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
