Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[e4-dev] E4/JavaScript additional thoughts 
Looking at the wiki page:

	http://wiki.eclipse.org/E4/JavaScript

I've got a few more thoughts.
- I don't fully grok where you're going with the bundled JSON bit. I realize we need to have a way of being able to bundle a bunch of things, presumably even a number of "plugins" into one wad, for efficiency sake, at deployment time. But this really needs to run in an "unbundled", "file-based" way at development time. At development time, I need to be able to edit a .js file, save, and "reload" (for some definition of reload). Without having to go through a "build" step. Almost seems like the declarative bits need to all be kinda file-based, with some other declarative bits providing advisory information on where "bundled" versions might be located, or something.
- Any thought given to handling more languages than just JavaScript? One way to handle this, and make things like the "script descriptor" in the plugin.xml a bit neater, would be to define a prefix that mapped to a class adapter per language kind of thing. eg, here's a sample of a plugin.xml entry: 

<extension point="org.eclipse.equinox.http.registry.servlets">
  <servlet
      class="js:jsHello:myServlet">
  </servlet>
</extension>
with the idea being of folding in a bunch of things at once - the factory, the alias, the resource identifier, and for JS, the "class identifier". The "js" prefix would be a key to the script adapter, the remaining bits would be an adapter-specific resource identifier which would need to identify the actual class. A Jython version would simply replace the value of the class attribute with "jython:jyHello.myServlet", where jyHello identified a Python module (in the file jyHello.py file), which contains a class named myServlet. Very natural for Python, seems like. Obviously, we'd need to come up with some conventions for referring to JS "modules" and things within them.
- for the example JavaScript code, there's a couple of glorpy things here. One is that there is a repetition of the "some" variable back to the extension. I've removed that in my plugin example above, with the implied suggestion that there would be something like a magic global variable, say called "module" or something, which you would use instead of the "some" variable in the JavaScript code. You would also remove the initialization of that variable, it would be initialized for you (to an empty object) at "creation time".
- the other glorpy bit, for the JavaScript code, is the indirection of the Java class-ization of the JS bits. Why not just return the class? Here's an example, with a different bit of style (but equivalent, depending on semantics of the "global scope") for specifying the instance methods: 

function service(req, resp) {
  this.super$service(req, resp); // this is very important
}

function doGet(req, resp) {
  resp.getWriter().write("<html><body>");
resp.getWriter().write("Hello World from a " + this.getServletInfo()); 
  resp.getWriter().write("</html></body>");
}

function getServletInfo() {
  return "JavaScript Servlet";
}
module.myServlet = new JavaAdapter(Packages.javax.servlet.http.HttpServlet, { 
	"service":        service,
	"doGet":          doGet,
	"getServletInfo": getServletInfo
})

Patrick Mueller - http://muellerware.org/

Back to the top