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.
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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
