On Mon, 2003-11-24 at 06:27, Timothy Larson wrote: > --- 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.
Be careful though, since it's not possible to blindly cache those; as for a repeater these can change if rows are removed. Maybe resetting the cached value at the start of readFromRequest would be enough to solve this. > > > 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. still marked as unread :-) -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
