Combine experience [message #542098] |
Wed, 23 June 2010 20:45 |
rjahn Messages: 8 Registered: June 2010 Location: Vienna/Austria |
Junior Member |
|
|
Sapphire is really a good idea and UI development with data-binding should be as simple as possible to have enough time to fulfill the requested requirements. Developers life should be easier.
In the last 2 years we developed an open source library with pretty the same goals. So it maybe makes sense to combine our experience.
Our library is distributed under apache license 2.0 and is available on our website http://www.sibvisions.com/en/jvx.
[Updated on: Thu, 24 June 2010 08:06] Report message to a moderator
|
|
|
|
Re: Combine experience [message #543253 is a reply to message #542098] |
Mon, 28 June 2010 19:55 |
rjahn Messages: 8 Registered: June 2010 Location: Vienna/Austria |
Junior Member |
|
|
Your blog helped to understand for what Sapphire is developed.
For me, it is a good idea to help developers to create UIs. But the developer must still write a lot of
interfaces/xml files. But not so much as before and that helps!
How is your plan to integrate the database access?
How has the developer to combine UI model with domain model?
Any plans for client/server apps?
The UI is only one part in application development. Of course, it depends on the application type.
If a developer creates an UI, in most cases, he needs more e.g. database access, client/server communication,
business logic, ...
With JVx we try to help the developers with every part of app development.
The developer has to write source code instead of define the UI by XML. The written code can then be run as Desktop, RIA or HTML/Ajax application, without any changes in the code. Same code, different UI platform. We have a standard cross platform UI Interface for widget's, layouts etc. and we wrote an implementation for each UI technology. So we take care about the UI platform problems, and for the Application Developer is everything the same!
We have the same idea/vision "simplify development", but I think we used a kind of different way to solve the needs of an developer over the complete development process of a typical database driven business applications.
|
|
|
|
Re: Combine experience [message #543776 is a reply to message #543258] |
Wed, 30 June 2010 14:28 |
rjahn Messages: 8 Registered: June 2010 Location: Vienna/Austria |
Junior Member |
|
|
> We have no specific plans right now to work on easing database access, but Sapphire model is flexible......
You are right. I asked because easy UI creation is very important but the UI needs data to work as expected. In your example you described value properties, list properties, ...
And that is what i meant with UI model / domain model combination:
e.g.:
We access the database with an ORM (maybe cayenne or hibernate or others)
We create all relevant classes, database, ...
On the backend we have our POJOs and on the frontend we have our UI model.
Now we need a lot of source code to bind our "data model" to the "UI model". There is not really a difference between UI binding, with or without Sapphire, isn't it?
Am I completely Offtopic?
> Riena
I read a lot about the framework, but I did not try to create apps. I like the direction of thinking but the dependencies let it appear complex.
Some time ago I searched a solution for Android devices: Same framework for development, but different apps:
- Frontend/Backend (Java RIA)
- Mobile Client (Android)
I did not find a framework which has both. There are a lot of frameworks/tools which supports service creation and other frameworks which supports the service access.
But I need a lot of frameworks to do simple things...
JVx helps us to do above things, because it is very small and doesn't assume other libraries. And it runs on android devices too.
But that's not the right place to discuss differences between Riena and JVx
|
|
|
Re: Combine experience [message #543826 is a reply to message #543776] |
Wed, 30 June 2010 17:05 |
Konstantin Komissarchik Messages: 1077 Registered: July 2009 |
Senior Member |
|
|
> On the backend we have our POJOs and on the frontend we have our
> UI model.
>
> Now we need a lot of source code to bind our "data model" to the "UI
> model". There is not really a difference between UI binding, with or
> without Sapphire, isn't it?
I think I finally understand what you mean by "data model" and the "UI model".
In Sapphire, the model presents a standard front-end interface to clients (such as the UI renderer or custom processing code). This is the interfaces, the annotations and the properties that you see in the articles that I posted. This part doesn't change depending on how the data is stored, so the Sapphire UI framework will bind to the model whether the data comes from XML, database or some other custom source.
On the back-end of the model, there is a concept of a resource which knows how to read/write properties to the underlying storage medium. Sapphire provides a resource implementation for XML that binds to XML DOM, but anyone can write a custom resource. For instance, someone could write a resource that binds to JPA POJOs. Some JPA frameworks have powerful underlying data access layer that can be leveraged directly without the intermediary step of a POJO, which in the Sapphire case would be hidden behind the model so it doesn't provide much value.
I hope that answered your questions.
> But I need a lot of frameworks to do simple things...
This tends to be a natural product of the diversity of usecases. Of course there also an opportunity here for third parties to create value by assembling multiple components into solutions suited for particular problems.
My goal is to keep Sapphire core very light and make it possible for it to run in a variety of environments. Currently Sapphire requires OSGi, primarily for extensibility (third parties adding extensions). I am actively looking for ways to break this dependency because I'd like to make Sapphire accessible to every Java developer.
It sounds that in many ways the goals of Sapphire and JVx are aligned. We could use help writing additional renderers as we currently have only one for SWT. We could use one for Swing and one for HTML/Ajax. It looks like you have a lot of experience in this area. Sapphire's scope may not encompass an end-to-end solution that your a looking for with JVx, but perhaps with a bit of work Sapphire can be the UI component in JVx?
- Konstantin
|
|
|
|
|
Re: Combine experience [message #561072 is a reply to message #543258] |
Wed, 30 June 2010 14:28 |
rjahn Messages: 8 Registered: June 2010 Location: Vienna/Austria |
Junior Member |
|
|
> We have no specific plans right now to work on easing database access, but Sapphire model is flexible......
You are right. I asked because easy UI creation is very important but the UI needs data to work as expected. In your example you described value properties, list properties, ...
And that is what i meant with UI model / domain model combination:
e.g.:
We access the database with an ORM (maybe cayenne or hibernate or others)
We create all relevant classes, database, ...
On the backend we have our POJOs and on the frontend we have our UI model.
Now we need a lot of source code to bind our "data model" to the "UI model". There is not really a difference between UI binding, with or without Sapphire, isn't it?
Am I completely Offtopic?
> Riena
I read a lot about the framework, but I did not try to create apps. I like the direction of thinking but the dependencies let it appear complex.
Some time ago I searched a solution for Android devices: Same framework for development, but different apps:
- Frontend/Backend (Java RIA)
- Mobile Client (Android)
I did not find a framework which has both. There are a lot of frameworks/tools which supports service creation and other frameworks which supports the service access.
But I need a lot of frameworks to do simple things...
JVx helps us to do above things, because it is very small and doesn't assume other libraries. And it runs on android devices too.
But that's not the right place to discuss differences between Riena and JVx :)
|
|
|
Re: Combine experience [message #561089 is a reply to message #543776] |
Wed, 30 June 2010 17:05 |
Konstantin Komissarchik Messages: 1077 Registered: July 2009 |
Senior Member |
|
|
> On the backend we have our POJOs and on the frontend we have our
> UI model.
>
> Now we need a lot of source code to bind our "data model" to the "UI
> model". There is not really a difference between UI binding, with or
> without Sapphire, isn't it?
I think I finally understand what you mean by "data model" and the "UI model".
In Sapphire, the model presents a standard front-end interface to clients (such as the UI renderer or custom processing code). This is the interfaces, the annotations and the properties that you see in the articles that I posted. This part doesn't change depending on how the data is stored, so the Sapphire UI framework will bind to the model whether the data comes from XML, database or some other custom source.
On the back-end of the model, there is a concept of a resource which knows how to read/write properties to the underlying storage medium. Sapphire provides a resource implementation for XML that binds to XML DOM, but anyone can write a custom resource. For instance, someone could write a resource that binds to JPA POJOs. Some JPA frameworks have powerful underlying data access layer that can be leveraged directly without the intermediary step of a POJO, which in the Sapphire case would be hidden behind the model so it doesn't provide much value.
I hope that answered your questions.
> But I need a lot of frameworks to do simple things...
This tends to be a natural product of the diversity of usecases. Of course there also an opportunity here for third parties to create value by assembling multiple components into solutions suited for particular problems.
My goal is to keep Sapphire core very light and make it possible for it to run in a variety of environments. Currently Sapphire requires OSGi, primarily for extensibility (third parties adding extensions). I am actively looking for ways to break this dependency because I'd like to make Sapphire accessible to every Java developer.
It sounds that in many ways the goals of Sapphire and JVx are aligned. We could use help writing additional renderers as we currently have only one for SWT. We could use one for Swing and one for HTML/Ajax. It looks like you have a lot of experience in this area. Sapphire's scope may not encompass an end-to-end solution that your a looking for with JVx, but perhaps with a bit of work Sapphire can be the UI component in JVx?
- Konstantin
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04878 seconds