You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christopher Oliver <re...@verizon.net> on 2004/03/06 17:04:18 UTC
Update CocoonForms flowscript API (was Re: [CocoonForms] Code freeze)
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: 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