On Wed, Jun 16, 2004 at 04:49:44PM -0600, Johnston, Jason wrote: > Thank you for your reply, Tim...
We do not have code ownership here, but I still feel some healthy responsibility to help support code that I helped add, especially since not very many other developers seem to have figured out this piece of code yet. > > Working from memory alone, I only see three issues: > > * Where do you want the lookup to be relative to? Probably relative to > > the parent (like I think you are suggesting) would make the most > > sense. > > I agree with you, relative to the parent seems the most logical and is > consistent with the current behavior. Good, I think we can keep backwards compatibility then, for whatever it is worth... > > * There may be sequence of execution issues if the widget you reference > > is defined below (further down the file) than the union itself, as in > > the case-determining widget's request parameter may not have been > > processed in time to contribute to the union's case selection process. > > You will need to test this and either document the limitation or > > design some way for this dependecy to reorder the request parameter > > processing to eliminate the problem. > > How is this issue currently resolved? What happens if a union is > defined and then its case-determining widget is defined directly after > it? It seems the dependency you describe would exist regardless of if > the widget lookup uses getChild() or lookupWidget(). The current code does have this limitation. I just mentioned it so everyone would be aware of it, and in case anyone wanted to fix it :) > > * The union widget is being redesigned and will be replaced by "choice" > > described here: http://wiki.cocoondev.org/Wiki.jsp?page=WoodyScratchpad > > The good news is we can probably reuse the good solutions you come up > > with for the union widget when we implement "choice/case". > > That's an interesting read and I'm looking forward very much to the new > choice/case paradigm. The current union is useful but becomes very > unwieldy and limiting if complex selection logic is needed. Agreed. The complexity, inflexibility and poor choice of name triggered the redesign. I still wonder if in the new choice/case design we need to be able to split apart control of which widgets' request parameters are processed versus which widgets get validated. Any thoughts? > How actively is the new choice/case widget being developed? Will it > replace union altogether or supplement it? If switching union to use > lookupWidget() as I originally described turns out to function properly > would a patch be accepted in the official tree? I'm new to the Cocoon > community's development process so please forgive my ignorance. Marc and I were trying to develop it, but we both ran out of time. Anyone is welcome to code it. I would also welcome incremental improvements like lookupWidget to the union widget in CForms, and don't _think_ others would object either. Changes to the copy in Woody (the old frozen version of CForms, only left in to help with migration) would be a harder sell, probably requiring a vote, and might get voted down because Woody is frozen. --Tim Larson
