You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Johnston, Jason" <ja...@Intrado.com> on 2004/06/16 18:53:38 UTC
[CForms] union case as relative path
Hello all--
I'm working with the union widget and have come across a situation where
I need the union's case to be determined by a widget outside the
container in which the union is defined. However it appears that the
case="" can only take the id of a field within the same container as the
union widget itself. This causes problems when the union is defined
within a struct or another union but the case field is defined
elsewhere.
I've dug into the source and found that on line 61 of
src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Union.java it
finds the widget to use for the case by calling:
caseWidget = ((ContainerWidget)getParent()).getChild(caseWidgetId);
It seems to me that replacing .getChild() with .lookupWidget() would
allow the case="" attribute to take a relative path to find the proper
field and allow me to do what I want.
Is this the correct approach? Would it cause other problems I can't see
with my limited knowledge of the code?
Thank you
--Jason
Re: [CForms] union case as relative path
Posted by "Johnston, Jason" <ja...@Intrado.com>.
On Wed, 2004-06-16 at 21:10, Tim Larson wrote:
> > 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.
That's good to hear. We're going to be trying out the getChild ->
lookupWidget change in our development tree, make sure it works like we
need, and give it a good bit of testing. Once we're sure it's a good
fix I'll submit a patch to this list, or is it better to file a bug
report and attach it there?
Things are backed up around here so the whole process may take a week or
two.
Thanks again,
--Jason
Re: [CForms] union case as relative path
Posted by Sylvain Wallez <sy...@apache.org>.
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:
>>>* 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 :)
>
>
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"
>>> 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?
>
>
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 }
Re: [CForms] union case as relative path
Posted by Tim Larson <ti...@keow.org>.
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
Re: [CForms] union case as relative path
Posted by "Johnston, Jason" <ja...@Intrado.com>.
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
Re: [CForms] union case as relative path
Posted by Tim Larson <ti...@keow.org>.
On Wed, Jun 16, 2004 at 10:53:38AM -0600, Johnston, Jason wrote:
<snip/>
> I've dug into the source and found that on line 61 of
> src/blocks/forms/java/org/apache/cocoon/forms/formmodel/Union.java it
> finds the widget to use for the case by calling:
>
> caseWidget = ((ContainerWidget)getParent()).getChild(caseWidgetId);
>
> It seems to me that replacing .getChild() with .lookupWidget() would
> allow the case="" attribute to take a relative path to find the proper
> field and allow me to do what I want.
>
> Is this the correct approach? Would it cause other problems I can't see
> with my limited knowledge of the code?
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.
* 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.
* 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".
--Tim Larson