You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by re...@gmx.net on 2003/07/03 15:18:16 UTC
[Vote] Move flow related "packages"
As you probably read at my previous mail "[Flow] Status"
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105722900706900&w=2
there are 3 flow related "packages" which should go to the main trunk:
[Vote 1] JXTemplateGenerator/Transformer
Move the JXTemplateGenerator/Transformer to the main trunk.
You should find some docs here (after a build including the docs):
[http://localhost:8888/docs/userdocs/flow/jxtemplate.html]
[Vote 2] Forms
Replace XMLForms with the JXForms implementation. See
[http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105389102015851&w=2]
Of course we need a migration guide for our users.
[Vote 3] Petstore
a) Move Petstore to the main trunk.
b) The connection to the database is implemented with JavaScript objects.
This should not stop the release as we can implement it e.g. with OJB
in the future.
Here my four +1!
Regards,
Reinhard
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!
Re: [Vote] Move flow related "packages"
Posted by Steven Noels <st...@outerthought.org>.
On 4/07/2003 23:15 Vadim Gritsenko wrote:
>> [Vote 1] JXTemplateGenerator/Transformer
>> Move the JXTemplateGenerator/Transformer to the main trunk. You
>> should find some docs here (after a build including the docs):
>> [http://localhost:8888/docs/userdocs/flow/jxtemplate.html]
>>
>
> +0.5 to core; +0 to block -- I'm not sure what this stuff does but
> sounds like core ;-)
+1 on core - after some more poundering it seems like this wouldn't make
much sense in its own block, and there's many other components still
left in the core that should be moved out if we use the same criteria
it's quite some piece of code, though
>> [Vote 2] Forms
>> Replace XMLForms with the JXForms implementation. See
>> [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105389102015851&w=2]
>> Of course we need a migration guide for our users.
>>
>
> +1 for moving into the block
+1 for block, dunnow about replacing xmlforms (might be a bit too
ambitious?)
>> [Vote 3] Petstore
>>
>> a) Move Petstore to the main trunk.
>>
>
> +1 for moving into the block
+1 - keeps the database.js thing out of the core ;-)
I'm glad we understood each other.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [Vote] Move flow related "packages"
Posted by Joerg Heinicke <jo...@gmx.de>.
Vadim Gritsenko wrote:
> After readin' Steven' clarifications...
>
>> [Vote 1] JXTemplateGenerator/Transformer
>> Move the JXTemplateGenerator/Transformer to the main trunk.
+1 (also core)
>> [Vote 2] Forms
>> Replace XMLForms with the JXForms implementation.
+1 (also block)
>> [Vote 3] Petstore
>> a) Move Petstore to the main trunk.
+ b) The connection to the database is implemented with JavaScript
objects.
+1 (also block)
Joerg
Re: [Vote] Move flow related "packages"
Posted by Vadim Gritsenko <va...@verizon.net>.
After readin' Steven' clarifications...
reinhard_poetz@gmx.net wrote:
>As you probably read at my previous mail "[Flow] Status"
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105722900706900&w=2
>there are 3 flow related "packages" which should go to the main trunk:
>
>
> [Vote 1] JXTemplateGenerator/Transformer
> Move the JXTemplateGenerator/Transformer to the main trunk.
> You should find some docs here (after a build including the docs):
> [http://localhost:8888/docs/userdocs/flow/jxtemplate.html]
>
+0.5 to core; +0 to block -- I'm not sure what this stuff does but
sounds like core ;-)
> [Vote 2] Forms
> Replace XMLForms with the JXForms implementation. See
> [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105389102015851&w=2]
> Of course we need a migration guide for our users.
>
+1 for moving into the block
> [Vote 3] Petstore
>
> a) Move Petstore to the main trunk.
>
+1 for moving into the block
Vadim
Re: [Vote] Move flow related "packages"
Posted by Ricardo Rocha <ri...@apache.org>.
reinhard_poetz@gmx.net wrote:
> [Vote 1] JXTemplateGenerator/Transformer
> Move the JXTemplateGenerator/Transformer to the main trunk.
+1
> [Vote 2] Forms
> Replace XMLForms with the JXForms implementation. See
+1
> [Vote 3] Petstore
>
> a) Move Petstore to the main trunk.
+1
> b) The connection to the database is implemented with JavaScript objects.
> This should not stop the release as we can implement it e.g. with OJB
> in the future.
+1
Yes all the way
Re: [Vote] Move flow related "packages"
Posted by re...@gmx.net.
> reinhard_poetz@gmx.net wrote:
>
> >From: Steven Noels
> >
> >
> >
> >>It's some 120K of code being added to the core. Syntactical sugar for
> >>the flow in the sitemap is essentially orthogonal to
> >>JXTransformer/-Generator (and agreed upon IIUC), but moving this into
> >>its own block might grow a better community wrt. documentation, coherent
> >>samples and support.
> >>
> >>
> >
> >After sending the mail I thought the same. So I'm +1 that the
> >JXTemplateGenerator/Transformer, all flow examples, the flow
> documentation
> >and the Petstore go into this new "fow" block.
> >
> >
>
> We already voted that flow is the very important part for the Cocoon and
> is stay in the core. Why sudden move?
I know that there has been a vote on this. Here we talk about additional
stuff and cocoon.jar is already very large. On the other hand this additional
stuff gives you "a first impression" on what control flow is about and if we
put it into a block it may appear less important. And this additional stuff
(JXTemplateGenerator) is at the moment the best way to implement the view of
flow applications.
So my conculsion: IMO we should discuss these things after a release because
the 14th (beta1) is very close and the upcoming blocks will change a lot. So
Vadim you are right, we should respect the result of this vote and change
things in the future and not now (=until we released 2.1).
Cheers,
Reinhard
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!
Re: [Vote] Move flow related "packages"
Posted by Steven Noels <st...@outerthought.org>.
On 4/07/2003 16:40 Vadim Gritsenko wrote:
> We already voted that flow is the very important part for the Cocoon and
> is stay in the core. Why sudden move?
I'm not suggesting to move anything 'out' of the core, but I'm reluctant
to move new stuff into the core build which isn't absolutely necessary,
especially now that we finally have a manageble and componentized build
system wth blocks and all that. So I'm +1 on the FOM and related core
flow stuff being added to the care, but would like to see some
consideration before simply dropping the PetStore in the core. Ditto for
JXForms to give some examples (but since XMLForm is already in its own
block , I guess jxform isn't exactly a problem).
JXTransformer/-Generator I don't know, except that it's quite some code.
A block is *not* a second-class citizen in Cocoon. It's a polite way of
providing people with they stuff *they* choose to use, and nothing else.
There's plenty of users out there who use the authentication-fw for
example, still it's a block.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [Vote] Move flow related "packages"
Posted by Vadim Gritsenko <va...@verizon.net>.
reinhard_poetz@gmx.net wrote:
>From: Steven Noels
>
>
>
>>It's some 120K of code being added to the core. Syntactical sugar for
>>the flow in the sitemap is essentially orthogonal to
>>JXTransformer/-Generator (and agreed upon IIUC), but moving this into
>>its own block might grow a better community wrt. documentation, coherent
>>samples and support.
>>
>>
>
>After sending the mail I thought the same. So I'm +1 that the
>JXTemplateGenerator/Transformer, all flow examples, the flow documentation
>and the Petstore go into this new "fow" block.
>
>
We already voted that flow is the very important part for the Cocoon and
is stay in the core. Why sudden move?
Vadim
Re: [Vote] Move flow related "packages"
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Vendredi, 4 juil 2003, à 13:20 Europe/Zurich, reinhard_poetz@gmx.net
a écrit :
> ...After sending the mail I thought the same. So I'm +1 that the
> JXTemplateGenerator/Transformer, all flow examples, the flow
> documentation
> and the Petstore go into this new "fow" block....
Can't JXTemplateGenerator/Transformer live in its own block, separate
from the samples?
If all of the Flow subsystem moves to its own block later, IMHO we
could then have the following blocks:
flow
flow-samples (assuming there are many of them, else put them in flow)
petstore (separate, as IIRC it also demonstrates several template
systems)
jx
I think making more blocks makes it easier to understand what is what.
-Bertrand
Re: [Vote] Move flow related "packages"
Posted by re...@gmx.net.
From: Steven Noels
> It's some 120K of code being added to the core. Syntactical sugar for
> the flow in the sitemap is essentially orthogonal to
> JXTransformer/-Generator (and agreed upon IIUC), but moving this into
> its own block might grow a better community wrt. documentation, coherent
> samples and support.
After sending the mail I thought the same. So I'm +1 that the
JXTemplateGenerator/Transformer, all flow examples, the flow documentation
and the Petstore go into this new "fow" block.
So the sitemap related classes, the interpreter and the rhino-continuations
library
stay in the core until we refactor the core with the blocks implementation
we hopefully start soon after the 2.1 release.
>
> > The Petstore could move to the flow examples.
>
> I'd like to see this being put into its own (perhaps flow-centric
> sample-only) block.
see above
>
> > About the JXForms I'm not sure at the moment. Of course it should go
> > into it's own block and IMO it would be best if they go into the
> > XMLForms block. This would not confuse our users and from a technical
> > point of view it is also correct because AFAIK JXForms are only a
> > wrapper to XMLForms to make it easier to use them from within your flow
> > scripts. And so the XMLForms action (probably it must be rewritten in
> > some parts) is still available for all people who have already used the
> > unreleased XMLForms or for people who do not want to rely on the flow.
> >
> > What do you think?
>
> This Form stuff is troubling me more and more, but I can't see ATM how
> we can consolidate easily while maintaining backwards compatibility &
> offering an abundance of choice. It's not only about XMLForms and
> JXForms, it's also about Woody (which might also be integrated with the
> Flow in the future), and various other, smaller Form-related actions and
> components dispersed across Cocoon CVS.
>
> Part of myself feels like axing and actively deprecating older (and less
> actively used) Form frameworks, and demanding some sort of collaboration
> between the various Form frameworks. But maybe Darwin will do that for
> us. Then again, not believing in fate and all that, I'm sure we can be
> masters of our own destiny.
>
> But as Bruno, sitting next to me, is suggesting, is that there's quite
> some other areas of functionality overlap & duplication in Cocoon, and
> apparently only Forms is enough of a common concern so that people
> actually care about consolidation. Basides the story behind XMLForms, of
> course, which sadly reflects now in the last column of
>
http://sourceforge.net/project/stats/index.php?report=months&group_id=18425
>
> I'm just very careful about all this because I see now what harm the
> dramatic overselling of XMLForms is causing us ATM.
What do we have now?
- Ivelin implemented XMLForms and after some time we moved them into
its own block.
- After some time Ivelin decided to start xmlform.org. This step has
not led to the success he had expected and Christopher decided
that he doesn't want JXForms depend on an external community.
- Bruno started another, very different form framework some month
ago. It doesn't follow any spec and is currently alpha.
So what should we do?
I think it is very easy to integrate XMLForms and JXForms because
a look into the sources showed me that they are nearly the same. The big
difference is the controller but this part is plugable and
a matter of taste whether you would like the control flow or an
action to control your forms application.
So I'm +1 to have one block (I would call it XMLForms) and
this is a combination of both (the 'old' XMLForms block and JXForms)
and contains one example controlling the form application with
a control flow and another with the XMLFormsAction. See also
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105389102015851&w=2
--> it contains information about off-list communication between Christohper
and Ivelin.
... and Woody is Woody and IMO completly different. As you
said evolution will show us which use cases are better solved with
XMLForms/JXForms and which with Woody. So I don't
worry that we have to decide something here.
What do you think?
Cheers,
Reinhard
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
Jetzt ein- oder umsteigen und USB-Speicheruhr als Prämie sichern!
Re: [Vote] Move flow related "packages"
Posted by Steven Noels <st...@outerthought.org>.
On 4/07/2003 10:02 Reinhard Pötz wrote:
>>From: Steven Noels [mailto:stevenn@outerthought.org]
>>
>>On 3/07/2003 15:18 reinhard_poetz@gmx.net wrote:
>>
>>
>>>As you probably read at my previous mail "[Flow] Status"
>>>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105722900706900&w=2
>>>there are 3 flow related "packages" which should go to the
>>
>>main trunk:
>>
>>Where in the 'main trunk'? Are we talking about blocks here?
>
>
> Good question ...
>
> I would add the JXTemplateGenerator/Transformer to the core. If we ever
> decide to move the flow related stuff into its own block this would be
> the best place. But we should move this discussion to the time after 2.1
> is released because IIRC it is not so easy to move the flow into it's
> own block because of its relations to the sitemap (but possible).
It's some 120K of code being added to the core. Syntactical sugar for
the flow in the sitemap is essentially orthogonal to
JXTransformer/-Generator (and agreed upon IIUC), but moving this into
its own block might grow a better community wrt. documentation, coherent
samples and support.
> The Petstore could move to the flow examples.
I'd like to see this being put into its own (perhaps flow-centric
sample-only) block.
> About the JXForms I'm not sure at the moment. Of course it should go
> into it's own block and IMO it would be best if they go into the
> XMLForms block. This would not confuse our users and from a technical
> point of view it is also correct because AFAIK JXForms are only a
> wrapper to XMLForms to make it easier to use them from within your flow
> scripts. And so the XMLForms action (probably it must be rewritten in
> some parts) is still available for all people who have already used the
> unreleased XMLForms or for people who do not want to rely on the flow.
>
> What do you think?
This Form stuff is troubling me more and more, but I can't see ATM how
we can consolidate easily while maintaining backwards compatibility &
offering an abundance of choice. It's not only about XMLForms and
JXForms, it's also about Woody (which might also be integrated with the
Flow in the future), and various other, smaller Form-related actions and
components dispersed across Cocoon CVS.
Part of myself feels like axing and actively deprecating older (and less
actively used) Form frameworks, and demanding some sort of collaboration
between the various Form frameworks. But maybe Darwin will do that for
us. Then again, not believing in fate and all that, I'm sure we can be
masters of our own destiny.
But as Bruno, sitting next to me, is suggesting, is that there's quite
some other areas of functionality overlap & duplication in Cocoon, and
apparently only Forms is enough of a common concern so that people
actually care about consolidation. Basides the story behind XMLForms, of
course, which sadly reflects now in the last column of
http://sourceforge.net/project/stats/index.php?report=months&group_id=18425
I'm just very careful about all this because I see now what harm the
dramatic overselling of XMLForms is causing us ATM.
Cheers,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: [Vote] Move flow related "packages"
Posted by Reinhard Pötz <re...@gmx.net>.
> From: Steven Noels [mailto:stevenn@outerthought.org]
>
> On 3/07/2003 15:18 reinhard_poetz@gmx.net wrote:
>
> > As you probably read at my previous mail "[Flow] Status"
> > http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105722900706900&w=2
> > there are 3 flow related "packages" which should go to the
> main trunk:
>
> Where in the 'main trunk'? Are we talking about blocks here?
Good question ...
I would add the JXTemplateGenerator/Transformer to the core. If we ever
decide to move the flow related stuff into its own block this would be
the best place. But we should move this discussion to the time after 2.1
is released because IIRC it is not so easy to move the flow into it's
own block because of its relations to the sitemap (but possible).
The Petstore could move to the flow examples.
About the JXForms I'm not sure at the moment. Of course it should go
into it's own block and IMO it would be best if they go into the
XMLForms block. This would not confuse our users and from a technical
point of view it is also correct because AFAIK JXForms are only a
wrapper to XMLForms to make it easier to use them from within your flow
scripts. And so the XMLForms action (probably it must be rewritten in
some parts) is still available for all people who have already used the
unreleased XMLForms or for people who do not want to rely on the flow.
What do you think?
Reinhard
Re: [Vote] Move flow related "packages"
Posted by Steven Noels <st...@outerthought.org>.
On 3/07/2003 15:18 reinhard_poetz@gmx.net wrote:
> As you probably read at my previous mail "[Flow] Status"
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105722900706900&w=2
> there are 3 flow related "packages" which should go to the main trunk:
Where in the 'main trunk'? Are we talking about blocks here?
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: [Vote] Move flow related "packages"
Posted by David Crossley <cr...@indexgeo.com.au>.
reinhard_poetz@gmx.net wrote:
> As you probably read at my previous mail "[Flow] Status"
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105722900706900&w=2
> there are 3 flow related "packages" which should go to the main trunk:
>
>
> [Vote 1] JXTemplateGenerator/Transformer
> Move the JXTemplateGenerator/Transformer to the main trunk.
> You should find some docs here (after a build including the docs):
> [http://localhost:8888/docs/userdocs/flow/jxtemplate.html]
+1
> [Vote 2] Forms
> Replace XMLForms with the JXForms implementation. See
> [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105389102015851&w=2]
> Of course we need a migration guide for our users.
+1 ... and we need a userdocs/concepts document that mentions
each Forms implementation without steering people in any particular
direction.
>
> [Vote 3] Petstore
>
> a) Move Petstore to the main trunk.
>
> b) The connection to the database is implemented with JavaScript objects.
> This should not stop the release as we can implement it e.g. with OJB
> in the future.
+1
--David
Re: [Vote] Move flow related "packages"
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
>> Move the JXTemplateGenerator/Transformer to the main trunk.
+1
>> Replace XMLForms with the JXForms implementation.
+1
>> a) Move Petstore to the main trunk.
+1
>
>> b) The connection to the database is implemented with JavaScript
>> objects.
>> This should not stop the release as we can implement it e.g.
>> with OJB
>> in the future.
+1
-Bertrand
Re: [Vote] Move flow related "packages"
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Thursday, July 3, 2003, at 02:18 PM, reinhard_poetz@gmx.net wrote:
> As you probably read at my previous mail "[Flow] Status"
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105722900706900&w=2
> there are 3 flow related "packages" which should go to the main trunk:
>
>
> [Vote 1] JXTemplateGenerator/Transformer
> Move the JXTemplateGenerator/Transformer to the main trunk.
> You should find some docs here (after a build including the docs):
> [http://localhost:8888/docs/userdocs/flow/jxtemplate.html]
+ 1, Already very useful and capable
> [Vote 2] Forms
> Replace XMLForms with the JXForms implementation. See
>
> [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105389102015851&w=2]
> Of course we need a migration guide for our users.
+1, JXForms appears to be the version that is being maintained.
> [Vote 3] Petstore
>
> a) Move Petstore to the main trunk.
+1
> b) The connection to the database is implemented with JavaScript
> objects.
> This should not stop the release as we can implement it e.g.
> with OJB
> in the future.
+ 1, I don't see why this should hold up a release
regards Jeremy
Re: [Vote] Move flow related "packages"
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
Le Lundi, 7 juil 2003, à 09:32 Europe/Zurich, Reinhard Pötz a écrit :
> Is there a rule how long a voting has to run until it is valid?
AFAIK there's no set rule for such votes
> started the
> voting last Thursday.
Seems like plenty of time for everybody to express their opinions.
-Bertrand
RE: [Vote] Move flow related "packages"
Posted by Reinhard Pötz <re...@gmx.net>.
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
RE: [Vote] Move flow related "packages" - Result
Posted by Reinhard Pötz <re...@gmx.net>.
> > [Vote 3] Petstore
> >
> > a) Move Petstore to the main trunk.
>
> 8x +1
>
> Move it to a "petstore" block
I moved the Petstore into its own block and marked it as unstable. As it
doesn't contain any interfaces stable/unstable doesn't make really
sense. I chose "unstable" because of some problems (images and some
number formatting issues) with the JXPath view.
I also updated gump.xml - maybe somebody with more Gump
knowledge could review my changes.
TIA
Cheers,
Reinhard
RE: [Vote] Move flow related "packages" - Result
Posted by Reinhard Pötz <re...@gmx.net>.
After 4 days time - here are the results:
From: Reinhard Pötz
>
> As you probably read at my previous mail "[Flow] Status"
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105722900706900&w=2
> there are 3 flow related "packages" which should go to the main trunk:
>
>
> [Vote 1] JXTemplateGenerator/Transformer
> Move the JXTemplateGenerator/Transformer to the main trunk.
> You should find some docs here (after a build including the docs):
> [http://localhost:8888/docs/userdocs/flow/jxtemplate.html]
5x +1
2x +1 (core)
1x +0,5 (core)
So these components go to the core.
> [Vote 2] Forms
> Replace XMLForms with the JXForms implementation. See
>
> [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105389102015851&w=2]
> Of course we need a migration guide for our users.
8x +1
JXForms will go into the XMLForms block and will be a second
implementation
of the controller.
> [Vote 3] Petstore
>
> a) Move Petstore to the main trunk.
8x +1
Move it to a "petstore" block
> b) The connection to the database is implemented with
> JavaScript objects.
> This should not stop the release as we can implement it
> e.g. with OJB in the future.
7x +1
Cheers,
Reinhard
Re: [Vote] Move flow related "packages"
Posted by Vadim Gritsenko <va...@verizon.net>.
Dmitry Lisenko wrote:
>On Thu, 3 Jul 2003 reinhard_poetz@gmx.net wrote:
>
...
>> [Vote 2] Forms
>> Replace XMLForms with the JXForms implementation. See
>> [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105389102015851&w=2]
>> Of course we need a migration guide for our users.
>>
>>
>
>Hope you leave XMLForms as deprecated package in 2.1 release?
>We are (and others) have our code extends current XMLForms implemetation.
>
Don't worry; it will still be there. And I guess it won't be deprecated yet.
Vadim
Re: [Vote] Move flow related "packages"
Posted by Dmitry Lisenko <dm...@htec.kiev.ua>.
On Thu, 3 Jul 2003 reinhard_poetz@gmx.net wrote:
> As you probably read at my previous mail "[Flow] Status"
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105722900706900&w=2
> there are 3 flow related "packages" which should go to the main trunk:
>
>
> [Vote 1] JXTemplateGenerator/Transformer
> Move the JXTemplateGenerator/Transformer to the main trunk.
> You should find some docs here (after a build including the docs):
> [http://localhost:8888/docs/userdocs/flow/jxtemplate.html]
>
>
> [Vote 2] Forms
> Replace XMLForms with the JXForms implementation. See
> [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105389102015851&w=2]
> Of course we need a migration guide for our users.
Hope you leave XMLForms as deprecated package in 2.1 release?
We are (and others) have our code extends current XMLForms implemetation.
>
>
> [Vote 3] Petstore
>
> a) Move Petstore to the main trunk.
>
> b) The connection to the database is implemented with JavaScript objects.
> This should not stop the release as we can implement it e.g. with OJB
> in the future.
>
>
> Here my four +1!
>
> Regards,
> Reinhard
>
> --
> +++ GMX - Mail, Messaging & more http://www.gmx.net +++
>
> Jetzt ein- oder umsteigen und USB-Speicheruhr als PrДmie sichern!
>
>