Simple question:
Do we allow actions to wrap call functions in the sitemap?
map:match pattern=xxx
map:act type=myAction
map:call function=myFunction/
/map:act
/map:match
Are there any reasons that make this useful? Maybe with the
authentication framework? I think it is
Hi Chris,
thank you very much, your changes solved the problems perfectly!
The only issue that remains is the
uncaught JavaScript exception: TypeError: calculator is not a
function.
This error only occurs if I use JMeter to test it. If I change the flow
interpreter to JavaScript (old version)
We make progress - thanks to Christopher and Sylvain!
See http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow for more
details.
Cheers,
Reinhard
From: Christopher Oliver
Sylvain Wallez wrote:
snip
Names are one of the most important things in design, since
it's first
through the names that a user goes into a set of classes. Bad names
imply wrong understanding. Abstractions named after a particular
implementation make
Up to now 8 people voted - no negative vote.
Is there a rule how long a voting has to run until it is valid? I
started the
voting last Thursday.
Cheers,
Reinhard
From: Reinhard Pötz
Sent: Monday, July 07, 2003 9:28 AM
To: [EMAIL PROTECTED]
Subject: RE: [RT] Generalizing the flow
From: Christopher Oliver
Sylvain Wallez wrote:
snip
Names are one of the most important things in design, since
it's first
through the names
From: Christopher Oliver
I just modified the remainder of the scratchpad code
including PetStore
and JXForms to use the FOM. I also implemented the FOM
WebContinuation.
However, in order not to break anyone immediately who may be
using them,
I haven't yet modified the
Frank,
Sounds interessting. Please submit them using Bugzilla.
Cheers,
Reinhard
-Original Message-
From: Frank Taffelt [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 1:46 PM
To: [EMAIL PROTECTED]
Subject: interest on Woody extension ?
Hi,
i've made some extension's
From: Andreas Hochsteger
Hi Mike!
I didn't use cocoon in eclipse by myself, but there is some
documentation on the cocoon wiki but I fear that it doesn't
cover your
deployment question:
http://wiki.cocoondev.org/Wiki.jsp?page=LoadInEclipse
+1
I think we don't have to vote on this particular issue. I'm preparing
the vote on the complete flow implementation and will post it within the
next few hours.
Reinhard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Giacomo Pati
Sent: Tuesday,
From: Sylvain.Thevoz
Some questions from a user that has sometimes difficulties to
follow the discussion on the dev list:
What are the different alternatives to XMLForm and what is
the current status of each?
XMLForms will be released with Cocoon 2.1
Digging into the archives I found Stefanos RTs from linkmaps to
flowmaps
from 2001-03-05.[1] He wrote Take a piece of paper, avoid thinking you
are writing an application for the web, so avoid taking into
consideration
technical constraints (like the request/response paradigm, intrinsic
From: Sylvain Thevoz
Hello Reinhard,
What are the advantages if I choose JXForms (Cocoon Control
Flow) instead of XMLForms (Action)?
Only another type of controller. IMO it is more advanced than
the XMLForm actions you have to write otherwise, easier to
implement and maintain.
We
From: Reinhard Pötz
+--+
| Cocoon Advanced Control Flow (in general) |
+--+
+1 for A to G
From: Vadim Gritsenko
Reinhard Pötz wrote:
snip/
Thank you for voting/reading so far (13 items ;-)!
Reinhard,
This doco nicely summarizes what we have so far in the flow. And,
because it is already present, and was already dicussed/voted
some time
ago, what here we
From: Steven Noels
On 9/07/2003 14:37 Reinhard Pötz wrote:
[3] I'm aware of Sylvain's and Marc's proposal on changing
the scope of available controllers. I contacted Sylvain off-list
and the said that they want to come up with a concrete
implementation
From: Christopher Oliver
JXForms supports the latest W3C XForms syntax (although not every
construct). JXForms doesn't use XMLFormTransformer. Instead
it provides
its own generator (JXFormsGenerator) and transformer
(JXFormsTransformer). It uses the same Form object and validation
-Original Message-
From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2003 6:26 PM
To: [EMAIL PROTECTED]
Subject: Re: [Vote] Cocoon Advanced Control Flow
Thank you for voting/reading so far (13 items ;-)!
+1 on everything - I cannot look at all
From: Christopher Oliver
Reinhard Pötz wrote:
From: Christopher Oliver
JXForms supports the latest W3C XForms syntax (although not every
construct). JXForms doesn't use XMLFormTransformer. Instead
it provides
its own generator (JXFormsGenerator) and transformer
From: JD Daniels
Thanks! I think I will go have a look at Hibernate .. that
looks helpful While I wait for FOM to settle down...
stay tuned ... the vote is already running!
Cheers,
Reinhard
From: Jeremy Quinn
On Thursday, July 10, 2003, at 09:04 AM, Reinhard Pötz wrote:
IMO no. I would use Object/Relational mapping tools like OJB
http://db.apache.org/ojb/ or Hibernate
(http://hibernate.bluemars.net).
Is there a wiki somewhere on this type of thing?
http
From: Jeremy Quinn
The problem arises when you wish to use a (brilliant) feature of
Hibernate called 'lazy-initialisation', whereby access to the DB is
only made when you actually ask for Bean Properties.
This is particularly useful when you have large 'graphs' of related
Beans, for
From: Christopher Oliver
I think it would be easiest to move it to its own block. Then
we could
deprecate XMLForm and those who are using it won't get
broken. I'm not
sure how you would merge it with the XMLForm block, anyway. If making
JXForms its own block is ok, then I can do
From: Hugo Burm
Hello,
This dreammode is almost a reality. See the Wiki pages on Hibernate.
Main spoilers are:
- A user can quit in the middle of your function xxx (e.g. by
closing the browser). This will generate a zombie Hibernate
session. Jeremy and Ugo are using a workaround
-Original Message-
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
Sent: Saturday, July 12, 2003 4:27 AM
To: [EMAIL PROTECTED]
Subject: Re: JXForms/XMLForms
Reinhard Pötz wrote:
From: Christopher Oliver
I think it would be easiest to move it to its own block
From: Berin Loritsch
Ugo Cei wrote:
Reinhard Pötz wrote:
As I'm curious I have a technical question:
What's the difference if I read the necessary data in the flow or
some milliseconds latter in the view layer? What do I gain?
You gain a cleaner separation of concerns. I
From: Berin Loritsch
Ugo Cei wrote:
Reinhard Pötz wrote:
As I'm curious I have a technical question:
What's the difference if I read the necessary data in the flow or
some milliseconds latter in the view layer? What do I gain?
You gain a cleaner separation of concerns. I
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Leszek Gawron
Sent: Saturday, July 12, 2003 4:35 PM
To: [EMAIL PROTECTED]
Subject: calling actions from flow
I've been tracking the subject a little but still I do not
get what is the current
Carsten Ziegeler
Hi,
the last time we discussed this topic, we agreed on releasing
2.1 beta 1 this week. I'm planning to start the release
procedure on thursday, 17th. However, instead of naming it
beta 1, I think the rc 1 is slightly better.
Is anything *really* show stopping
From: Geoff Howard
Christopher Oliver wrote:
Yes. That is a feature of the new FOM: it always creates a session.
The
original API had createSession() and removeSession(). Those
functions
were removed from FOM.
I thought that was only supposed to happen after a reference to
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
Reinhard Pötz wrote:
From: Jeremy Quinn
What I do not grok ATM, how does the Hibernate Session automatically
get closed at the appropriate time (ie. after the view layer has
completed)?
IIU the current flow
From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
On Tuesday, July 15, 2003, at 08:28 AM, Christopher Oliver wrote:
Reinhard Pötz wrote:
From: Christopher Oliver [mailto:[EMAIL PROTECTED]
snip
catch (break) {
// a continuation is being captured,
// code
-Original Message-
From: Timothy Larson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 6:13 PM
To: [EMAIL PROTECTED]
Subject: Dynamic pipeline assembly, was Re: [RT] the value of
beingwrong
[EMAIL PROTECTED] 07/15/03 11:48AM
...
(despite the continous call for
From: Stefano Mazzocchi
I have taken a step back and reconsidered the whole discussion about
flow and how to implement it. I still believe that there is a lot of
preconceptions against the use of a scripted flow with continuations,
but diversity is a better value than any
From: Antonio Gallardo
Hi:
I want to try some of the new spectacular technologies
sported in Cocoon :) I also will play with persistent data.
The idea is to create a simple database application using
postgres as storage of persistent data.
After checking all the docs. For forms: I
In the scratchpad we have a CastorTransformer. I'm not sure but I think
that it is a rather long time there. Is it in use and stable and is it
time to move it in the main trunk or can we remove it.
I also found a CastorSourceConverter in the portal framework. What are
the differences? Can they
Could somebody please summarize the status of this discussion and what
you propose how sessions and flows should be connected?
TIA!
Cheers,
Reinhard
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 15, 2003 8:16 PM
To: [EMAIL PROTECTED]
From: Carsten Ziegeler
Reinhard Pötz wrote:
In the scratchpad we have a CastorTransformer. I'm not sure but I
think that it is a rather long time there. Is it in use and
stable and
is it time to move it in the main trunk or can we remove it.
I also found a CastorSourceConverter
From: Carsten Ziegeler
Hi,
I just wanted to check what the status for releasing tomorrow is?
- Petstore is moved into a block (Petstore)
- JXTemplate* is moved into the main trunk
- JXForms is moved into its own block
- flow implementation is IMO stable
- flow is accepted (see vote --
From: Marc Portier
Reinhard Pötz wrote:
JXForms is very close to the XForms standard by the W3C.
The problem
with this standard is that is was written for clients and not for
servers.
I share this view...
On the other hand Woody is IMO a server-side form framework
From: Carsten Ziegeler
Reinhard Pötz wrote:
- the only open point is the flow integration into the sitemap
-- As RC1 should have stable public interfaces we should decide
this ASAP!
Do we need another vote on this or is there consensus
on the list that we
From: Geoff Howard
Reinhard Pötz wrote:
From: Carsten Ziegeler
- the only open point is the flow integration into the sitemap
-- As RC1 should have stable public interfaces we should decide
this ASAP!
I'd suggest that the flow/session discussion is a little
After the balkanization discussion it's time to vote on this last
point before we can release Cocoon 2.1 with stable public interfaces:
Out of Sylvain's RT
[http://archives.real-time.com/pipermail/cocoon-devel/2003-July/016291.h
tml]
So here are the proposed refactorings :
1/ In the flow
From: Reinhard Pötz
[A] The Cocoon Advanced Control Flow provides a controller that is
linked into the sitemap (as **child element** of map:sitemap
.../:
map:flow type=[yourEngine]
[configuration]
/map:flow
This reflects
From: Joerg Heinicke
Because of this upcomming naming discussion I guess the vote
started to
early.
Unfortunatly you are right. After the balkanization discussion I
thought that the people here are satisfied with Marc's/Sylvain's
proposal. In the meantime I'm really tired of waiting for
As I have been confused by all those suggestions you can find a summary
here:
http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration
After the discussion and all your opinions I would prefer:
Integrating the flow processor/engine:
--
map:flows
From: Stephan Michels
On Thu, 17 Jul 2003, Geoff Howard wrote:
Stephan Michels wrote:
- rename WebContinuation to FlowState, and accordingly
WebContinuationManager to FlowStateManager.
Yes, the Continuation represents a state, but to make a clear
difference
IMHO:
I think the verb 'continue' catches a broader consensus:
interactions or use cases are indeed just started(initiated) or
continued, and this also captures the relation the sitemap has to
this.
The noun 'continuation' has gotten a ring of being tied to a
interpreted-language
From: Marc Portier [mailto:[EMAIL PROTECTED]
Hi Mark,
Good remarks!
My list then becomes:
Integrating the flow processor/engine:
- V2 : flows/flow/(@type,@name)/*
+1
Call a flow the first time:
- V2 : initialize/(@flow,@type)/paramaters
+1
Continue a flow: (just added the
-Original Message-
From: Stephan Michels
On Fri, 18 Jul 2003, Reinhard Pötz wrote:
From: Stephan Michels [mailto:[EMAIL PROTECTED]
A: V1
Why do you want implementation details in the element: map:flows
...
map:flow name=java type=atct class
Sorry for the offtopic post ...
I use the eclipse-project build target in order to generate the
necessary Eclipse project files. I like the features of Eclipse that
allow me to jump directly into the Javadoc or the sourcecode of external
libraries. So I wanted to improve the build target and add
I wasn't aware of the status of Environment. It's there
simply because
it was in the original flow implementation. It should be easy
enough to
only expose the features of Environment that are needed (
getURIPrefix()
and getObjectModel()) rather than the entire object. I don't think
Hi Antonio,
I would like to support (review, commits, coding) your efforts as Apache
Cocoon committer because I'm also very interested in this. So I would
looking forward to working together on this.
I would love to see an example using JXForms/Control Flow/OJB/Hibernate
- but I think that is
I want to propose Guido Casper ([EMAIL PROTECTED]) as a new Cocoon
committer.
+1
Cheers,
Reinhard
From: Carsten Ziegeler
There are several problems with xsltc which makes Cocoon in
some scenarios unusable. We have several problem reports and
I know from many customers that they all had to disable xsltc
and use xslt in their environment.
It's ok to have xsltc as the default for
For the actual code see
http://nagoya.apache.org/bugzilla/show_ bug.cgi?id=21900
Marc, why don't you put Apples it into scratchpad?
Cheers,
Reinhard
From: Carsten Ziegeler
I just want to collect opinions how to manage the final release.
Now, it seems 2.1rc1 is relative stable, no real complains,
some minor issues but no showstoppers. From that we could
say: the current cvs is the final version. point. I don't
think we need a rc2.
From: Carsten Ziegeler
I just want to collect opinions how to manage the final release.
Now, it seems 2.1rc1 is relative stable, no real complains,
some minor issues but no showstoppers. From that we could
say: the current cvs is the final version. point. I don't
think we need a rc2.
From: Steven Noels
On 1/08/2003 11:15 Reinhard Pötz wrote:
For the actual code see
http://nagoya.apache.org/bugzilla/show_ bug.cgi?id=21900
Marc, why don't you put Apples it into scratchpad?
Karma request is in process, he isn't listed in the avail file yet.
Ah, thanks! I
Quick question:
Is there a reason why the paginator and the image reader are part of
Cocoon core and not put into blocks?
I'm asking because if you call http://localhost:/samples/ you get
the impression that they are major parts of Cocoon ...
Reinhard
-Original Message-
From: Reinhard Pötz [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 4:21 PM
To: [EMAIL PROTECTED]
Subject: RE: Paginator and ImageReader -- core components?
Responding to Carsten's mail too:
Then (if anybody else is faster) I modify the examples
From: Bruno Dumon
On Fri, 2003-08-01 at 11:15, Reinhard Pötz wrote:
For the actual code see
http://nagoya.apache.org/bugzilla/show_ bug.cgi?id=21900
Marc, why don't you put Apples it into scratchpad?
From the practical side of things: is there much difference between
scratchpad
+1 for now, implementation of real blocks will make us rethink this
again.
Cheers,
Reinhard
-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2003 2:21 PM
To: [EMAIL PROTECTED]
Subject: sendPage, sendPageAndWait uri argument (was Re:
[flow]
From: Bruno Dumon
On Mon, 2003-08-04 at 17:41, Unico Hommes wrote:
On a related note: the cocoon.process(uri,object,outStream) FOM
function is always resolved as cocoon:// . Do you think this should
behave as sendPage(AndWait)?
To provide the necessary context for others: this
From: Steve Krulewitz
[I posted this earlier on the user list, but it might be more
appropriate here given the new-ness of the flow stuff]
Hey folks --
Total newbie here. I've been spending the last week getting
up to speed on Cocoon, especially the new flow stuff and how
it
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
- Cocoon interacts with most data sources, including
filesystems, RDBMS,
- LDAP, native XML databases, and network-based data
sources. It adapts
Does anybody mind if I add SAP R/3 (r) as another option?
Reinhard
From: news [mailto:[EMAIL PROTECTED]
Hi Cocoon developers,
I just updated from 2.1-M1 to 2.1 and noticed that the
inputModuleGetAttribute() function is no longer supported.
Yep
legacy support for cocoon.input(..) and cocoon.act(..)
has not been implemented yet
The purpose of the input
From: Carsten Ziegeler
- removing old FOM (reported by Bruno) : If I followed the
changes correctly,
this has been fixed, right?
The old implementation is still there but I commented it out in
cocoon.xconf. All examples (thanks to Ugo, he ported Linotype) should
use the FOM
From: news [mailto:[EMAIL PROTECTED]
Thank you for your relies to my previous message!
I have another question:
The FOM request does not contain a getRequestURI() method.
In the wiki I've read that URI handling is not supported
because this is not necessary. How should the request
From: Sylvain Wallez
FYI, I just found a JavaScript plugin for Eclipse :
http://sourceforge.net/projects/jseditor/
It does syntax highlighting outline. Not as good as java
support, but
helps writing flow scripts...
I have been using it for more than a month and it works great (only
From: Carsten Ziegeler
Hi,
we have the following entries in bugzilla dealing with XMLForm:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13216
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13795
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15618
Hi Ugo,
From: Ugo Cei
Vadim Gritsenko wrote:
You see... Here lies the problem: everything not wrapped in
js_ should
not be accessible. See all those discussions on less is more and
FOM. Before adding anything into the FOM (adding some new
wrapper)
vote should take place. FOM was
I have two javascript maps:
var map1 = { x : y };
var map2 = { a : b };
I want to copy both maps into one single map. Does anybody have an idea
how I can achieve this?
Cheers,
Reinharde
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 13, 2003 9:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Bugzilla Entries for XMLForm
we have the following entries in bugzilla dealing with XMLForm:
On Behalf Of Andreas Hartmann
Reinhard Pötz wrote:
The FOM request does not contain a getRequestURI() method.
Another question: What is your usecase?
It's about the administration of users, groups etc. in Lenya.
There is an Avalon component AccessControllerResolver which
IMO a bug in Cocoon 2.1 that makes a 2.1.1 necessary, doesn't it? I
think many production environments depend on external sources and many
use proxy firewalls.
Without looking into the sources: could this be a problem with the
httpclient library?
Additionally Sylvains fixes to the I18n
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Friday, August 15, 2003 5:25 PM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: cocoon-2.1/src/webapp/WEB-INF cocoon.xconf
[EMAIL PROTECTED] wrote:
cziegeler2003/08/15 06:42:31
Modified:lib
Reinhard Pötz wrote:
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Modified:lib jars.xml
src/webapp/WEB-INF cocoon.xconf
Added: lib/core excalibur-store-20030815.jar
Removed: lib/core excalibur-store-20030726.jar
Log
Geoff,
Maybe we should change the text: Some parts *are* alpha/beta - see the
unstable blocks.
Reinhard
-Original Message-
From: Geoff Howard [mailto:[EMAIL PROTECTED]
Sent: Monday, August 18, 2003 2:27 AM
To: [EMAIL PROTECTED]
Subject: WARNING.txt
Should it just get deleted
From: Joerg Heinicke
Carsten Ziegeler wrote:
It seems that we should make a 2.1.1 release soon due to some
bugs/problems.
Now, what do you think if we apply/process all patches entered in
bugzilla for 2.1.1 as well? A patch can either be applied
or closed if
it's obsolete
-Original Message-
From: Geoff Howard [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 19, 2003 9:29 PM
To: [EMAIL PROTECTED]
Subject: Classloading from flow (was [Fwd: RE: Calling Java
classes from (JXForms) javascript - can you? how?])
Here's a message from users where a
Without trying it ...
#{parameters.myParameter} should do it ...
Cheers,
Reinhard
-Original Message-
From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 20, 2003 4:35 PM
To: [EMAIL PROTECTED]
Subject: can you reach sitemap params from JXTemplate?
Hi All
From: Christian Haul [mailto:[EMAIL PROTECTED]
Interception in Flowscript
Something that can be modelled very well as an aspect is
authentication/authorization (aka login) because it's not
something that
is part of the webapp (at least, it shouldn't
From: Carsten Ziegeler
Hi,
it seems that we had some minor problems with the 2.1.1
release as stated recently in this list. That's why we didn't
officially announce the release. AFAIK, the problems are all
solved in the current cvs, so I suggest that we make quickly
a 2.1.2 release
From: Alan Gutierrez
* Reinhard Poetz [EMAIL PROTECTED] [2003-10-12 14:06]:
Stefano envisions a system where it is very easy to edit
content using
a WYSIWIG editor (no structured text, no strange XML) for
*everybody*
by simply clicking on an 'edit' button - without having
Geoff Howard wrote:
Ugo Cei wrote:
Antonio Gallardo wrote:
Do you agree with JSDK 1.4 as the lower Java version supported in
Cocoon 2.2?
Here is my +1
-0.5
Even though 1.4 is available for most platforms, and I've been using
it exclusively for quite a long time, I still think there are
Christoph Gaffga wrote:
The idea is to set JSDK 1.4 as the minimum supported JDK supported for the
next major release 2.2 of Cocoon. Currently we are supporting also 1.3 but
seems like few people is using it.
but what about the maximum support JDK? I tried to compile with 1.5beta, but
it
Antonio Gallardo wrote:
Reinhard Pötz dijo:
Did you solve your problems with running ant using JDK? I proposed to
run Ant with a JRE 1.5 and use the 1.5 compiler explicitly in the
javac task of Ant. Did you try this?
It would be fine to already include it in the build system. Soon
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
[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
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
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
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 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
[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
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
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, Tim
1 - 100 of 494 matches
Mail list logo