cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Larson <...@keow.org>
Subject Re: [CForms] union case as relative path
Date Thu, 17 Jun 2004 03:10:08 GMT
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

Mime
View raw message