You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@apache.org> on 2004/11/02 11:29:28 UTC
[rant] please backport bugfixes to 2.1!
Unusual for me, but time for a rant: I wrote the new CForms widget state
feature in 2.1 and tried to port it to 2.2.
WHAT A PITA!
There are a number or *bug fixes* or minor new features that only exist
in 2.2. Why aren't they ported also to 2.1?
Please, please, consider upgrading both branches at the same time. There
will be some time before 2.2 is out and not everybody runs a snapshot of
trunk.
I remember a time where 2.2 contained only the Cocoon core and no
blocks. Is it no more possible? Ah no: the cforms xconf files now
reference ECM++ selectors. Grrrr... What about reinstalling in 2.2 an
ExtendedComponentSelector that would simply be a subclass of
CocoonServiceSelector. That would allow to share config files between
branches.
Grmbl... lost 2 hours this morning to do the merge, and finally reverted
all :-(
Going to port Tim's swan to widget states so that cforms in 2.2 and 2.1
can be *identical*.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [rant] please backport bugfixes to 2.1!
Posted by Tim Larson <ti...@keow.org>.
On Wed, Nov 03, 2004 at 07:05:49PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >On Wed, Nov 03, 2004 at 06:29:46PM +0100, Sylvain Wallez wrote:
> >>Tim Larson wrote:
> >>>On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
> >>I had a bug while writing widget states because Repeater.RepeaterRow was
> >>redefining getParent() while I was using this.parent. So I made it final
> >>in order to be able to use this.parent throughout AbstractWidget.
> >
> >Ok, but I predict Marc will be unhappy ;)
>
> Why? Does he have special widgets that redefine getParent(). If that's
> the case, we can remove the "final" and replace "this.parent" by
> "getParent()".
Just the general rule of preventing the possibility of
making changes to things that should not be changed, such
as a RepeaterRow's parent, but maybe someone will find
a usecase to justify it :)
> Ok. Something that's seem more and more necessary to me is an "output"
> state that would sit between "disabled" and "invisible", in order to
> render widgets as text and not as disabled inputs without having to use
> styling type="output".
Yes, lets start by adding that, and see where that gets us.
> You already told us about this idea, and it seems to me much more
> general than CForms. However, I also understand that you may want to use
> CForms as a playground for this experiment. But doing it in the main dev
> line when we are trying to achieve stable state for CForms is IMO dangerous.
>
> So whiteboard/scratchpad seems a good idea. Remember: flowscript started
> there ;-)
I have no problem with this, as long as it is ok with others
for me to clone cforms in the whiteboard for this purpose.
--Tim Larson
Re: [rant] please backport bugfixes to 2.1!
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
>On Wed, Nov 03, 2004 at 06:29:46PM +0100, Sylvain Wallez wrote:
>
>
>>Tim Larson wrote:
>>
>>
>>>On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
>>>I am working on the port now and have it almost finished,
>>>
>>>
>>Buhooo... I missed your post and am also almost finished :-(((
>>
>>
>
>:(
>
>
>
>>>but I have a few questions about some recent changes that
>>>the commit comments did not make clear to me:
>>>
>>>AbstractWidget.java
>>> From: public Widget getParent()
>>> To: public final Widget geParent()
>>>
>>>
>>I had a bug while writing widget states because Repeater.RepeaterRow was
>>redefining getParent() while I was using this.parent. So I made it final
>>in order to be able to use this.parent throughout AbstractWidget.
>>
>>
>
>Ok, but I predict Marc will be unhappy ;)
>
>
Why? Does he have special widgets that redefine getParent(). If that's
the case, we can remove the "final" and replace "this.parent" by
"getParent()".
>>>Could you explain what these changes are for, and then
>>>I can finish the porting.
>>>
>>>
>>Mmmh... I nearly finished it on my side... how do we proceed? I'm ready
>>to finish that job if you don't mind.
>>
>>
>
>Please go ahead and commit, then I will comment if necessary.
>
>
Okay!
>>Note that there are some new features in 2.2 that I wouldn't like to be
>>ported now to 2.1 as I'm not very happy with them and would like some
>>discussion about them:
>>- the get/setProcessRequest() stuff which seems to overlap with widget
>>states
>>
>>
>
>Yeah, I did not think that design was ready either...but we may need
>to expand widget states (tm) a little bit, but I will see after your
>commit.
>
>
Ok. Something that's seem more and more necessary to me is an "output"
state that would sit between "disabled" and "invisible", in order to
render widgets as text and not as disabled inputs without having to use
styling type="output".
>>- the new "choose/when" statement in EffectWidgetReplacingPipe: for
>>complex control structures, we have template languages like JTXG and
>>XSP. It doesn't seem good to me that every transformer reinvents it's
>>own control structure language.
>>
>>
>
>There is reason to this madness, if you will just bear with me
>for a bit. I will hold off on porting that to BRANCH_2_1_X.
>
>I have a plan, an experiment, but if it is too disruptive for
>the dev line (svn trunk) then I could move it to the whiteboard.
>It involves compiled templates and transformers (yes, I figured
>out an efficient way to compile and cache transformer-templates)
>with fairly human-friendly syntax, view "widgets", and parallel
>structure between the binding, model, and templates, including
>things like having choose/when being in all three (as a more
>functional, flexible replacement for union/case). WDYT, do I
>need to move this effort to the whiteboard? (not a vote ;)
>
>
You already told us about this idea, and it seems to me much more
general than CForms. However, I also understand that you may want to use
CForms as a playground for this experiment. But doing it in the main dev
line when we are trying to achieve stable state for CForms is IMO dangerous.
So whiteboard/scratchpad seems a good idea. Remember: flowscript started
there ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [rant] please backport bugfixes to 2.1!
Posted by Tim Larson <ti...@keow.org>.
On Wed, Nov 03, 2004 at 06:29:46PM +0100, Sylvain Wallez wrote:
> Tim Larson wrote:
> >On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
> >I am working on the port now and have it almost finished,
>
> Buhooo... I missed your post and am also almost finished :-(((
:(
> >but I have a few questions about some recent changes that
> >the commit comments did not make clear to me:
> >
> > AbstractWidget.java
> > From: public Widget getParent()
> > To: public final Widget geParent()
> >
> >
>
> I had a bug while writing widget states because Repeater.RepeaterRow was
> redefining getParent() while I was using this.parent. So I made it final
> in order to be able to use this.parent throughout AbstractWidget.
Ok, but I predict Marc will be unhappy ;)
> > Field.java
> > From: super validate
> > To: super validate && widget != null
> >
> >
>
> That's "value != null". This check is required as "old-style validators"
> (the ones that were inside fd:datatype) assume a non-null value and this
> was therefore leading to NPEs.
Ok, thanks for explaining.
> >Could you explain what these changes are for, and then
> >I can finish the porting.
>
> Mmmh... I nearly finished it on my side... how do we proceed? I'm ready
> to finish that job if you don't mind.
Please go ahead and commit, then I will comment if necessary.
> Note that there are some new features in 2.2 that I wouldn't like to be
> ported now to 2.1 as I'm not very happy with them and would like some
> discussion about them:
> - the get/setProcessRequest() stuff which seems to overlap with widget
> states
Yeah, I did not think that design was ready either...but we may need
to expand widget states (tm) a little bit, but I will see after your
commit.
> - the new "choose/when" statement in EffectWidgetReplacingPipe: for
> complex control structures, we have template languages like JTXG and
> XSP. It doesn't seem good to me that every transformer reinvents it's
> own control structure language.
There is reason to this madness, if you will just bear with me
for a bit. I will hold off on porting that to BRANCH_2_1_X.
I have a plan, an experiment, but if it is too disruptive for
the dev line (svn trunk) then I could move it to the whiteboard.
It involves compiled templates and transformers (yes, I figured
out an efficient way to compile and cache transformer-templates)
with fairly human-friendly syntax, view "widgets", and parallel
structure between the binding, model, and templates, including
things like having choose/when being in all three (as a more
functional, flexible replacement for union/case). WDYT, do I
need to move this effort to the whiteboard? (not a vote ;)
--Tim Larson
Re: [rant] please backport bugfixes to 2.1!
Posted by Sylvain Wallez <sy...@apache.org>.
Tim Larson wrote:
>On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
>
>
>>Unusual for me, but time for a rant: I wrote the new CForms widget state
>>feature in 2.1 and tried to port it to 2.2.
>>
>>WHAT A PITA!
>>
>>There are a number or *bug fixes* or minor new features that only exist
>>in 2.2. Why aren't they ported also to 2.1?
>>
>>Please, please, consider upgrading both branches at the same time. There
>>will be some time before 2.2 is out and not everybody runs a snapshot of
>>trunk.
>>
>>
><snip/>
>
>
>>Grmbl... lost 2 hours this morning to do the merge, and finally reverted
>>all :-(
>>
>>
>
>Very sorry that you lost time :( I had not ported my changes
>to 2_1_x yet because I was not sure they were ready, but
>addmittedly there were some bugfixes included that I should
>have ported immediately.
>
>I am working on the port now and have it almost finished,
>
>
Buhooo... I missed your post and am also almost finished :-(((
>but I have a few questions about some recent changes that
>the commit comments did not make clear to me:
>
> AbstractWidget.java
> From: public Widget getParent()
> To: public final Widget geParent()
>
>
I had a bug while writing widget states because Repeater.RepeaterRow was
redefining getParent() while I was using this.parent. So I made it final
in order to be able to use this.parent throughout AbstractWidget.
> Field.java
> From: super validate
> To: super validate && widget != null
>
>
That's "value != null". This check is required as "old-style validators"
(the ones that were inside fd:datatype) assume a non-null value and this
was therefore leading to NPEs.
> Repeater.java
> In inner class RepeaterRow
> From: getParent() returns Repeater.this and
> setParent() throws a RuntimeException
> To: setParent(Repeater.this)
> (This seems to be caused by the AbstractWidget
> change above.)
>
>
Exactly.
>Could you explain what these changes are for, and then
>I can finish the porting.
>
>
Mmmh... I nearly finished it on my side... how do we proceed? I'm ready
to finish that job if you don't mind.
Note that there are some new features in 2.2 that I wouldn't like to be
ported now to 2.1 as I'm not very happy with them and would like some
discussion about them:
- the get/setProcessRequest() stuff which seems to overlap with widget
states
- the new "choose/when" statement in EffectWidgetReplacingPipe: for
complex control structures, we have template languages like JTXG and
XSP. It doesn't seem good to me that every transformer reinvents it's
own control structure language.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [rant] please backport bugfixes to 2.1!
Posted by Tim Larson <ti...@keow.org>.
On Tue, Nov 02, 2004 at 09:12:28PM +0000, Tim Larson wrote:
> I am working on the port now and have it almost finished,
> but I have a few questions about some recent changes that
> the commit comments did not make clear to me:
>
> AbstractWidget.java
> From: public Widget getParent()
> To: public final Widget geParent()
> Field.java
> From: super validate
> To: super validate && widget != null
> Repeater.java
> In inner class RepeaterRow
> From: getParent() returns Repeater.this and
> setParent() throws a RuntimeException
> To: setParent(Repeater.this)
> (This seems to be caused by the AbstractWidget
> change above.)
>
> Could you explain what these changes are for, and then
> I can finish the porting.
Sorry for the quick, unformatted email; I had to rush out to vote.
(hmm, perhaps not "early and often" enough to have an effect ;(
What I was wondering was why getParent was made final in
AbstractWidget, thus causing RepeaterRow to not be able
to enforce that its parent cannot be changed.
And I was wondering if this from Field.java in BRANCH_2_1_X:
VVVVVVVVVVVVVVVV
if (super.validate() && value != null) {
// New-style validators were successful. Check the old-style ones.
this.validationError = getDatatype().validate(value, new ExpressionContextImpl(this));
}
...needs to be ported to the trunk? I think so, but my mind is
a little cloudy from all the porting and I wanted to doublecheck.
--Tim Larson
Re: [rant] please backport bugfixes to 2.1!
Posted by Tim Larson <ti...@keow.org>.
On Tue, Nov 02, 2004 at 11:29:28AM +0100, Sylvain Wallez wrote:
> Unusual for me, but time for a rant: I wrote the new CForms widget state
> feature in 2.1 and tried to port it to 2.2.
>
> WHAT A PITA!
>
> There are a number or *bug fixes* or minor new features that only exist
> in 2.2. Why aren't they ported also to 2.1?
>
> Please, please, consider upgrading both branches at the same time. There
> will be some time before 2.2 is out and not everybody runs a snapshot of
> trunk.
<snip/>
> Grmbl... lost 2 hours this morning to do the merge, and finally reverted
> all :-(
Very sorry that you lost time :( I had not ported my changes
to 2_1_x yet because I was not sure they were ready, but
addmittedly there were some bugfixes included that I should
have ported immediately.
I am working on the port now and have it almost finished,
but I have a few questions about some recent changes that
the commit comments did not make clear to me:
AbstractWidget.java
From: public Widget getParent()
To: public final Widget geParent()
Field.java
From: super validate
To: super validate && widget != null
Repeater.java
In inner class RepeaterRow
From: getParent() returns Repeater.this and
setParent() throws a RuntimeException
To: setParent(Repeater.this)
(This seems to be caused by the AbstractWidget
change above.)
Could you explain what these changes are for, and then
I can finish the porting.
> Going to port Tim's swan to widget states so that cforms in 2.2 and 2.1
> can be *identical*.
>From a very quick look at the widget states implementation,
I suspect a few problems will come up while doing this,
but I am sure we can resolve them without too much trouble.
--Tim Larson
RE: [rant] please backport bugfixes to 2.1!
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
>
> I remember a time where 2.2 contained only the Cocoon core
> and no blocks. Is it no more possible? Ah no: the cforms
> xconf files now reference ECM++ selectors. Grrrr... What
> about reinstalling in 2.2 an ExtendedComponentSelector that
> would simply be a subclass of CocoonServiceSelector. That
> would allow to share config files between branches.
>
There are other changes as well - internal processing etc. But
the good news is: you can use the ExtendedComponentSelector
in the configuration, although the class doesn't exist. ECM++
will automatically use the CocoonServiceSelector. This is
for compatibility.
Carsten