Tim Larson wrote:
On Wed, Nov 10, 2004 at 08:54:33PM +0100, Sylvain Wallez wrote:
Tim Larson wrote:
<snip/>
I finaly got to look at the widget states implementation,Do you mean the distinction between getState() and getCombinedState()? I implemented it that way because I felt that we may need to now the actual state of a widget and not always the combination with it's parent state according to the state priority rules.
and even port parts of Swan to use it (working on porting
the rest now). I see some things we can improve, but it
looks good overall because of the separation between how
we set states and how we query them.
Yes, I like the the getState()/getCombinedState() split, and also the split between how we set a state (currently all attributes at once: readable, writeable, styling hint) versus how we query the state with isXXX (quering the attributes individually.) This will permit us to later allow setting the different attributes independently (if the need develops.)
This will allowOk, waiting :-)
us to add more fine-grained state setting logic without
disturbing existing state querying logic (if we find we
need these changes in the future.) I will comment on
the possible improvements later when I have collected
my thoughts more, since they should not affect back-
compatibility anyways.
The most visible problem is that getCombinedState() is
called several times per widget, and (iiuc) it climbs
up to the root of the widget tree on each call. This
would be rather inefficient for a deeply nested form,
such as an xml editor. Perhaps we should reverse and
cache the updates, having a parent notify its children
when its state changes? This would cut the number of
tree passes considerably, at the cost of some memory
use for caching the combined states.
I thought about this problem when implementing states, and wanted to add a "parentStateChanged()" method to the Widget interface, so that a container could notify its children that some state change happened in the upper levels, for them to recompute their combined states.
I decided however not to add it as it seemed to me like letting the internal state computing machinery appear on the general widget interface. The state combination is very lightweight (comparing two integers) and my feeling was that it should only become visible in very large and very deep structures.
This is something we can add now or later with no other impact than this new parentStateChanged method.
BTW, for something really inefficient, have a look at getParameterName() before updating SVN: the string concatenation occurs at each call when we know that, contrarily to states, a widget path never changes! I just changed it so that computation occurs only once.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
