Hi FirstFridayists,
How do we go with the license change?
The src/java/org/apache/committers/ReplaceLicense.java class from
committers module looks good, but maybe we should try it on a smaller
part of the tree before doing the whole thing.
I could start right away and:
a) tag the 2.1 tree
b)
Bertrand Delacretaz wrote:
All other files were updated by hand as they didn't have a license
before - but perhaps there is an easier way.
Doesn't ReplaceLicense add it if absent? haven't looked yet.
I don't think so. In that case it had to look at the content type
(xml, html,
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Chaps,
The Geronimo project recently performed a migration of all of their
code using a bunch of perl scripts. May be worth looking at if we have
trouble with the below.
The scripts were run by Gianny Damour, and are available to committers
in his home directory, ~gdamour/LicenseMigration/.
Sounds good :)
I used that tool for the java sources of the Pluto project and
it did work very well.
All other files were updated by hand as they didn't have a
license before - but perhaps there is an easier way.
Carsten
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL
Hi,
I don't know, if you had the same experience, but it always feels nasty to
me when I do simple XML bindings, where xml element names and field ids are
always called the same.
Wouldn't it be good to make some attributes optional in the binding
definition?
Here's a partial example from the
Le Vendredi, 5 mars 2004, à 09:26 Europe/Zurich, Carsten Ziegeler a
écrit :
Sounds good :)
Ok, I'll go ahead with the scratchpad then.
I used that tool for the java sources of the Pluto project and
it did work very well.
cool
All other files were updated by hand as they didn't have a
license
I got the same problem even in 2.1.5-dev
Roy Huang
- Original Message -
From: Steve Krulewitz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, March 05, 2004 7:14 AM
Subject: Re: [cforms] Woody template transformer eating namespaced element tags?
I did a little more poking
It's been about a day since the last poll reply came through, i guess
it's either too far down in the newsreader overview for people to still
notice it or maybe just everyone who wanted to vote actually has voted.
The poll :
COCOON : your version here
JDK : your version here
CONTAINER : your
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
wild guess: perhaps
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24793 ?
roy huang wrote:
I got the same problem even in 2.1.5-dev
Roy Huang
- Original Message -
From: Steve Krulewitz [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, March 05, 2004 7:14 AM
Subject: Re:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Le Vendredi, 5 mars 2004, à 09:48 Europe/Zurich, Paul Russell a écrit :
...The Geronimo project recently performed a migration of all of their
code using a bunch of perl scripts. May be worth looking at if we have
trouble with the below
Thanks for the info - committers, note that there is
Thor Heinrichs-Wolpert wrote:
XDoclet is a good generator, but the license is wrong for Apache.
Using straight Introspection can and will expose things that you do not
wish to allow users to alter on the fly.
Unfortunately I'm completely snowed under until March 29th. After that
date I will
hi:
As part of the new licenses work, we also need to add licenses to files
that currently does not have any.
The question is:
What year range use?
1999-2004 or just 2004?
Rememeber the CVS history was lost.
Best Regards,
Antonio Gallardo
Le Vendredi, 5 mars 2004, à 09:18 Europe/Zurich, Bertrand Delacretaz a
écrit :
...I could start right away and:
a) tag the 2.1 tree
b) run ReplaceLicense on the scratchpad only
c) if it compiles, commit and let others check it before doing the
whole tree
FYI, this is done, see
Next, I've now
FYI, this is done, see
I meant see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467;
-Bertrand
Antonio Gallardo wrote:
hi:
As part of the new licenses work, we also need to add licenses to files
that currently does not have any.
The question is:
What year range use?
1999-2004 or just 2004?
Rememeber the CVS history was lost.
Best Regards,
Antonio Gallardo
If we use 1999 we are on
Hi,
In the next few days I want (no promise ;-) to start with
renaming Woody
to CocoonForms. First I want to move the _core_ which means
that I want
to make one simple example run.
namespaces:
http://apache.org/cocoon/woody/definition/1.0
--
Sounds good to me. +1
From your description, I guess you want to add a new block for
Cocoon Forms in parallel to the Woody one, right?
Carsten
-Original Message-
From: Reinhard Pötz [mailto:[EMAIL PROTECTED]
Sent: Friday, March 05, 2004 1:18 PM
To: [EMAIL PROTECTED]
Subject: From
While applying the new license I found out that a complete build with
all blocks does not start, I get a stack overflow.
Stack trace shows repeated calls to JCSStore.parameterize.
After commenting this element in cocoon.xconf, startup is ok:
persistent-store
[EMAIL PROTECTED] wrote:
Hi,
In the next few days I want (no promise ;-) to start with
renaming Woody
to CocoonForms. First I want to move the _core_ which means
that I want
to make one simple example run.
namespaces:
http://apache.org/cocoon/woody/definition/1.0
--
Carsten Ziegeler wrote:
Sounds good to me. +1
From your description, I guess you want to add a new block for
Cocoon Forms in parallel to the Woody one, right?
Yep as it is much work and I'm not sure on all parts if they are
_official_ or not.
--
Reinhard
---BeginMessage---
Hmm, I won't say that it's impossible ;) But I've been hitting the store pretty
heavily today (000's of objects cached) and I've not yet had such a problem, AFAIK it
should only be calling the parameterize once - when it first initialises the store,
although that's defined
Bertrand Delacretaz wrote:
While applying the new license I found out that a complete build with
all blocks does not start, I get a stack overflow.
Stack trace shows repeated calls to JCSStore.parameterize.
After commenting this element in cocoon.xconf, startup is ok:
persistent-store
Le Vendredi, 5 mars 2004, à 13:18 Europe/Zurich, Reinhard Pötz a écrit :
...
namespaces:
packages:
...
classnames:
...
xconf:
...
What do you think?
Quite frankly, I think changing implementation-specific names
(packages, classes) is not worth the hassle.
I'd change just the namespaces
Le Vendredi, 5 mars 2004, à 14:01 Europe/Zurich, Unico Hommes a écrit :
No not related. I've had this before and it is related to a circular
dependency: JCStore - SourceResolver -
RepositorySource/CachingSource - Cache - JCSStore
Try commenting out RepositorySource. I will look into fixing it
On Fri, 2004-03-05 at 13:54, Reinhard Pötz wrote:
Carsten Ziegeler wrote:
Sounds good to me. +1
From your description, I guess you want to add a new block for
Cocoon Forms in parallel to the Woody one, right?
Yep as it is much work and I'm not sure on all parts if they are
Bertrand Delacretaz wrote:
Le Vendredi, 5 mars 2004, à 13:18 Europe/Zurich, Reinhard Pötz a écrit :
...
namespaces:
packages:
...
classnames:
...
xconf:
...
What do you think?
Quite frankly, I think changing implementation-specific names
(packages, classes) is not worth the hassle.
I'd
Le Vendredi, 5 mars 2004, à 14:09 Europe/Zurich, Reinhard Pötz a écrit :
...Changing package or class names is the smallest problem if you use
Eclipse ;-)
sure, but what about docs, samples and people's minds ;-)
...I don't do the whole transformation at once because I know that I
don't have
Bertrand Delacretaz wrote:
Le Vendredi, 5 mars 2004, à 14:09 Europe/Zurich, Reinhard Pötz a écrit :
...Changing package or class names is the smallest problem if you use
Eclipse ;-)
sure, but what about docs, samples and people's minds ;-)
...I don't do the whole transformation at once
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27467.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Reinhard Pötz wrote:
In the next few days I want (no promise ;-) to start with renaming
Woody to CocoonForms. First I want to move the _core_ which means that
I want to make one simple example run.
First of all, let's freeze cocoon woody - so we do not loose any patches
in the process, and
[EMAIL PROTECTED] wrote:
Hi,
In the next few days I want (no promise ;-) to start with renaming Woody to CocoonForms. First I want to move the _core_ which means that I want to make one simple example run.
namespaces:
http://apache.org/cocoon/woody/definition/1.0
--
Unico Hommes wrote:
Unico Hommes wrote:
Corin Moss wrote:
Hi Guys,
I might be getting ahead of myself a bit here, but I'm going to try
and turn off the default MRU store, in favour of the JCS based
persistent store. I'd like to try some tests on performance without
the default MRU - has
On Fri, Mar 05, 2004 at 03:05:38PM +0100, Marc Portier wrote:
Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
Hi,
In the next few days I want (no promise ;-) to start with renaming
Woody to CocoonForms. First I want to move the _core_ which means
that I want to make one simple example run.
Vadim Gritsenko wrote:
Reinhard Pötz wrote:
In the next few days I want (no promise ;-) to start with renaming
Woody to CocoonForms. First I want to move the _core_ which means
that I want to make one simple example run.
First of all, let's freeze cocoon woody - so we do not loose any
[EMAIL PROTECTED] wrote:
Are there other 'forms' types? Maybe you could use cforms
since that is the most often used abbreviation and to set it
apart from other form types.
+1 (although I'm one of those that will miss woody)
Me too, I didn't follow the thread on why
Tim Larson wrote:
On Fri, Mar 05, 2004 at 02:32:21AM +0100, Joerg Heinicke wrote:
wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath
wb:unique-row
wb:value id=myId1 path=myId1/
wb:value id=myId2 path=myId2/
/wb:unique-row
wb:on-bind
wb:value id=field1 path=field1/
On Fri, Mar 05, 2004 at 03:15:56PM +0100, Reinhard P?tz wrote:
Tim Larson wrote:
On Fri, Mar 05, 2004 at 03:05:38PM +0100, Marc Portier wrote:
Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
Hi,
In the next few days I want (no promise ;-) to start with renaming
Woody to CocoonForms. First I
Unico Hommes wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
Unico Hommes wrote:
Corin Moss wrote:
Hi Guys,
I might be getting ahead of myself a bit here, but I'm going to
try and turn off the default MRU store, in favour of the JCS based
persistent store. I'd like to try some tests on
Tim Larson wrote:
On Fri, Mar 05, 2004 at 03:15:56PM +0100, Reinhard P?tz wrote:
Tim Larson wrote:
On Fri, Mar 05, 2004 at 03:05:38PM +0100, Marc Portier wrote:
Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
Hi,
In the next few days I want (no
Geoff Howard wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
Unico Hommes wrote:
Unico Hommes wrote:
Corin Moss wrote:
Hi Guys,
I might be getting ahead of myself a bit here, but I'm going to
try and turn off the default MRU store, in favour of the JCS
based persistent store. I'd like
[EMAIL PROTECTED] wrote:
I could be wrong (that happens often enough), but what if we
eventually
replace Woody/Cocoon Forms with something better? If it is very
different then IMHO just a namespace version change 1.0-2.0, etc. may
not make a lot of sense. A new name may be in order at that
[EMAIL PROTECTED] wrote:
unico 2004/03/05 07:05:02
Modified:src/blocks/scratchpad/java/org/apache/cocoon/components/store
JCSStore.java
Log:
clean up logging and add some TODOs
Revision ChangesPath
1.3 +19 -25
wild guess: perhaps
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24793 ?
No it doesn't look like it. This bug is about missing namespaces and
attributes, not element names. Also, my problem seems to be caused by
the woody template transformer -- if I remove it, everything works fine.
We've had several mysterious issues with the various XSLT processors,
it would be good to have an XSLT test suite to validate our processors
and check for regressions.
Googling led me to XSLTMark [1] but the download link is broken.
Before investigating too much, has anyone used it, or does
Vadim Gritsenko vadim at reverycodes.com writes:
wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath
wb:unique-row
wb:value id=myId1 path=myId1/
wb:value id=myId2 path=myId2/
/wb:unique-row
wb:on-bind
wb:value id=field1 path=field1/
wb:value id=field2
Reinhard Pötz wrote:
Tim Larson wrote:
...
+1 'cforms' instead of just 'forms'
I'm +1 for forms only - as Vadim pointed out, it's Cocoon is
obvious because it's within the Cocoon CVS.
WDOT?
Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a little
chat on IRC and agreed on
Vadim Gritsenko wrote:
Reinhard Pötz wrote:
Tim Larson wrote:
...
+1 'cforms' instead of just 'forms'
I'm +1 for forms only - as Vadim pointed out, it's Cocoon is
obvious because it's within the Cocoon CVS.
WDOT?
Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a
little
I am not in favor of having FormValidatorAction and SimpleFormsTransformer
deprecated. They are lightweight and do the job they were intended to do.
-Original Message-
From: Reinhard Pötz [mailto:[EMAIL PROTECTED]
Sent: Friday, March 05, 2004 4:51 AM
To: [EMAIL PROTECTED]
On 05 Mar 2004, at 16:26, Vadim Gritsenko wrote:
Do we have a consensus now? Please chime in on IRC (somebody will have
to count votes then), or here :-)
+1
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source Java XMLAn Orixo
Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a demo.
Below are our experiences.
As people with different levels of experience are interested in workflow I
will start with a (very) brief
Don't know if my vote counts, just in case: +1
Helma
-Original Message-
From: Steven Noels [mailto:[EMAIL PROTECTED]
Sent: Friday, 05 March 2004 17:01
To: [EMAIL PROTECTED]
Subject: Re: [SUMMARY] From Woody to Cocoon Forms 1.0
On 05 Mar 2004, at 16:26, Vadim Gritsenko wrote:
Reinhard Pötz wrote:
Vadim Gritsenko wrote:
Reinhard Pötz wrote:
Tim Larson wrote:
...
+1 'cforms' instead of just 'forms'
I'm +1 for forms only - as Vadim pointed out, it's Cocoon is
obvious because it's within the Cocoon CVS.
WDOT?
Ok, we (where we stands for Vadim, Tim, Bertrand,
Le Vendredi, 5 mars 2004, à 17:16 Europe/Zurich,
[EMAIL PROTECTED] a écrit :
Don't know if my vote counts, just in case: +1
Thanks!
Only votes from committers are officially counted but we always
appreciate input from everybody.
-Bertrand
[EMAIL PROTECTED] wrote:
Don't know if my vote counts, just in case: +1
Helma
Technically, the vote of a non-committer isn't binding, but your
opinion (and anyone like you) is important and definitely counts.
Always feel free to pipe in.
Geoff
Marc Portier mpo at outerthought.org writes:
Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a
little chat on IRC and agreed on the following:
Block Title: Cocoon Forms, or Cocoon Forms 1.0
Block Name: cforms
Package: org.apache.cocoon.cforms
Namespace:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27188.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Joerg Heinicke wrote:
Vadim Gritsenko vadim at reverycodes.com writes:
wb:repeater id=myRepeaterId parent-path=. row-path=TheRowPath
wb:unique-row
wb:value id=myId1 path=myId1/
wb:value id=myId2 path=myId2/
/wb:unique-row
wb:on-bind
wb:value id=field1 path=field1/
wb:value id=field2
Joerg Heinicke wrote:
Marc Portier mpo at outerthought.org writes:
Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a
little chat on IRC and agreed on the following:
Block Title: Cocoon Forms, or Cocoon Forms 1.0
Block Name: cforms
Package: org.apache.cocoon.cforms
Vadim Gritsenko wrote:
Joerg Heinicke wrote:
Marc Portier mpo at outerthought.org writes:
Ok, we (where we stands for Vadim, Tim, Bertrand, and Rolf) had a
little chat on IRC and agreed on the following:
Block Title: Cocoon Forms, or Cocoon Forms 1.0
Block Name: cforms
Package:
Marc Portier wrote:
Reinhard Pötz wrote:
Vadim Gritsenko wrote:
Reinhard Pötz wrote:
Tim Larson wrote:
+1 'cforms' instead of just 'forms'
I'm +1 for forms only - as Vadim pointed out, it's Cocoon is
obvious because it's within the Cocoon CVS.
WDOT?
Ok, we (where we stands for Vadim,
Hi,
I just made a 'cocoon-2.1.5-dev' build from CVS. But on install I get a
statckoverflow.
I tried an install on tomcat-5.0.19 and jboss 3.2.3 and got the same errors.
I also built without the xmldb block but without success.
Any idea?
Oscar
Here you can find the log files:
Oscar Picasso wrote:
Hi,
I just made a 'cocoon-2.1.5-dev' build from CVS. But on install I get a
statckoverflow.
I tried an install on tomcat-5.0.19 and jboss 3.2.3 and got the same errors.
I also built without the xmldb block but without success.
Any idea?
This should have been fixed with
Hi,
This should have been fixed with a commit about three hours ago. Did you
update after that?
No before. I am going to try it again now.
Oscar
__
Do you Yahoo!?
Yahoo! Search - Find what youre looking for faster
http://search.yahoo.com
Hi,
I found some problems while running jakarta-pluto testsuite under CocoonPortalEngine.
I would like to report them and offer help if needed.
1. test2.jsp: Call to portalContext.getSupportedWindowStates() returns null.
2. test2.jsp: Call to renderRequest.getParameter(testName) returns null
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27456.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Geoff Howard wrote:
[EMAIL PROTECTED] wrote:
Don't know if my vote counts, just in case: +1
Helma
Technically, the vote of a non-committer isn't binding, but your
opinion (and anyone like you) is important and definitely counts.
Always feel free to pipe in.
Geoff
+1
I have been
Sorry for dissapearing after having started this discussion.
Guido Casper wrote:
Daniel Fagerstrom wrote:
So a pipeline for input handling could look like:
g - t* - store - act - [select] - g - t* - s.
I'm still not convinced by this symmetry thing :-)
The requirements for inbound data flow
Alan wrote:
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-23 15:21]:
snip/
XSLT
A MomentoSource would also give a good way to use Momento together with
XSLT and XQuery in Cocoon. Here we need to extend the ordinary use of
sources somewhat, let me explain:
The Source interface provides
Alan wrote:
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-25 15:49]:
Why Cocoon rocks for publishing
---
Cocoon is based on three great ideas: XML-adaptors, XML-pipelines and
the sitemap. Here we will discuss the first two.
If you have N different input formats
Alan wrote:
* Daniel Fagerstrom [EMAIL PROTECTED] [2004-02-25 21:53]:
snip/
XML centric view on input
-
The most important part is not a code change but rather a design
principle: Input handling is controlled from flowscripts, the flowscript
typically adapt various input
Michal Durdina wrote:
Hi,
I found some problems while running jakarta-pluto testsuite
under CocoonPortalEngine. I would like to report them and
offer help if needed.
Great, really appreciated!
1. test2.jsp: Call to
portalContext.getSupportedWindowStates() returns null.
I fixed
--- Oscar Picasso [EMAIL PROTECTED] wrote:
Hi,
This should have been fixed with a commit about three hours ago. Did you
update after that?
No before. I am going to try it again now.
Oscar
Works fine now with the latest from cvs.
I had some Exceptions on startup but they seem to
Marc Portier wrote:
another argument for having [cforms] from my side was that you could
never confuse it with the known english word 'form' that could mean an
HTML form, a paper-form, a whatever formalism or whatnot... in
discussions on these lists, and thus possibly introducing confusion
Reinhard Pötz wrote:
Marc Portier wrote:
Reinhard Pötz wrote:
Vadim Gritsenko wrote:
Reinhard Pötz wrote:
Tim Larson wrote:
+1 'cforms' instead of just 'forms'
I'm +1 for forms only - as Vadim pointed out, it's Cocoon is
obvious because it's within the Cocoon CVS.
WDOT?
Ok, we (where
On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:
Marc Portier wrote:
another argument for having [cforms] from my side was that you could
never confuse it with the known english word 'form' that could mean an
HTML form, a paper-form, a whatever formalism or whatnot... in
Hello,
I want to write my own transformer which iterates over a element and
repeates the content several times. For example:
iterate times=3
pI'm the content/p
/titerate
The content pI'm the content/p should be repeated 3 times, like this:
pI'm the content/p
pI'm the content/p
pI'm
On 05.03.2004 19:23, Oscar Picasso wrote:
I had some Exceptions on startup but they seem to relate to something in the
scratchpad: 'cache.ccf'. What is this?
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27385
There are also a few threads in the archives, have a look for JISP and JCS.
Joerg
You could use the JXTemplate generator to do this without Java
programming:
jx:macro name=iterate
jx:parameter name=times/
jx:forEach start=1 end=${times}
jx:evalBody/
/jx:forEach
/jx:macro
--
Chris
-Original Message-
From: Stephan Coboos [mailto:[EMAIL PROTECTED]
Sent:
On 05.03.2004 19:49, Tim Larson wrote:
Package: org.apache.cocoon.cforms
here I would go forms instead. package naming is where the estate
really is, where class collissions might happen.
I understand how this seems like a good place for the battleground,
but to introduce a new winner it
On 05.03.2004 16:57, Ralph Goers wrote:
I am not in favor of having FormValidatorAction and SimpleFormsTransformer
deprecated. They are lightweight and do the job they were intended to do.
Until now the discussions about deprecating old form stuff where only
about the two existing blocks and
Yes.
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Friday, March 05, 2004 11:49 AM
To: [EMAIL PROTECTED]
Subject:SimpleFormTransformer (was: From Woody to CocoonForms)
On 05.03.2004 16:57, Ralph Goers wrote:
I am not in favor of having
Christopher Oliver wrote:
You could use the JXTemplate generator to do this without Java
programming:
jx:macro name=iterate
jx:parameter name=times/
jx:forEach start=1 end=${times}
jx:evalBody/
/jx:forEach
/jx:macro
--
Chris
Thank you, Chris. But I need to write my own transformer for
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Reinhard Pötz wrote:
Marc Portier wrote:
Reinhard Pötz wrote:
Vadim Gritsenko wrote:
Reinhard Pötz wrote:
Tim Larson wrote:
+1 'cforms' instead of just 'forms'
I'm +1 for forms only - as Vadim pointed out, it's Cocoon is
obvious because it's within the Cocoon CVS.
WDOT?
Ok, we (where
Tim Larson wrote:
On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:
Package: org.apache.cocoon.cforms
here I would go forms instead. package naming is where the estate
really is, where class collissions might happen.
I understand how this seems like a good place for the
Joerg Heinicke wrote:
On 05.03.2004 19:49, Tim Larson wrote:
Package: org.apache.cocoon.cforms
here I would go forms instead. package naming is where the estate
really is, where class collissions might happen.
I understand how this seems like a good place for the battleground,
but to
Stephan Coboos wrote:
Christopher Oliver wrote:
You could use the JXTemplate generator to do this without Java
programming:
jx:macro name=iterate
jx:parameter name=times/
jx:forEach start=1 end=${times}
jx:evalBody/
/jx:forEach
/jx:macro
--
Chris
Thank you, Chris. But I need to write my
Marc Portier wrote:
another +1 to 'cforms' over 'forms'
Doesn't the c stand for Cocoon? If it does, I find it somewhat
redundant, especially in a package name: org.apache.cocoon.forms ==
org.apache.cocoon.cocoon.forms?
And what if someday we develop a new forms framework, do we call it
dforms?
Stefano Mazzocchi wrote:
I would do
http://apache.org/cocoon/cforms/1.0#definition
Stefano, how could you???!!!
http://apache.org/cocoon/forms/1.0#definition
;-P
Vadim
I thought about the same like you, Ugo.
But Tim has a very valid point here:
Try searching goolge for 'forms' and then for 'cforms'
Ugo Cei wrote:
Marc Portier wrote:
another +1 to 'cforms' over 'forms'
Doesn't the c stand for Cocoon? If it does, I find it somewhat
redundant, especially in a
Johan Stuyts wrote:
Experience with workflow at Hippo Webworks
==
At Hippo we used OSWorkflow to implement a workflow solution in a demo.
Below are our experiences.
As people with different levels of experience are interested in workflow
I will start
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27484.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
On 5 Mar 2004, at 21:10, Stefano Mazzocchi wrote:
Tim Larson wrote:
On Fri, Mar 05, 2004 at 01:24:57PM -0500, Stefano Mazzocchi wrote:
Package: org.apache.cocoon.cforms
here I would go forms instead. package naming is where the estate
really is, where class collissions might happen.
I
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18116.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
1 - 100 of 131 matches
Mail list logo
