flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mihai Chira <mihai.ch...@gmail.com>
Subject Re: [GitHub] flex-sdk pull request: Fix FLEX-15159 by making ArrayList extend P...
Date Sun, 07 Jun 2015 16:35:49 GMT
Hi Fr├ęd, thanks for your suggestion. (I responded inline.)

> I have to admit I'm not very keen to see an already overly complex class to become even
more complex adding complex field managment.
Me neither, I agree. I was thinking to add the field watcher as an
optional constructor parameter / setter, in-line with Alex's
philosophy of you get what you pay for. This way the class itself
won't become more complex, and also developers have a choice of
whether they want to ask the collection to fulfil this role or not.
How does that sound?

> I generally solve the problem at application level, using a decorator pattern to my VO
mixed with a dynamic class to, at sort events, dynamicaly add or remove simple fields and
forward their value to their complex counterpart, it
> works as well when you have hierarchical data and you want to display them in a flat
datagrid, if  those VO need to be sent on the server or the rest of the application, I use
the decoratee VO.
That's a solution too, but some developers might not know how to do it
(by using the decorator pattern or through bindings), might not have
time, and might make mistakes implementing it. Plus, in my mind this
is core framework functionality, and it's not there simply because (I
imagine) the Adobe developers never got round to it. It's no stretch
to me to think that if we monitor changes to objects and then resort
collections based on those changes, we can and should do the same for
nested chains of objects.

Mime
View raw message