Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] JavaScript support wiki entry

Thanks Pat,
....figured it was only a matter of time before your replied.

> I've also had specific problems with Rhino not being able to handle some particular Java constructs. Can't remember exactly, something to do with some classes in Java that were difficult/impossible to subclass correctly in JS, but you needed to per the API contract - had to resort to writing Java "covers" that I could then subclass in JS, or some such.

Indeed. Sub-classing with JavaAdapter doesn't work nearly as well as implementing interfaces which is fine. The example of sub-classing an HttpServlet that I posted is a case in point. There you must implement the "service" method to avoid problems as the generated wrapper class can't sort out which of the two "service" methods to use for incoming requests. As part of this effort I'll take a closer look at the classes generated and see if I can't put up a page to clarify method and field dispatch and where appropriate log/fix bugs in Rhino.

> The other thing of interest to me is trying to inject some modularity into the picture. Best effort thus far is some of the work proposed on the serverJS stuff - https://wiki.mozilla.org/ServerJS . I think the current proposal that is favored is the poorly named "SecurableModules" proposal - https://wiki.mozilla.org/ServerJS/Modules/SecurableModules ; this happens to be the approach I like best as well.

Yep. Following this incredibly closely especially now that everyone has calmed down a little bit. Not surprisingly the approaches are incredibly similar with (I think) some differences in when the module metadata is represented and subsequently more substantial differences in what a resolver would look like.

> Not sure how this would fit into the Eclipse work, might well not at all; I suspect you may be loading the _javascript_ code in separate contexts anyway.
In a pure _javascript_ implementation the equivalent of Rhino Contexts are only an eval in a function closure away and in the cards :)

-Simon


Inactive hide details for Patrick Mueller ---02/19/2009 08:39:15 AM---I only have one thing to say ... SWEEEEEET!!!! Been waitiPatrick Mueller ---02/19/2009 08:39:15 AM---I only have one thing to say ... SWEEEEEET!!!! Been waiting to "script Eclipse" forever.


From:

Patrick Mueller <pmuellr@xxxxxxxxx>

To:

E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

Date:

02/19/2009 08:39 AM

Subject:

Re: [e4-dev] _javascript_ support wiki entry




I only have one thing to say ... SWEEEEEET!!!!

Been waiting to "script Eclipse" forever.

Couple things:

I've had mixed success is mixing Java and scripting languages. Eventually things devolve into "writing Java in xxx language", which isn't really a big help. I've also had specific problems with Rhino not being able to handle some particular Java constructs. Can't remember exactly, something to do with some classes in Java that were difficult/impossible to subclass correctly in JS, but you needed to per the API contract - had to resort to writing Java "covers" that I could then subclass in JS, or some such. I'm glad to see a concerted effort made here though.

The other thing of interest to me is trying to inject some modularity into the picture. Best effort thus far is some of the work proposed on the serverJS stuff - https://wiki.mozilla.org/ServerJS . I think the current proposal that is favored is the poorly named "SecurableModules" proposal - https://wiki.mozilla.org/ServerJS/Modules/SecurableModules ; this happens to be the approach I like best as well. Not sure how this would fit into the Eclipse work, might well not at all; I suspect you may be loading the _javascript_ code in separate contexts anyway.

On Feb 19, 2009, at 12:45 AM, Simon Kaegi wrote:
      I've added a page on some of the work I've been doing for _javascript_ support to the E4 wiki here -- http://wiki.eclipse.org/E4/_javascript_
      I'll follow this up with a more user friendly blog posting demonstrating it's use but for those who want an early peek..

Patrick Mueller - http://muellerware.org/



_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev


GIF image

GIF image


Back to the top