Tim Larson wrote:
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.
Having started to use it a few weeks ago, I'm currently starting to look at it ;-)
Working from memory alone, I only see three issues:I agree with you, relative to the parent seems the most logical and is
* 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.
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 referenceHow is this issue currently resolved? What happens if a union is
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.
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 :)
Are you sure this limitation exists? In union.readFromRequest(), there's a explicit call readFromRequest on the case widget to ensure it properly got a value.
* The union widget is being redesigned and will be replaced by "choice"That's an interesting read and I'm looking forward very much to the new
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".
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?
Sorry, got lost here: can you elaborate?
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.
+1. And count me in to work on the new choice/case.
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.
Rather than backporting to Woody, I really think people should migrate to CForms. The transition isn't that hard and brings many benefits. Also, I recently made some changes to ensure that the CVS version also works with the 2.1.5 release (and problably some of the previous ones also).
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
