[errai-dev] Declarative API for PropertyChangeHandlers in DataBinding
Jonathan Fuerth
jfuerth at redhat.com
Tue Mar 12 11:16:56 EDT 2013
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 <eric.wittmann at redhat.com> 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 <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
>>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130312/5f51d965/attachment.html
More information about the errai-dev
mailing list