[errai-dev] Declarative API for PropertyChangeHandlers in DataBinding

Eric Wittmann eric.wittmann at redhat.com
Tue Mar 12 07:36:25 EDT 2013


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 <cbrock at redhat.com> 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
>> errai-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/errai-dev
>
>
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev
>


More information about the errai-dev mailing list