|
Re: One Framework to bind them All ?! [message #545245 is a reply to message #545137] |
Wed, 07 July 2010 09:51 |
Eclipse User |
|
|
|
Hi Werner
You are right there are already a whole bunch of kind of "similar" projects.
E4: The new release of Eclipse with a lot of deprecation cleanup, code
injection and workbench modeling. Promises to reduce the entry barrier
for Eclipse newbies. Scout will extend the e4 workbench model by its
component model and use injection to access services (the concepts of
Scout and e4 matches by 100%).
JFace Data Binding: An GUI only data binding SWT/JFace dependent. Since
Scout is fully GUI independent we are not making use of JFace data
binding in the framework part.
Nebula: A widget library. Your decision to use Nebula widgets in Scout
applications.
Riena: Of all the mentioned project Riena and Scout have the biggest
overlap. Both of them are projects to build whole application stacks
(multi tier applications). The overlap is mainly in the runtime part.
The Scout SDK (development environment) has more overlaps with the
RedView project. It depends on the project requirements what to use.
Sapphire: Sapphire is a project more on the DSL (domain specific
language) and declarative UI side. To not reduce the language scope
Scout does not use domain specific languages nor declarative UI.
Hope it helps
Andreas
Werner Keil wrote:
> Hi,
>
> I was wondering, how Sapphire stands compared to all those various
> binding projects:
>
> - E4
> - Scout (has its own mechanisms for binding)
> - Rienna
> - RedView (based on Rienna)
> - JFace Data Binding
> - Nebula (based on SWT/JFace)
>
> I may have missed some, but as you can see, there's already a whole lot
> of them out there.
> Also those are scattered all across different parts of Eclipse,
> Platform, RT, Technology.
>
> Thanks,
> Werner
|
|
|
|
Re: One Framework to bind them All ?! [message #545285 is a reply to message #545270] |
Wed, 07 July 2010 11:21 |
Eclipse User |
|
|
|
DSL (domain specific language)
is a language covers a certain domain. DSLs are simplifications of a
programming language to cover a certain domain. So the API of a DSL is a
subset of a programming language. Usually a good DSL has been validated
over several years to ensure the coverage of a domain (not more and not
less). In case a DSLs grow unregulated it ends up in a lot of scripting
code and hooks to include programming language fragments - a mess. A
main reason to formulate a DSL is to avoid the underlying programming
language from people using the DSL. The hiding of the programming
language has mainly two reasons on one side if the underlying
programming language is to complicated and unreadable on the other side
people working with a DSL are not familiar with the underlying
programming language (e.g. business people formulating some application
screens).
A good example of DSL is SQL; The API is good enough to access data of a
database but still clearly defined and simple. Even then some special
statements could not be translated into SQL so people come up with PLSql.
Scout decided to not formulate a DSL. Mainly in order Java is already a
readable and common language and Scout developers are familiar with
Java. Scout is designed for domain independent application development
what makes it difficult to formulate a DSL.
Cheers
Andraes
Werner Keil wrote:
> Thanks a lot for those.
>
> I'm sure this may help any developer curious of which one to use...
>
> What about the DSL? OR Domain-Specific-Framework mentioned in the proposal.
>
> Can you tell us more about that?
>
> Thanks,
> Werner
|
|
|
|
Re: One Framework to bind them All ?! [message #586269 is a reply to message #545137] |
Wed, 07 July 2010 09:51 |
Eclipse User |
|
|
|
Hi Werner
You are right there are already a whole bunch of kind of "similar" projects.
E4: The new release of Eclipse with a lot of deprecation cleanup, code
injection and workbench modeling. Promises to reduce the entry barrier
for Eclipse newbies. Scout will extend the e4 workbench model by its
component model and use injection to access services (the concepts of
Scout and e4 matches by 100%).
JFace Data Binding: An GUI only data binding SWT/JFace dependent. Since
Scout is fully GUI independent we are not making use of JFace data
binding in the framework part.
Nebula: A widget library. Your decision to use Nebula widgets in Scout
applications.
Riena: Of all the mentioned project Riena and Scout have the biggest
overlap. Both of them are projects to build whole application stacks
(multi tier applications). The overlap is mainly in the runtime part.
The Scout SDK (development environment) has more overlaps with the
RedView project. It depends on the project requirements what to use.
Sapphire: Sapphire is a project more on the DSL (domain specific
language) and declarative UI side. To not reduce the language scope
Scout does not use domain specific languages nor declarative UI.
Hope it helps
Andreas
Werner Keil wrote:
> Hi,
>
> I was wondering, how Sapphire stands compared to all those various
> binding projects:
>
> - E4
> - Scout (has its own mechanisms for binding)
> - Rienna
> - RedView (based on Rienna)
> - JFace Data Binding
> - Nebula (based on SWT/JFace)
>
> I may have missed some, but as you can see, there's already a whole lot
> of them out there.
> Also those are scattered all across different parts of Eclipse,
> Platform, RT, Technology.
>
> Thanks,
> Werner
|
|
|
|
Re: One Framework to bind them All ?! [message #586292 is a reply to message #545270] |
Wed, 07 July 2010 11:21 |
Eclipse User |
|
|
|
DSL (domain specific language)
is a language covers a certain domain. DSLs are simplifications of a
programming language to cover a certain domain. So the API of a DSL is a
subset of a programming language. Usually a good DSL has been validated
over several years to ensure the coverage of a domain (not more and not
less). In case a DSLs grow unregulated it ends up in a lot of scripting
code and hooks to include programming language fragments - a mess. A
main reason to formulate a DSL is to avoid the underlying programming
language from people using the DSL. The hiding of the programming
language has mainly two reasons on one side if the underlying
programming language is to complicated and unreadable on the other side
people working with a DSL are not familiar with the underlying
programming language (e.g. business people formulating some application
screens).
A good example of DSL is SQL; The API is good enough to access data of a
database but still clearly defined and simple. Even then some special
statements could not be translated into SQL so people come up with PLSql.
Scout decided to not formulate a DSL. Mainly in order Java is already a
readable and common language and Scout developers are familiar with
Java. Scout is designed for domain independent application development
what makes it difficult to formulate a DSL.
Cheers
Andraes
Werner Keil wrote:
> Thanks a lot for those.
>
> I'm sure this may help any developer curious of which one to use...
>
> What about the DSL? OR Domain-Specific-Framework mentioned in the proposal.
>
> Can you tell us more about that?
>
> Thanks,
> Werner
|
|
|
|
Powered by
FUDForum. Page generated in 0.03924 seconds