You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Pötz <re...@apache.org> on 2004/03/06 16:47:01 UTC

[CocoonForms] Code freeze

In the next few days I'm going to rename Woody to Cocoon Forms. So 
please don't commit into the Woody block any more as it will be removed 
afterwards. Expect results by the end of next week (and not before 
Monday afternoon).

Here are the new names (latest status summing up the recent discussion):

 Block Title: Cocoon Forms
 Block Name:  forms
 Package:     org.apache.cocoon.forms
 Namespace:   http://apache.org/cocoon/forms/1.0#definition 
<http://apache.org/cocoon/forms/1.0#definition>
 NS Prefix:   fd

Reinhard

Re: [CocoonForms] END of code freeze

Posted by Reinhard Pötz <re...@apache.org>.
Joerg Heinicke wrote:

> On 09.03.2004 12:10, Reinhard Pötz wrote:
>
>> The new forms block is in CVS and Woody removed. Open tasks:
>> - update Unit tests by somebody who is familiar with them
>> - update Wiki pages (maybe we can do this automatically in some
>>   parts with moving Wiki to Apache infrastructure)
>> - test the new 'forms' block and the Petstore whether everything 
>> works well
>> - test the Ant task that updates Woody projects
>
>
> Though there is a bit of work needed for the stylesheets, JS, and CSS 
> (e.g. 'woody-submit-id') thanks you very much for your massive effort.
>
> Joerg
>
Yes sorry, forget to mention those things. I wanted to unfreeze Cocoon 
Forms ASAP.

-- 
Reinhard

Re: [CocoonForms] END of code freeze

Posted by Joerg Heinicke <jo...@gmx.de>.
On 09.03.2004 12:10, Reinhard Pötz wrote:

> The new forms block is in CVS and Woody removed. Open tasks:
> - update Unit tests by somebody who is familiar with them
> - update Wiki pages (maybe we can do this automatically in some
>   parts with moving Wiki to Apache infrastructure)
> - test the new 'forms' block and the Petstore whether everything works well
> - test the Ant task that updates Woody projects

Though there is a bit of work needed for the stylesheets, JS, and CSS 
(e.g. 'woody-submit-id') thanks you very much for your massive effort.

Joerg

Re: [CocoonForms] END of code freeze

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Steven Noels wrote:

> On 09 Mar 2004, at 12:10, Reinhard Pötz wrote:
>
>> The new forms block is in CVS and Woody removed.
>
>                                    ^^^^^^^^^^^^^^
>
> Ouch - are you sure this was needed *immediately after* the renaming? 
> I know this eventually needed to be done, but I would have given the 
> old block a grace period of at least two weeks.


Why? We have "cvs -D yesterday" :-)

Vadim

Re: [CocoonForms] END of code freeze

Posted by Stefano Mazzocchi <st...@apache.org>.
Steven Noels wrote:

> On 09 Mar 2004, at 12:10, Reinhard Pötz wrote:
> 
>> The new forms block is in CVS and Woody removed.
> 
>                                    ^^^^^^^^^^^^^^
> 
> Ouch - are you sure this was needed *immediately after* the renaming? I 
> know this eventually needed to be done, but I would have given the old 
> block a grace period of at least two weeks.

or more!

we are changing this for community dynamics, but we DO NOT want to screw 
our users since we did already release this (even if an alpha block).

As long as everybody understands that that block is going to go away, 
it's safe to leave it there for a few more releases, IMHO.

-- 
Stefano.

[CocoonForms] Woody available again

Posted by Reinhard Pötz <re...@apache.org>.
Sylvain Wallez wrote:

> Bertrand Delacretaz wrote:
>
>> Le Mardi, 9 mars 2004, à 14:53 Europe/Zurich, Steven Noels a écrit :
>>
>>> ...Thanks for your brave effort!
>>
>>
>>
>> Yes, let's not forget this: big THANKS Reinhard for your work!
>
>
>
> Sure: THANKS Reinhard!

You're welcome :-)

>
> Sylvain, wondering how long the "thanks" thread will be ;-)

Can be long enough ;-)

---
Woody is in CVS again.

-- 
Reinhard

Re: [CocoonForms] END of code freeze

Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:

> Le Mardi, 9 mars 2004, à 14:53 Europe/Zurich, Steven Noels a écrit :
>
>> ...Thanks for your brave effort!
>
>
> Yes, let's not forget this: big THANKS Reinhard for your work!


Sure: THANKS Reinhard!

Sylvain, wondering how long the "thanks" thread will be ;-)

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [CocoonForms] END of code freeze

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 9 mars 2004, à 14:53 Europe/Zurich, Steven Noels a écrit :
> ...Thanks for your brave effort!

Yes, let's not forget this: big THANKS Reinhard for your work!
-Bertrand

Re: [CocoonForms] END of code freeze

Posted by Steven Noels <st...@outerthought.org>.
On 09 Mar 2004, at 13:17, Reinhard Pötz wrote:

> Steven Noels wrote:
>
>> On 09 Mar 2004, at 12:10, Reinhard Pötz wrote:
>>
>>> The new forms block is in CVS and Woody removed.
>>
>>                                    ^^^^^^^^^^^^^^
>>
>> Ouch - are you sure this was needed *immediately after* the renaming? 
>> I know this eventually needed to be done, but I would have given the 
>> old block a grace period of at least two weeks.
>>
>> </Steven>
>
> Sorry for this. I thought there was no need for the old block but if 
> somebody needs it we can revert the removal.

No sweat. It's just that I was aware of some production installations 
living very close to the CVS HEAD edge.

Thanks for your brave effort!

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Re: [CocoonForms] END of code freeze

Posted by Jorg Heymans <jh...@domek.be>.
Deprecating before removing seems the best option if you care about the 
installed userbase...  Just keep both of them for one more release so 
people can assess the work involved in migrating.

It's the more "gentle" approach :-)

Jorg

Vadim Gritsenko wrote:
> Guido Casper wrote:
> 
>> Vadim Gritsenko wrote:
>>
>>> But, either way this ends up, I'm -1 on keeping both blocks in the 
>>> release. This means the block must be removed before end of month.
>>
>>
>>
>> Vadim, I (kindly :-) ask you to revert your -1. I have a project using 
>> Woody running on 2.1.4 (not CVS head) and that would force me to 
>> upgrade to 2.1.5 AND CForms at the same time while I would prefer 
>> doing it seperately.
>>
>> +1 to remove it in 2.1.6
> 
> 
> 
> Ummm... If I'm alone in this, I can change to -0 :-)
> WDOT?
> 
> Vadim
> 
>

Re: [CocoonForms] END of code freeze

Posted by Reinhard Pötz <re...@apache.org>.
Torsten Curdt wrote:

> <RT>
> Maybe somehting we should indroduce anyway. An upgrade script!
> Would be cool do have it associated with the changes file.
> </RT>

Yes, I've already started it. See ./tools/targets/upgrade-build.xml. 
Currently only the Woody2CocoonForms upgarde script is in but I hope 
more follows soon. As we're an XML-framework we should have many 
possiblities to support our users with those scripts ;-)

-- 
Reinhard

Re: [CocoonForms] END of code freeze

Posted by Torsten Curdt <tc...@vafer.org>.
Guido Casper wrote:

> Torsten Curdt wrote:
> 
>> Shouldn't one be able to keep the old block
>> and use 2.1.5-dev? ...as an interim solution?
> 
> 
> Yes, I can live with that. But I think it's not a good sign for our 
> users. A user should have a chance to migrate while using a released 
> version.

Hm... I hear you - and agree in general. But AFAIK woody is not yet
marked stable. Plus it's quite a commong thing that you might need
to call an upgrade script after an upgrade. Since we are not deprecating
any functionality I *personally* don't see a big problem in this
particular case ...as long as the upgrade script does all the work.

<RT>
Maybe somehting we should indroduce anyway. An upgrade script!
Would be cool do have it associated with the changes file.
</RT>

cheers
--
Torsten

Re: [CocoonForms] END of code freeze

Posted by Steven Noels <st...@outerthought.org>.
On 09 Mar 2004, at 15:59, Guido Casper wrote:

> Torsten Curdt wrote:
>> Shouldn't one be able to keep the old block
>> and use 2.1.5-dev? ...as an interim solution?
>
> Yes, I can live with that. But I think it's not a good sign for our 
> users. A user should have a chance to migrate while using a released 
> version.

+1 - and I think most of us who have production users will agree with 
that. I don't want to slow down the process, but also don't want to 
lose users by force-feeding them migration work they haven't catered 
for. This is just a temporary solution, and in due time new features 
will emerge from the official cforms branch that will make them do the 
switch at their own pace.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Re: [CocoonForms] END of code freeze

Posted by Guido Casper <gc...@s-und-n.de>.
Torsten Curdt wrote:
> Shouldn't one be able to keep the old block
> and use 2.1.5-dev? ...as an interim solution?

Yes, I can live with that. But I think it's not a good sign for our 
users. A user should have a chance to migrate while using a released 
version.

Guido

Re: [CocoonForms] END of code freeze

Posted by Torsten Curdt <tc...@vafer.org>.
>>> But, either way this ends up, I'm -1 on keeping both blocks in the 
>>> release. This means the block must be removed before end of month.
>>
>>
>>
>> Vadim, I (kindly :-) ask you to revert your -1. I have a project using 
>> Woody running on 2.1.4 (not CVS head) and that would force me to 
>> upgrade to 2.1.5 AND CForms at the same time while I would prefer 
>> doing it seperately.
>>
>> +1 to remove it in 2.1.6
> 
> 
> 
> Ummm... If I'm alone in this, I can change to -0 :-)
> WDOT?

You are not alone ...shipping with both does not
feel very good. Although I do understand Guido's
situation I have to give it a -0.5

Shouldn't one be able to keep the old block
and use 2.1.5-dev? ...as an interim solution?

Since woody got pretty mainstream ...providing
an upgrade script would be good. We more an
more need to care about stuff like this in the
future ...IMHO

cheers
--
Torsten

Re: [CocoonForms] END of code freeze

Posted by Torsten Curdt <tc...@vafer.org>.
> Please guys try my Ant tasks, it should do most of the work for you. If 
> not, report back or fix it pls!

Oh ...you already created an ant task for it?! Great!
Woody-in-production-user, do guys still need a grace
period then?

cheers
--
Torsten

Re: [CocoonForms] END of code freeze

Posted by Reinhard Pötz <re...@apache.org>.
Vadim Gritsenko wrote:

> Guido Casper wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> But, either way this ends up, I'm -1 on keeping both blocks in the 
>>> release. This means the block must be removed before end of month.
>>
>>
>>
>> Vadim, I (kindly :-) ask you to revert your -1. I have a project 
>> using Woody running on 2.1.4 (not CVS head) and that would force me 
>> to upgrade to 2.1.5 AND CForms at the same time while I would prefer 
>> doing it seperately.
>>
>> +1 to remove it in 2.1.6
>
>
>
> Ummm... If I'm alone in this, I can change to -0 :-)
> WDOT?

I would have(ääähm I have) removed it now but I haven't thought of those 
who use the ParanoidCocoonServlet and refer directly to Cocoon CVS. I 
think we should give them some time but finally I want it to be removed. 
Simply, it doesn't make sense to have two versions in a *CVS*.

Please guys try my Ant tasks, it should do most of the work for you. If 
not, report back or fix it pls!

So I'm +1 releasing Cocoon 2.1.5 with a deprecated Woody and a big 
warning in the release notes and Cocoon 2.1.6 shouldn't contain Woody 
any more.
(Especially those who always use the latest features of CocoonForms will 
upgrade to the latest version because development simply goes on ;-)

-- 
Reinhard

Re: [CocoonForms] END of code freeze

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Guido Casper wrote:

> Vadim Gritsenko wrote:
>
>> But, either way this ends up, I'm -1 on keeping both blocks in the 
>> release. This means the block must be removed before end of month.
>
>
> Vadim, I (kindly :-) ask you to revert your -1. I have a project using 
> Woody running on 2.1.4 (not CVS head) and that would force me to 
> upgrade to 2.1.5 AND CForms at the same time while I would prefer 
> doing it seperately.
>
> +1 to remove it in 2.1.6


Ummm... If I'm alone in this, I can change to -0 :-)
WDOT?

Vadim

Re: [CocoonForms] END of code freeze

Posted by Guido Casper <gc...@s-und-n.de>.
Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
> 
>> Reinhard Pötz wrote:
> 
> 
> ...
> 
>>> Sorry for this. I thought there was no need for the old block but if 
>>> somebody needs it we can revert the removal.
>>
>>
>>
>> Oh yes, *please*, *please*, because this instantly breaks all 
>> applications that use woody and the latest CVS !!!!
> 
> 
> 
> I'm missing something... Don't use the latest CVS then, stick to 
> yesterday's version?
> 
> But, either way this ends up, I'm -1 on keeping both blocks in the 
> release. This means the block must be removed before end of month.

Vadim, I (kindly :-) ask you to revert your -1. I have a project using 
Woody running on 2.1.4 (not CVS head) and that would force me to upgrade 
to 2.1.5 AND CForms at the same time while I would prefer doing it 
seperately.

+1 to remove it in 2.1.6

Guido

Re: [CocoonForms] END of code freeze

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Sylvain Wallez wrote:

> Reinhard Pötz wrote:

...

>> Sorry for this. I thought there was no need for the old block but if 
>> somebody needs it we can revert the removal.
>
>
> Oh yes, *please*, *please*, because this instantly breaks all 
> applications that use woody and the latest CVS !!!!


I'm missing something... Don't use the latest CVS then, stick to 
yesterday's version?

But, either way this ends up, I'm -1 on keeping both blocks in the 
release. This means the block must be removed before end of month.

Vadim

Re: [CocoonForms] END of code freeze

Posted by Stefano Mazzocchi <st...@apache.org>.
Bertrand Delacretaz wrote:

> Le Mardi, 9 mars 2004, à 13:57 Europe/Zurich, Sylvain Wallez a écrit :
> 
>> Reinhard Pötz wrote:
>>
>>>
>>> ...Sorry for this. I thought there was no need for the old block but 
>>> if somebody needs it we can revert the removal.
>>
>>
>>
>> ...What would be better, IMO, is to leave the woody block as is, but 
>> mark it as deprecated and clearly indicate the migration in samples.
> 
> 
> Fine, but we must then watch CVS commit messages to make sure the woody 
> block does not diverge from the forms block while both are present.

we can make it read only ;-)

-- 
Stefano.

Re: [CocoonForms] END of code freeze

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 9 mars 2004, à 14:17 Europe/Zurich, Sylvain Wallez a écrit :
> ...Uh? The blocks _will_ diverge as woody is stopped whereas cforms 
> starts its life!

Sorry I wasn't clear. I meant what you understood below ;-)

> A solution to enforce this is to lock the woody directory, either 
> through CVS lock or by removing write permissions on the repository 
> directory.

+1, effectively freezing the woody block, that's what I meant

-Bertrand

Re: [CocoonForms] END of code freeze

Posted by Sylvain Wallez <sy...@apache.org>.
Bertrand Delacretaz wrote:

> Le Mardi, 9 mars 2004, à 13:57 Europe/Zurich, Sylvain Wallez a écrit :
>
>> Reinhard Pötz wrote:
>>
>>>
>>> ...Sorry for this. I thought there was no need for the old block but 
>>> if somebody needs it we can revert the removal.
>>
>>
>> ...What would be better, IMO, is to leave the woody block as is, but 
>> mark it as deprecated and clearly indicate the migration in samples.
>
>
> Fine, but we must then watch CVS commit messages to make sure the 
> woody block does not diverge from the forms block while both are present.


Uh? The blocks _will_ diverge as woody is stopped whereas cforms starts 
its life!

A solution to enforce this is to lock the woody directory, either 
through CVS lock or by removing write permissions on the repository 
directory.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [CocoonForms] END of code freeze

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 9 mars 2004, à 13:57 Europe/Zurich, Sylvain Wallez a écrit :

> Reinhard Pötz wrote:
>>
>> ...Sorry for this. I thought there was no need for the old block but 
>> if somebody needs it we can revert the removal.
>
>
> ...What would be better, IMO, is to leave the woody block as is, but 
> mark it as deprecated and clearly indicate the migration in samples.

Fine, but we must then watch CVS commit messages to make sure the woody 
block does not diverge from the forms block while both are present.

-Bertrand

Re: [CocoonForms] END of code freeze

Posted by Sylvain Wallez <sy...@apache.org>.
Reinhard Pötz wrote:

> Steven Noels wrote:
>
>> On 09 Mar 2004, at 12:10, Reinhard Pötz wrote:
>>
>>> The new forms block is in CVS and Woody removed.
>>

*AAAAAAAAAAAAAAAAAAAAAAARGH* !!!!

>>                                    ^^^^^^^^^^^^^^
>>
>> Ouch - are you sure this was needed *immediately after* the renaming? 
>> I know this eventually needed to be done, but I would have given the 
>> old block a grace period of at least two weeks.
>>
>> </Steven>
>
>
> Sorry for this. I thought there was no need for the old block but if 
> somebody needs it we can revert the removal.


Oh yes, *please*, *please*, because this instantly breaks all 
applications that use woody and the latest CVS !!!!

And I guess many people are in this situation. At least I am.

What would be better, IMO, is to leave the woody block as is, but mark 
it as deprecated and clearly indicate the migration in samples.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: [CocoonForms] END of code freeze

Posted by Reinhard Pötz <re...@apache.org>.
Steven Noels wrote:

> On 09 Mar 2004, at 12:10, Reinhard Pötz wrote:
>
>> The new forms block is in CVS and Woody removed.
>
>                                    ^^^^^^^^^^^^^^
>
> Ouch - are you sure this was needed *immediately after* the renaming? 
> I know this eventually needed to be done, but I would have given the 
> old block a grace period of at least two weeks.
>
> </Steven>

Sorry for this. I thought there was no need for the old block but if 
somebody needs it we can revert the removal.

-- 
Reinhard

Re: [CocoonForms] END of code freeze

Posted by Steven Noels <st...@outerthought.org>.
On 09 Mar 2004, at 12:10, Reinhard Pötz wrote:

> The new forms block is in CVS and Woody removed.
                                    ^^^^^^^^^^^^^^

Ouch - are you sure this was needed *immediately after* the renaming? I 
know this eventually needed to be done, but I would have given the old 
block a grace period of at least two weeks.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source Java & XML            An Orixo Member
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org

Re: [CocoonForms] END of code freeze

Posted by Reinhard Pötz <re...@apache.org>.
Upayavira wrote:

> Reinhard Pötz wrote:
> ...
>
>> The new forms block is in CVS and Woody removed. Open tasks:
>> ...
>> - update Wiki pages (maybe we can do this automatically in some
>>   parts with moving Wiki to Apache infrastructure)
>
>
> I can rename the pages on the new Wiki to be FormBinding instead of 
> WoodyBinding. This would be trivial for me as a part of the conversion.
>
> I won't change the content of the pages though. That would be quite a 
> bit more complicated.
>
> Agree?

Yes of course.

If it helps have a look at cocoon-2.1/tools/targets/upgrade-build.xml 
which contains the upgrade script (Ant) that contains all changes. There 
aren't that many changes (mainly namespaces, some component names and 
flowscript functions) and you might integrate them into your script as well.

-- 
Reinhard

Re: [CocoonForms] END of code freeze

Posted by Upayavira <uv...@upaya.co.uk>.
Bertrand Delacretaz wrote:

> Le Mardi, 9 mars 2004, à 16:39 Europe/Zurich, Upayavira a écrit :
>
>> Reinhard Pötz wrote:
>> ...
>>
>>> The new forms block is in CVS and Woody removed. Open tasks:
>>> ...
>>> - update Wiki pages (maybe we can do this automatically in some
>>>   parts with moving Wiki to Apache infrastructure)
>>
>>
>> I can rename the pages on the new Wiki to be FormBinding instead of 
>> WoodyBinding. This would be trivial for me as a part of the > 
>> conversion.
>>
>> I won't change the content of the pages though. That would be quite a 
>> bit more complicated.
>
>
> Did you store intermediate pages as text files? If so, it would be 
> fairly easy to replace "woody" words by "forms" words with a few sed 
> pipelines.
>
> Much less work than doing it manually later on the wiki IMHO. I can 
> help with the sed stuff if needed (but not before Thursday).

It's all done in Perl. So if someone supplies me with s/Woody/Forms/g; 
statements, I'll happily add them!

Regards, Upayavira

Re: [CocoonForms] END of code freeze

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Mardi, 9 mars 2004, à 16:39 Europe/Zurich, Upayavira a écrit :

> Reinhard Pötz wrote:
> ...
>
>> The new forms block is in CVS and Woody removed. Open tasks:
>> ...
>> - update Wiki pages (maybe we can do this automatically in some
>>   parts with moving Wiki to Apache infrastructure)
>
> I can rename the pages on the new Wiki to be FormBinding instead of 
> WoodyBinding. This would be trivial for me as a part of the > conversion.
>
> I won't change the content of the pages though. That would be quite a 
> bit more complicated.

Did you store intermediate pages as text files? If so, it would be 
fairly easy to replace "woody" words by "forms" words with a few sed 
pipelines.

Much less work than doing it manually later on the wiki IMHO. I can 
help with the sed stuff if needed (but not before Thursday).

WDYT?

-Bertrand

Re: [CocoonForms] END of code freeze

Posted by Upayavira <uv...@upaya.co.uk>.
Reinhard Pötz wrote:
...

> The new forms block is in CVS and Woody removed. Open tasks:
> ...
> - update Wiki pages (maybe we can do this automatically in some
>   parts with moving Wiki to Apache infrastructure)

I can rename the pages on the new Wiki to be FormBinding instead of 
WoodyBinding. This would be trivial for me as a part of the conversion.

I won't change the content of the pages though. That would be quite a 
bit more complicated.

Agree?

Regards, Upayavira

[CocoonForms] END of code freeze

Posted by Reinhard Pötz <re...@apache.org>.
Reinhard Pötz wrote:

> In the next few days I'm going to rename Woody to Cocoon Forms. So 
> please don't commit into the Woody block any more as it will be 
> removed afterwards. Expect results by the end of next week (and not 
> before Monday afternoon).
>
> Here are the new names (latest status summing up the recent discussion):
>
> Block Title: Cocoon Forms
> Block Name:  forms
> Package:     org.apache.cocoon.forms
> Namespace:   http://apache.org/cocoon/forms/1.0#definition 
> <http://apache.org/cocoon/forms/1.0#definition>
> NS Prefix:   fd
>
> Reinhard
>
The new forms block is in CVS and Woody removed. Open tasks:
 - update Unit tests by somebody who is familiar with them
 - update Wiki pages (maybe we can do this automatically in some
   parts with moving Wiki to Apache infrastructure)
 - test the new 'forms' block and the Petstore whether everything works well
 - test the Ant task that updates Woody projects

-- 
Reinhard

Re: Update CocoonForms flowscript API (was Re: [CocoonForms] Code freeze)

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Christopher Oliver wrote:

> Those jx macros have never been checked in. I can check in something 
> after Reinhard is done if you want.


I think it would be beneficial for all. Just yesterday I had a need to 
do labels for one control created out of value of another control... 
It's not possible with transformer, but should be possible with macros.

Vadim


> To fix the problem you mention, a helper Java class has to be written 
> that buffers the widget's end-element event and allows the macro to 
> stream the wi:styling element before it. This class can be called from 
> the macro.
>
> Chris
>
> Vadim Gritsenko wrote:
>
>> Christopher Oliver wrote:
>>
>>> Can we also get rid of the original Woody flowscript API as part of 
>>> this process (and replace it with the v2 version)? The original was 
>>> clearly not ready for prime time.
>>
>>
>>
>>
>> This new API, does it allow creation of JXTemplate macros with proper 
>> wi:styling handling (old set of macros were printing wi:styling 
>> outside of wi:field element)?
>>
>> Vadim
>

Re: Update CocoonForms flowscript API (was Re: [CocoonForms] Code freeze)

Posted by Christopher Oliver <re...@verizon.net>.
Those jx macros have never been checked in. I can check in something 
after Reinhard is done if you want. To fix the problem you mention, a 
helper Java class has to be written that buffers the widget's 
end-element event and allows the macro to stream the wi:styling element 
before it. This class can be called from the macro.

Chris

Vadim Gritsenko wrote:

> Christopher Oliver wrote:
>
>> Can we also get rid of the original Woody flowscript API as part of 
>> this process (and replace it with the v2 version)? The original was 
>> clearly not ready for prime time.
>
>
>
> This new API, does it allow creation of JXTemplate macros with proper 
> wi:styling handling (old set of macros were printing wi:styling 
> outside of wi:field element)?
>
> Vadim
>
>

Re: Update CocoonForms flowscript API (was Re: [CocoonForms] Code freeze)

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Christopher Oliver wrote:

> Can we also get rid of the original Woody flowscript API as part of 
> this process (and replace it with the v2 version)? The original was 
> clearly not ready for prime time.


This new API, does it allow creation of JXTemplate macros with proper 
wi:styling handling (old set of macros were printing wi:styling outside 
of wi:field element)?

Vadim

Re: Update CocoonForms flowscript API (was Re: [CocoonForms] Code freeze)

Posted by Stefano Mazzocchi <st...@apache.org>.
Christopher Oliver wrote:

> Can we also get rid of the original Woody flowscript API as part of this 
> process (and replace it with the v2 version)? The original was clearly 
> not ready for prime time.

+1

-- 
Stefano.

Re: Status on Woody-->CocoonForms renaming

Posted by Joerg Heinicke <jo...@gmx.de>.
On 07.03.2004 17:43, Joerg Heinicke wrote:

> As nagoya seems to down at the moment

Seemed to be a temporary issue with the ISP, other sites did neither 
work. Closing and reopening a connection helped.

Joerg

Re: Status on Woody-->CocoonForms renaming

Posted by Reinhard Pötz <re...@apache.org>.
Bruno Dumon wrote:

>On Sun, 2004-03-07 at 17:43, Joerg Heinicke wrote:
>  
>
>>On 06.03.2004 19:09, Reinhard Pötz wrote:
>>
>>    
>>
>>>The first part is done - which means:
>>>- renaming of all Java classes
>>>- reflect changes within Flowscripts
>>>- first run on updating all samples
>>>
>>>open
>>>- Stylesheet for namespace change and change the
>>>  namespaces
>>>      
>>>
>>As nagoya seems to down at the moment you can find the stylesheet 
>>attached. 2 minor issues does it have:
>>
>>- the old problem of namespace clean up. It copies all namespace 
>>declarations from input to output, so also the old woody one's. Instead 
>>of using <xsl:copy> I could have used <xsl:element>, but you need to 
>>define then all needed namespaces in the stylesheet additionally 
>>starting with i18n, maybe xhtml and so on. I prefer the post-processing 
>>(removing the superflouos woody namespaces) over the pre-processing of 
>>the stylesheet as adding additional namespace declarations is more error 
>>prone than removing the old ones.
>>
>>- whitespace-only text nodes (other must not be there) between comment 
>>nodes are removed when they occur outside the root element. That's a 
>>problem of Xalan. Inside the root element those text nodes are copied to 
>>the output too. I saw this for form1-bind-bean.xml.
>>    
>>
>
>Wouldn't a simple text based search-and-replace be simpler then an XSLT?
>
>  
>
Yes, but I want to provide an Ant task for our users which will do the 
transformation. This can also be the infrastructure for future updates 
between different CocoonForms versions.
Ant the stylesheet written by Jörg looks pretty simple ;-)

-- 
Reinhard

Re: Status on Woody-->CocoonForms renaming

Posted by Bruno Dumon <br...@outerthought.org>.
On Sun, 2004-03-07 at 17:43, Joerg Heinicke wrote:
> On 06.03.2004 19:09, Reinhard Pötz wrote:
> 
> > The first part is done - which means:
> > - renaming of all Java classes
> > - reflect changes within Flowscripts
> > - first run on updating all samples
> > 
> > open
> > - Stylesheet for namespace change and change the
> >   namespaces
> 
> As nagoya seems to down at the moment you can find the stylesheet 
> attached. 2 minor issues does it have:
> 
> - the old problem of namespace clean up. It copies all namespace 
> declarations from input to output, so also the old woody one's. Instead 
> of using <xsl:copy> I could have used <xsl:element>, but you need to 
> define then all needed namespaces in the stylesheet additionally 
> starting with i18n, maybe xhtml and so on. I prefer the post-processing 
> (removing the superflouos woody namespaces) over the pre-processing of 
> the stylesheet as adding additional namespace declarations is more error 
> prone than removing the old ones.
> 
> - whitespace-only text nodes (other must not be there) between comment 
> nodes are removed when they occur outside the root element. That's a 
> problem of Xalan. Inside the root element those text nodes are copied to 
> the output too. I saw this for form1-bind-bean.xml.

Wouldn't a simple text based search-and-replace be simpler then an XSLT?

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org

Re: Status on Woody-->CocoonForms renaming

Posted by Joerg Heinicke <jo...@gmx.de>.
On 06.03.2004 19:09, Reinhard Pötz wrote:

> The first part is done - which means:
> - renaming of all Java classes
> - reflect changes within Flowscripts
> - first run on updating all samples
> 
> open
> - Stylesheet for namespace change and change the
>   namespaces

As nagoya seems to down at the moment you can find the stylesheet 
attached. 2 minor issues does it have:

- the old problem of namespace clean up. It copies all namespace 
declarations from input to output, so also the old woody one's. Instead 
of using <xsl:copy> I could have used <xsl:element>, but you need to 
define then all needed namespaces in the stylesheet additionally 
starting with i18n, maybe xhtml and so on. I prefer the post-processing 
(removing the superflouos woody namespaces) over the pre-processing of 
the stylesheet as adding additional namespace declarations is more error 
prone than removing the old ones.

- whitespace-only text nodes (other must not be there) between comment 
nodes are removed when they occur outside the root element. That's a 
problem of Xalan. Inside the root element those text nodes are copied to 
the output too. I saw this for form1-bind-bean.xml.

Joerg

Status on Woody-->CocoonForms renaming (was: Update CocoonForms flowscript API)

Posted by Reinhard Pötz <re...@apache.org>.
Christopher Oliver wrote:

> Can we also get rid of the original Woody flowscript API as part of 
> this process (and replace it with the v2 version)? The original was 
> clearly not ready for prime time.
>
> -- 
> Chris


The first part is done - which means:
 - renaming of all Java classes
 - reflect changes within Flowscripts
 - first run on updating all samples

open
 - Stylesheet for namespace change and change the
   namespaces
 - tidy up samples (get rid of first flowscript implementation, make
   them easier to understand, ...)
 - woody is used at many places (javadocs, parameter names, client-side 
javascript)
   --> as I want to learn more about CocoonForms I'll use this 
"opportunity" and go
       through all classes and make the updates.

Expect the new block on Wednesday evening (GMT) ;-) as my time the next 
three days is very limited.

-- 
Reinhard

Update CocoonForms flowscript API (was Re: [CocoonForms] Code freeze)

Posted by Christopher Oliver <re...@verizon.net>.
Can we also get rid of the original Woody flowscript API as part of this 
process (and replace it with the v2 version)? The original was clearly 
not ready for prime time.

--
Chris

Reinhard Pötz wrote:

> In the next few days I'm going to rename Woody to Cocoon Forms. So 
> please don't commit into the Woody block any more as it will be 
> removed afterwards. Expect results by the end of next week (and not 
> before Monday afternoon).
>
> Here are the new names (latest status summing up the recent discussion):
>
> Block Title: Cocoon Forms
> Block Name:  forms
> Package:     org.apache.cocoon.forms
> Namespace:   http://apache.org/cocoon/forms/1.0#definition 
> <http://apache.org/cocoon/forms/1.0#definition>
> NS Prefix:   fd
>
> Reinhard
>
>

Re: [CocoonForms] Code freeze

Posted by Reinhard Pötz <re...@apache.org>.
Bertrand Delacretaz wrote:

> Le Samedi, 6 mars 2004, à 16:47 Europe/Zurich, Reinhard Pötz a écrit :
>
>> ...Here are the new names (latest status summing up the recent 
>> discussion):
>> ...Package:     org.apache.cocoon.forms
>> ...NS Prefix:   fd
>
>
> Do we have volunteers to update the docs, samples and wiki as well to 
> account for these changes?
>
> Like I said yesterday, my lazy side would keep the old package name.
> But if someone is willing to sync the docs and wiki, no problem.
>
> -Bertrand
>
AFAIK there are no docs. The samples will be updated by me. So only the 
wiki pages are open

-- 
Reinhard

Re: [CocoonForms] Code freeze

Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Samedi, 6 mars 2004, à 16:47 Europe/Zurich, Reinhard Pötz a écrit :

> ...Here are the new names (latest status summing up the recent 
> discussion):
> ...Package:     org.apache.cocoon.forms
> ...NS Prefix:   fd

Do we have volunteers to update the docs, samples and wiki as well to 
account for these changes?

Like I said yesterday, my lazy side would keep the old package name.
But if someone is willing to sync the docs and wiki, no problem.

-Bertrand