If you would like to see this in action, just have a look at: https://dfruits.dev.java.net/forms/
This concept has been in use in a business rcp with hundreds of "forms" managed declaratively through the proper extension points for 2 years now and has proven to be quite useful... most of them programmed in xswt declaratively, some others natively in java, others again scripted... I would really like to see eclipse support something like that natively. 2009/9/1 Mike Wilson <[email protected]>: > I like the idea of having pluggability here. Then the only constraint on > whether the toolkits get delivered as part of the SDK is whether or not one > or more of the SDK Parts is built with them. That is, if they are being > *used* by the SDK, then they need to be part of the main download, otherwise > they can be delivered separately and users can pick up which ever one they > want to use. > > McQ. > > Erdal Karaca ---2009/09/01 01:52:30---Yes, that would be the same approach > as jsr223 where each scripting > > > From: > Erdal Karaca <[email protected]> > To: > E4 Project developer mailing list <[email protected]> > Date: > 2009/09/01 01:52 > Subject: > Re: [e4-dev] how to contribute to toolkit model ? > ________________________________ > > > Yes, that would be the same approach as jsr223 where each scripting > language is bridged to and accessible from one API... > > 2009/8/31 Hallvard Trætteberg <[email protected]>: >> Erdal Karaca wrote: >>> >>> IMHO, there should be as many (declarative) ui frameworks as needed, >>> as long as there is a uniform way of using them in the target >>> platform... >> >> I think I understand what you mean: If there is a standard way of >> loading a declared UI from a URI and bind to its parts, we needn't limit >> the languages that we support. I.e. some extension point for pluging in >> a new language and rendering engine, and a service for finding a >> suitable for a particular resource/content type. >> >> This reminds me of the Java standard for using Java-based scripting >> language. Lots of scripting languages could be integrated into an >> application by standard means. There was a snag though: If you often >> couldn't access important engine objects at a fine enough granularity, >> like scopes. But in general, being able to plug in new languages and >> rendering engines could be a good thing. >> >> Hallvard >> >> _______________________________________________ >> e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/e4-dev >> > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
