Tim Larson wrote:
On Sun, Nov 07, 2004 at 09:29:40PM +0100, Sylvain Wallez wrote:
Tim Larson wrote:
On Fri, Nov 05, 2004 at 09:58:43PM +0100, Sylvain Wallez wrote:So let's discuss your concerns. I started looking at Swan, and it seems to me that what's needed is simply and additional "output" state.
Tim Larson wrote:concerns before. I will try to take some time this weekend
to see how to resolve this. I really do not want to revert
the code if we can just improve it instead. I just feel
pressured by the short time before we plan to release.
Do you want me also to explain more clearly how states are implemented and behave (lacked the time to write some docs)?
I finaly got to look at the widget states implementation, 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.
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.
This will allow
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.
Ok, waiting :-)
[Question:]
http://marc.theaimsgroup.com/?l=xml-cocoon-cvs&m=109994348811745&w=2
Is this change acceptable for keeping in the trunk and
including in the stable branch? (The part about changing
from isAcceptingInputs() to isValidatingValues() in
the widgets' validate() methods?) Currently both methods
will return the same value, but this will allow us to
split the logic later if needed.
Good idea. The various isXXX methods on WidgetState are meant to avoid direct reference to actual state constants within the code. That firstly avoids inconsistencies and also allow later extension if needed (once again, I think we'll need to add an "output" state).
So go on merging in the stable branch!
Well, you've got a point here: yes, you should probably explain more what you want to do. The group's feedback will strengthen the ideas and turn them into a collective creation rather than a one-man show.
Agreed. I will update my wiki page to explain my current
plans, so they can be discussed, changed, and improved :)
Good idea, but rather than your page or WoodyScratchpad, what about a new CFormsScratchpad or a [RT] so that we can all work collaboratively towards well-defined evolutions?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
