Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [riena-dev] UnboundPropertyWritableList - Can we remove it?

Hi Elias,

I agree that we should get rid of the UPWL. I did some experiments with the table example in the Riena playground and I found only one case where the behaviour differs depending on whether I use a WritableList or an UPWL. This is a 'bug' with a 3.5 target platform that you already discovered: https://bugs.eclipse.org/264453 . This bug disappears when I switch to an UPWL: in the TableSubModuleController I replaced 'new WritableList(input, WordNode.class)' with 'new UnboundPropertyWritableList(this, "input")' and added a getter and a setter for the property 'input'.

I also came across a different but related issue: if the list elements are JavaBeans with bound properties then property changes appear in the table immediately (no matter if a WritableList is used or an UPWL). This is contradictory to our default update strategy 'on request' that should require the method updateFromModel() to be invoked on the Ridget.

So +1 to the removal of the UPWL - while there may be some open questions I don't think that the UPWL is the answer to any of them :-)

Greetings,
Carsten


> -----Ursprüngliche Nachricht-----
> Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-
> bounces@xxxxxxxxxxx] Im Auftrag von Elias Volanakis
> Gesendet: Montag, 9. März 2009 21:44
> An: Riena Developers list
> Betreff: [riena-dev] UnboundPropertyWritableList - Can we remove it?
>
> Hi Riena committers,
>
> I am questioning the purpose of UnboundPropertyWritableList (=UPWL).
>
> Currently UPWL insulates a list kept in the model from the list kept in
> the ridget (see details below). My preference would be to completely
> remove UPWL, and instead modify the list-based ridgets (table, tree,
> list) to do the "insulation" internally.
>
> My motivation is, that relying on a non-standard class (UPWL) to get
> that insulation is not practical, because most developers will use the
> default mechanisms (BeansObservables / PojoObservables / WritableList)
> and miss UPWL:
>
> listRidget.bindToModel(new WritableList(days, MyNode.class),
> MyNode.class, columnPropertyNames, null);
>
> instead of:
>
> listRidget.bindToModel(new UnboundPropertyWritableList(new
> ListBean(days), ListBean.PROPERTY_VALUES), MyNode.class,
> columnPropertyNames, null);
>
> Let me know what you think about removing it.
>
> Elias.
>
>
>
> --- Full details for the interested ---
>
> I've compared UPWL with PojoObservables.bindList(...) /
> BeansObservables.bindList(...) / new WriteableList(list, clazz). The
> only difference I found between the default mechanisms and UPWL, is
> that the latter does not automatically 'register' modifications to the
> underlying list:
>
> Standard Databinding:
>
> IObservableList input = BeansObservables.observeList(bean,
> ListBean.PROPERTY_VALUES);
> input.toArray().length; // returns N
> bean.getList().add(foo);
> input.toArray().length // returns N + 1
>
> Riena UPWL:
>
> UnboundPropertyWritableList upwl = new UPWL(bean, "getter")
> upwl.toArray().length; // returns N bean.getList().add(foo);
> upwl.toArray().length // still N -- this is useful for ridgets, but we
> could do it ourselves
>
> We use this behavior to insulate the data kept in the ridget, until
> #updateFromModel() is invoked:
>
> public void updateFromModel() {
>   ...
>   if (rowObservables instanceof UnboundPropertyWritableList) {  // not
> so nice...
>      ((UnboundPropertyWritableList) rowObservables).updateFromBean();
>   }
>   ...
> }
>
> If you want to experiment see attached snippet.
>
> I think it would be better to add the "insulation" behavior to the
> appropriate ridgets (for example via a helper class) instead of relying
> on the custom type UPWL (implements IObservable).
>
> Elias.


Back to the top