Thank you for your reply, Tim... > 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. > * 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 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. 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. --Jason
