So two separate ideas here, right? First is hiding the DataBinder
(yes!) and the second is declarative change handlers for model updates.
Both are great ideas. So +1 to both.
The only thought I had on the declarative model change handler bit was
to have an *option* to be more specific with the declaration. In other
words, I might only care about one or two properties in my model. And I
might have very different logic that I want to perform for the different
properties. So it might be nice to target a single property name when
creating the change handler. Perhaps:
@OnModelChange(propertyName="firstName")
public void onMyModelChange(@OldModel MyModel model,
@NewModel MyModel newModel,
@Source Object source)
{
// Perform name-change logic here
}
@OnModelChange(propertyName="dob")
public void onMyModelChange(@OldModel MyModel model,
@NewModel MyModel newModel,
@Source Object source)
{
// Perform date of birth change logic here
}
Alternatively it could be:
@OnModelChange(properties={"firstName", "dob"})
And then method signature could remain the same.
-Eric
On 03/11/2013 08:42 PM, Mike Brock wrote:
> This gets us a little closer to something like this:
>
> @Singleton
> public class MyBean {
> @Inject @AutoBound MyModel model;
> @Inject @Bound Label name;
>
> public void onMyModelChange(@NewModel MyModel updatedModel) {
> // do something with updatedModel
> }
>
> @ModelSetter
> public void setModel(MyModel model) {
> this.model = model;
> }
> }
>
> Note that I didn't inject a DataBinder<T> but rather the MyModel directly.
> Also pay attention to the @ModelSetter annotation. The theory behind this is
> the DataBinder<T> would be created in the Bootstrapper but never actually
> injected. The @ModelSetter is a hint to create decorator code that proxies
> that method so the hidden DataBinder's setModel() method can be called, and
> then the proxied model object then passed on to the MyBean.setModel(). This
> requires AOP-style parodying of the MyBean in this case. But I think it's a
> powerful tradeoff.
>
> Mike.
>
> On 2013-03-11, at 8:33 PM, Mike Brock <[email protected]> wrote:
>
>> While I was playing tonight I had a few ideas I wanted to bounce off
>> everyone. What about a higher level API for handling change events?
>>
>> Consider the following:
>>
>> ====HelloWorld.java=========================================
>>
>> @EntryPoint
>> @Templated("#root")
>> public class HelloWorld extends Composite {
>> @Inject @AutoBound private DataBinder<MyModel> model;
>>
>> @Inject @NeedsData @Bound @DataField private TextBox name;
>> @Inject @DataField private Button button;
>>
>> @EventHandler("button")
>> private void onClick(ClickEvent e) {
>> messageBox.setText("Hello there, " + model.getModel().getName());
>> }
>>
>> @OnModelChange
>> public void onMyModelChange(@OldModel MyModel model,
>> @NewModel
>> MyModel newModel,
>> @Property String
>> propertyName,
>> @Source
>> Object source) {
>> // react to change
>> }
>> }
>>
>> ----------------------------------------------------------------------------------------------------
>>
>> ====ChangeEvents.java======================================
>>
>> @Singleton
>> public class ChangeEvents [
>> @OnGlobalModelChange
>> public void onMyModelChange(@OldModel MyModel model,
>> @NewModel
>> MyModel newModel,
>> @Property String
>> propertyName,
>> @Source
>> Object source) {
>> // react to change
>> }
>> }
>>
>> ----------------------------------------------------------------------------------------------------
>>
>> Note: the idea is that each of the specified attributes are optional with
>> the exception you must specify *at least* @OldModel or @NewModel. So in
>> practice you might just do something like this:
>>
>> public void onMyModelChange(@NewModel MyModel updatedModel) {
>> // do something with updatedModel
>> }
>>
>> The general idea is that the @ OnGlobalModelChange would match all *managed*
>> (read: injected automatically by the container such as @AutoBound)
>> DataBinders that match MyModel. Where-as the @OnModelChange in the
>> HelloWorld class would be scoped just to that one ErraiUI bean.
>>
>> ----
>>
>> This is just something I brainstormed in about 15 minutes. I am not fixed on
>> this particular approach. But I found myself wanting a declarative way of
>> listening for changes tonight that didn't involve me adding a @PostConstruct
>> and manually adding a PropertyChangeHandler to the DataBinder.
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> errai-dev mailing list
>> [email protected]
>> https://lists.jboss.org/mailman/listinfo/errai-dev
>
>
> _______________________________________________
> errai-dev mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/errai-dev
>
_______________________________________________
errai-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/errai-dev
