RE: Goal of the Cocoon TLP
Top Level Project Oz -Original Message- From: Nicolas Toper [mailto:[EMAIL PROTECTED] Sent: Friday, 6 February 2004 3:08 AM To: [EMAIL PROTECTED] Subject: Re: Goal of the Cocoon TLP Hi, I've been following this thread and I've kept wondering: what is a TLP??? :=) nicolas Le Jeudi 05 Février 2004 16:17, Geoff Howard a écrit : Tim Larson wrote: On Thu, Feb 05, 2004 at 08:48:29AM -0500, Stefano Mazzocchi wrote: On 5 Feb 2004, at 06:46, Geoff Howard wrote: Would there be benefit to keeping it more general: XML based application and publishing framework and applications built on and in support of that framework. As for the charter, I agree with Goeff here: we need to keep it general or we would need the board to change our charter every day. So, I would: 1) keep it language neutral: many people dislike java, but they can leave with it if th application is worth the effort (think lisp and emacs, for example) 2) keep it technology neutral (don't say XML/XSLT/SAX/DOM) 3) aim to identify the achitectural principles (modularity, composability, separation of concerns, feature reductionism) If the board requires specific technology names, lets keep the technology choices low-key. We could talk about the architectural principles and then just mention that this is currently implemented using XYZ technologies. This would let us be specific about the technologies in use now, without creating a social contract to always use this same list of technologies. I hope the architectural principles are enough so this document will not have to specifically mention Java, SAX, etc. Like Stefano, I think Cocoon's main purpose is to make it possible to follow good design principles, such as SoC, modularity, etc., and pushing certain technologies is merely a side effect of needing to have an actual implementation of the framework. We should actually be distinguishing carefully here IMO between Cocoon's purpose, and the purpose of the Cocoon TLP. I think we all agree that for the foreseeable future, we should keep Cocoon proper focused on XML pipelines, using Java. If someone wants to make a .Net port of Cocoon and make it work using binary pipelines, using C#, then we could make a sister project within the TLP called Cartoon or something. It would be out of scope for Cocoon to do that, but not necessarily for the TLP. Now, the question in my mind is how far to we want the TLP to be allowed to go away from what we now know of Cocoon? so we don't get a TLP that has to allow projects to do anything with any technology but also don't have undue burden to innovate. Geoff
RE: JXTemplateGenerator / JX macro bug
Chris,
thanks for the info. I need to do some presentation logic
hence the JXTemplateGenerator.
eg: jx:if test=${..}etc../jx:if
I've put the wi:styling stuff on the backburner for the moment.
Were you planning on expanding on the macros any time soon?
Oz
-Original Message-
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
Sent: Friday, 16 January 2004 5:58 PM
To: [EMAIL PROTECTED]
Subject: Re: JXTemplateGenerator / JX macro bug
Yes, you're right. There are some special hacks in
WoodyTemplateTransformer to insert the styling element inside the
expansion of the widget element. Although possible, it would be ugly to
recreate these hacks in a macro. Probably what I would do if I were
planning to fix this is to not use widget.generateSAXFragment() at all,
and replace its behavior with equivalent jx macro code.
Why can't you use WoodyTemplateTransformer?
Regards,
Chris
Oguz Kologlu wrote:
Hi all,
I'm using the latest 2.1 JXTemplateGenerator (cvs tag 1.30) and the JX Macros
Christopher Oliver orignally wrote.
There appears to be a problem with widgets that contains styling information
when the jxtemplategenerator processes them.
eg:
wt:widget id=notes
wi:styling type=textarea rows=4 style=width:100%/
/wt:widget
Will be processed as:
wi:field id=notes required=false/
wi:styling type=textarea rows=4 style=width:100%/
(NOTE: two seperate elements..)
It would appear that:
widget.generateSaxFragment(cocoon.consumer, locale)
in the macro is not outputing the wi:styling .. until
after it has finished processing wt:widget ... which then
results in the field being output as:
input name=notes
instead of the required:
texterea name=notes
Is there some workaround to this?
Thanks,
Oz
See full macro below:
jx:macro name=widget \
targetNamespace=http://apache.org/cocoon/woody/template/1.0; jx:parameter \
name=id/ jx:set var=widget value=${woodyCurrent.getWidget(id)}/
jx:choose
jx:when test=${widget.getSize() != null} !-- repeater --
jx:set var=lastRow value=${widget.getSize() - 1}/
jx:forEach varStatus=loop begin=0 end=${lastRow}
jx:set var=woodyCurrent value=${widget.getRow(loop.index)}/
${row.generateSaxFragment(cocoon.consumer, locale)}
jx:evalBody/
/jx:forEach
/jx:when
jx:otherwise
${widget.generateSaxFragment(cocoon.consumer, locale)}
jx:evalBody/
/jx:otherwise
/jx:choose
/jx:macro
JXTemplateGenerator / JX macro bug
Hi all,
I'm using the latest 2.1 JXTemplateGenerator (cvs tag 1.30) and the JX Macros
Christopher Oliver orignally wrote.
There appears to be a problem with widgets that contains styling information
when the jxtemplategenerator processes them.
eg:
wt:widget id=notes
wi:styling type=textarea rows=4 style=width:100%/
/wt:widget
Will be processed as:
wi:field id=notes required=false/
wi:styling type=textarea rows=4 style=width:100%/
(NOTE: two seperate elements..)
It would appear that:
widget.generateSaxFragment(cocoon.consumer, locale)
in the macro is not outputing the wi:styling .. until
after it has finished processing wt:widget ... which then
results in the field being output as:
input name=notes
instead of the required:
texterea name=notes
Is there some workaround to this?
Thanks,
Oz
See full macro below:
jx:macro name=widget \
targetNamespace=http://apache.org/cocoon/woody/template/1.0; jx:parameter \
name=id/ jx:set var=widget value=${woodyCurrent.getWidget(id)}/
jx:choose
jx:when test=${widget.getSize() != null} !-- repeater --
jx:set var=lastRow value=${widget.getSize() - 1}/
jx:forEach varStatus=loop begin=0 end=${lastRow}
jx:set var=woodyCurrent value=${widget.getRow(loop.index)}/
${row.generateSaxFragment(cocoon.consumer, locale)}
jx:evalBody/
/jx:forEach
/jx:when
jx:otherwise
${widget.generateSaxFragment(cocoon.consumer, locale)}
jx:evalBody/
/jx:otherwise
/jx:choose
/jx:macro
RE: JXTemplateGenerator / JX macro bug
I've been doing some more testing.
I've created a macro for wt:stlying which outputs the
styling information similar to the:
jx:macro name=form-template
targetNamespace=http://apache.org/cocoon/woody/template/1.0;
macro.
I now have:
wt:widget id=notes
wt:styling type=textarea rows=4 style=width:100%/
/wt:widget
which _should_ output to the format:
wi:field id=notes required=false
wi:styling type=textarea rows=4 style=width:100%/
/wi:field
but I still und up with:
wi:field id=notes required=false/
wi:styling type=textarea rows=4 style=width:100%/
It would appear that:
widget.generateSaxFragment(cocoon.consumer, locale)
(see below for full macro) is not actually processing the
wt:styling macro...
Any ideas?
Oz
-Original Message-
From: Oguz Kologlu
Sent: Friday, 16 January 2004 1:37 PM
To: [EMAIL PROTECTED]
Subject: JXTemplateGenerator / JX macro bug
Hi all,
I'm using the latest 2.1 JXTemplateGenerator (cvs tag 1.30) and the JX Macros
Christopher Oliver orignally wrote.
There appears to be a problem with widgets that contains styling information
when the jxtemplategenerator processes them.
eg:
wt:widget id=notes
wi:styling type=textarea rows=4 style=width:100%/
/wt:widget
Will be processed as:
wi:field id=notes required=false/
wi:styling type=textarea rows=4 style=width:100%/
(NOTE: two seperate elements..)
It would appear that:
widget.generateSaxFragment(cocoon.consumer, locale)
in the macro is not outputing the wi:styling .. until
after it has finished processing wt:widget ... which then
results in the field being output as:
input name=notes
instead of the required:
texterea name=notes
Is there some workaround to this?
Thanks,
Oz
See full macro below:
jx:macro name=widget \
targetNamespace=http://apache.org/cocoon/woody/template/1.0; jx:parameter \
name=id/ jx:set var=widget value=${woodyCurrent.getWidget(id)}/
jx:choose
jx:when test=${widget.getSize() != null} !-- repeater --
jx:set var=lastRow value=${widget.getSize() - 1}/
jx:forEach varStatus=loop begin=0 end=${lastRow}
jx:set var=woodyCurrent value=${widget.getRow(loop.index)}/
${row.generateSaxFragment(cocoon.consumer, locale)}
jx:evalBody/
/jx:forEach
/jx:when
jx:otherwise
${widget.generateSaxFragment(cocoon.consumer, locale)}
jx:evalBody/
/jx:otherwise
/jx:choose
/jx:macro
