--- Bruno Dumon <[EMAIL PROTECTED]> wrote: ...slow operation on deeper nesting levels... > Don't have any either (damn that optimizeit thing is expensive), but > suddenly the thought crossed my mind that this might be caused by the > calls to getFullyQualifiedId(), and adding some little caching code > there solved it indeed.
Thanks. I fixed one or two other methods like that, but missed that one. > Another thing I noticed is that in Union.readFromRequest, you first let > the active case do the readFromRequest, and then call > super.readFromRequest, which will let all cases do the readFromRequest. > I don't think this is needed, and it solves the multiple row creation > problem in the repeaters. (same applies to validate() I gues) Good, that should also solve the problem of nested repeaters losing their state when the enclosing union switches cases. > Anyway, I'm starting to think that the easiest way to collaborate on > this is if we just commit the code into CVS. Anyone got a problem with > that? Sounds good, as long as nobody hesitates to change aspects of it as needed. For example, I have been wondering about changing the Union widget from a composite widget to a container widget. The union could have an attribute which specifies which widget would act as the discriminant, or it could evaluate a general expression, which could reference other widgets, to produce the discriminant value. See my next email about subforms for the reason for this possible change. --Tim Larson __________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
