|
| Re: One Framework to bind them All ?! [message #545175 is a reply to message #545136] |
Tue, 06 July 2010 22:33   |
 Konstantin Komissarchik
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
Hi Werner,
Good question. You can find relation to e4 and JFace Data Binding explained in the project proposal.
http://www.eclipse.org/proposals/sapphire/
As to others...
1. Nebula. This is a collection of custom widgets. As such, it occupies the same place in the technology stack as SWT itself. In particular, Sapphire renderer for SWT could leverage Nebula widgets if that made sense.
2. Riena. This is a very broad project that aims to create an end-to-end toolkit for making it easier to build enterprise RPC apps. There is everything from UI to client-server and services architecture. On the UI side there this concept of ridgets. Judging by examples I've seen ridgets are very close to SWT widgets. You get some help with styling and such, but they are ultimately at the same level of the technology stack as widgets. You have to know that you want to create a label ridget or a text box ridget.
3. RedView. This is not an eclipse.org project, which may rule it out in some situations. It is based on Riena ridgets and introduces a declarative UI model. Since the RedView model is over ridgets, which are very close to SWT widgets, it is a similar level of abstraction to e4. By comparison, Sapphire models UI at the level of property editors, which makes the UI definitions more portable (different renderers can choose to present the same property in a different way depending on the capabilities of the UI platform). Even if SWT is your only target, Sapphire's approach makes it easier to drop in a new property editor implementation that is configured to activate based on a certain heuristic and have it immediately take affect across all UI screens written with Sapphire.
4. Scout. This is one that I am least familiar with, but from looking at the posted demos, this basically looks like Riena + RedView. An end-to-end platform for building enterprise apps, with UI just one aspect of the puzzle. Just like RedView, the modeling of UI happens at the level of widgets... text boxes, labels, buttons.
I hope I have answered your questions. If you'd like to learn more about Sapphire, you can read the introduction article:
http://lt-rider.blogspot.com/2010/06/sapphire.html
- Konstantin
|
|
|
| Re: One Framework to bind them All ?! [message #545257 is a reply to message #545136] |
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 #545289 is a reply to message #545258] |
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 #561139 is a reply to message #545136] |
Tue, 06 July 2010 22:33 |
Konstantin Komissarchik
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
Hi Werner,
Good question. You can find relation to e4 and JFace Data Binding explained in the project proposal.
http://www.eclipse.org/proposals/sapphire/
As to others...
1. Nebula. This is a collection of custom widgets. As such, it occupies the same place in the technology stack as SWT itself. In particular, Sapphire renderer for SWT could leverage Nebula widgets if that made sense.
2. Riena. This is a very broad project that aims to create an end-to-end toolkit for making it easier to build enterprise RPC apps. There is everything from UI to client-server and services architecture. On the UI side there this concept of ridgets. Judging by examples I've seen ridgets are very close to SWT widgets. You get some help with styling and such, but they are ultimately at the same level of the technology stack as widgets. You have to know that you want to create a label ridget or a text box ridget.
3. RedView. This is not an eclipse.org project, which may rule it out in some situations. It is based on Riena ridgets and introduces a declarative UI model. Since the RedView model is over ridgets, which are very close to SWT widgets, it is a similar level of abstraction to e4. By comparison, Sapphire models UI at the level of property editors, which makes the UI definitions more portable (different renderers can choose to present the same property in a different way depending on the capabilities of the UI platform). Even if SWT is your only target, Sapphire's approach makes it easier to drop in a new property editor implementation that is configured to activate based on a certain heuristic and have it immediately take affect across all UI screens written with Sapphire.
4. Scout. This is one that I am least familiar with, but from looking at the posted demos, this basically looks like Riena + RedView. An end-to-end platform for building enterprise apps, with UI just one aspect of the puzzle. Just like RedView, the modeling of UI happens at the level of widgets... text boxes, labels, buttons.
I hope I have answered your questions. If you'd like to learn more about Sapphire, you can read the introduction article:
http://lt-rider.blogspot.com/2010/06/sapphire.html
- Konstantin
|
|
|
| Re: One Framework to bind them All ?! [message #561152 is a reply to message #545136] |
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 #562830 is a reply to message #545258] |
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.05386 seconds
] 
Search
Help
Register
Login
Home
