|
| Re: questions [message #542861 is a reply to message #542836] |
Sat, 26 June 2010 20:48  |
 Konstantin Komissarchik
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
> 1. How would I listen to the changes to the model in order to
> do some custom validation?
You can attach listeners to model elements that will fire when property state changes. The actual listener infrastructure is pretty flexible. For instance, you can use paths to specify what you want listen to...
element.addListener( listener, "../Contacts/Name" )
In the above example, not only will you simultaneously be registered to listen for changes to multiple model elements, but when a new contact is added your listener will be attached to it without any work on your part.
Better yet... You do not have to mess with listeners at all to attach custom validation. The framework provides @Validator annotation that references a class that you implement. The attached validators will get called any time property value changes. Since its common for validation to x-reference other properties, there is also a @DependsOn annotation which will lets you tell the framework that a given property should be refreshed (value read and validated) when some other properties change. For instance...
@DependsOn( "../Contacts/Name" )
@Validator( impl = UniqueValueValidator.class )
The above is from another Sapphire sample, which a basic contacts manager. These two annotations are attached to the contact name property and work to insure uniqueness of contact names in the list.
In addition to custom validation, the framework has a library of annotations for specifying constraints in a declarative manner. For instance...
@NonNullValue
@NumericRange( min = "2", max = "75" )
> 2. How would I signal it back to UI?
A property editor in the UI listens for changes to the property. A property is considered changed if its value has changed, its default value has changed or its validation state has changed. When property editor hears about the change, it refresh its state, including the problem marker.
So you never have to worry about signaling UI yourself. You just work on implementing your semantic rules in the model.
> 3. Any plans for tooling to author UI definitions?
Absolutely. Initially, it will be form-based as that's easy with Sapphire, but it sure would be nice to have a graphical editor for assembling the UI complete with drag-n-drop and design-time rendering of what the UI will look like at runtime.
> 4. Have you opened the bug for the source contributions yet?
Not yet. The Sapphire project is in a proposal phase now. In a few weeks, once the community had a chance to comment on the proposal and hopefully after gathering a group of interested parties, the project will go through the creation review and be fully provisioned. Right after that happens we will submit our contribution for EMO IP review. That can take some time, but we will apply for parallel IP review status and if that's granted we should have the code in Eclipse CVS soon after project creation.
> It seems that EMF has common ground for modeling here. It
> also allows to listen when model have changed. I am little
> surprised to see other modeling approach (JAXB inspired?).
That's a very common question, so thanks for asking. The goal of Sapphire is to promote an easier way to write UI. It so happens that the architecture that we arrived at uses data modeling, but we are fundamentally not in this to promote modeling. This has implication on our framework for making technical decisions.
For instance, one of the criteria that we have is that the framework must be approachable and easy to learn to an average Java developer. We did not want developers to dismiss Sapphire because they are intimidated by the modeling technology that they must first learn. We chose to design Sapphire modeling framework around concepts such as Java Beans and annotations that would already be familiar and therefore not intimidating to an average Java developer.
There are also practical implications from having a modeling framework tightly coupled to the needs of the UI framework. One of problems we needed to solve early on is dealing with malformed data. See the example in the last section of the intro article where an invalid value was entered for product stage in the source view. You don't want to restrict your semantic model to always deal with strings. You want your model to give you access to both typed and untyped data. It turns out that it is actually very difficult to get EMF to do this for you. It just wasn't designed around that use case. Since we had a coupled modeling framework in Sapphire, we were able to alter the modeling framework to support this scenario. That's why value property getters always return Value<?> object rather than native typed data. Through this value object, the caller can get data in typed or untyped format. The Value object also makes accessible other essential information, such as the default value and the validation state.
On the other hand, EMF does have a large community of users at Eclipse and sees a lot of use in some sectors of the industry. We do not want to cut off access to benefits of Sapphire to developers who are already invested in EMF. We have talked about building a bridge that would allow Sapphire to talk to EMF. We just need sufficient demand and most likely a partner interested in helping make that happen.
- Konstantin
|
|
|
Powered by
FUDForum. Page generated in 0.03044 seconds
] 
Search
Help
Register
Login
Home
