On Feb 27, 2009, at 3:41 PM, Simon Kaegi wrote: > - 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 "some" variable is just part of a manufactured _javascript_ namespace and of course not necessary and just part of the example. You can directly get the JSBundle object and call directly into it but the module is separate from any namespacing issue. (I suspect I'm missing your point here - sorry). In the example I didn't pre-initialize the variable because I want a new instance of the Servlet generated every time.
For the "some" variable thing, I was just trying to get it out of the plugin.xml. The way the example on the wiki is coded, you need to specify the same "module object" (in this case, "some") in both the _javascript_ code AND in the plugin.xml. Don't Repeat Yourself. There's already going to be lots of duplication of that kind with 'class names', and bundle identifiers, in both the _javascript_ and plugin.xml. We should be able to architect a way around having the "some" reference, anyway. For instance, by using a magic variable name like "module" in the _javascript_ code. The serverJS Securable Modules proposal uses a magic variable called "exports". Something like that.
|
