What about aligning this more with the @EventHandler annotation we already have in the Errai UI module? I guess we can't reuse exactly that annotation since errai-data-binding doesn't depend on errai-ui, but maybe we can name it similarly, like @ModelChangeHandler or @PropertyChangeHandler?
-Jonathan On 2013-03-12, at 9:59 AM, Christian Sadilek wrote: > I like the @OnModelChange proposal and agree it should also support > specifying the property or a property list. > > However, wouldn't @OldModel always equal @Source in the examples below? The > source object is the object on which the event (change) occurred which should > always be the old model object, or did I misunderstand? I mean if they are > all optional it's fine but we can probably get away with one less annotation > if we wanted to. > > See: > https://github.com/errai/errai/blob/master/errai-data-binding/src/main/java/org/jboss/errai/databinding/client/api/PropertyChangeEvent.java > > We could additionally support @OldValue and @NewValue for property specific > change handlers: > > @OnModelChange(propertyName="dob") > public void onMyModelChange(@OldValue Date oldDob, @NewValue Date newDob, > @Source Object source) > { > // Perform date of birth change logic here > } > > Cheers, > Christian > > On 2013-03-12, at 7:36 AM, Eric Wittmann <[email protected]> wrote: > >> 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 > > _______________________________________________ > 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
