Why in parallel? Look at http://brutus.apache.org/docs/build/cocoon-2-2/. This
build already contains an improved structure that is similar to yours that
reflects Cocoon 2.2 in a better way than the current 2.1 docs do (although
Upayavira and I discussed this for hours, this doesn't mean that
Sebastien Arbogast wrote:
Why in parallel? Look at http://brutus.apache.org/docs/build/cocoon-2-2/. This
build already contains an improved structure that is similar to yours that
reflects Cocoon 2.2 in a better way than the current 2.1 docs do (although
Upayavira and I discussed this for hours,
Oh yes I totally agree with that. As a matter of format and technical
infrastructure, it is the best solution and we could just make a new
documentation branch at the top level. What I meant by in parallel I
had content progression in mind, just to be sure that new users could
see the difference
Sebastien Arbogast wrote:
Oh yes I totally agree with that. As a matter of format and technical
infrastructure, it is the best solution and we could just make a new
documentation branch at the top level. What I meant by in parallel I
had content progression in mind, just to be sure that new users
Just to precise a little point that is not explicitly precised in the wiki.
To download the sources of Cocoon 2.2, I do a checkout on this URL :
http://svn.apache.org/repos/asf/cocoon/trunk/ ?
Or is it in the whiteboard directory at top level ?
On 4/13/05, Reinhard Poetz [EMAIL PROTECTED] wrote:
Sebastien Arbogast wrote:
Just to precise a little point that is not explicitly precised in the wiki.
To download the sources of Cocoon 2.2, I do a checkout on this URL :
http://svn.apache.org/repos/asf/cocoon/trunk/ ?
that's correct (will add it to the wiki)
Or is it in the whiteboard directory
So the new 2.2 documentation base is in whiteboard or trunk ?
On 4/13/05, Reinhard Poetz [EMAIL PROTECTED] wrote:
Sebastien Arbogast wrote:
Just to precise a little point that is not explicitly precised in the wiki.
To download the sources of Cocoon 2.2, I do a checkout on this URL :
Ok it's alright I just checked your update on the wiki. Pfio it's
late here in montreal, maybe I should go to bed... ;o)
On 4/13/05, Sebastien Arbogast [EMAIL PROTECTED] wrote:
So the new 2.2 documentation base is in whiteboard or trunk ?
On 4/13/05, Reinhard Poetz [EMAIL PROTECTED]
Sebastien Arbogast wrote:
So the new 2.2 documentation base is in whiteboard or trunk ?
in trunk:
http://svn.apache.org/repos/asf/cocoon/trunk/src/documentation
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache
I don't know how forrest works yet but is it possible to have a global
PDF for a whole part of documentation. For example is it possible to
generate automatically a PDF book containing all the Cocoon
documentation in one file ?
On 4/13/05, Reinhard Poetz [EMAIL PROTECTED] wrote:
Sebastien
Sebastien Arbogast wrote:
I don't know how forrest works yet but is it possible to have a global
PDF for a whole part of documentation. For example is it possible to
generate automatically a PDF book containing all the Cocoon
documentation in one file ?
yes it is, but I haven't figured it out yet
On Wed, 2005-04-13 at 09:37 +0200, Reinhard Poetz wrote:
Sebastien Arbogast wrote:
I don't know how forrest works yet but is it possible to have a global
PDF for a whole part of documentation. For example is it possible to
generate automatically a PDF book containing all the Cocoon
Sebastien,
I know Reinhard has said a lot already. I just wanted to make a few
comments.
1) Thanks for coming over to the dev list. It is the best place for
these discussions as all developers will be reading what it said.
2) What myself and Reinhard have conceived is a container for ALL docs.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=34430.
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://issues.apache.org/bugzilla/show_bug.cgi?id=34431.
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://issues.apache.org/bugzilla/show_bug.cgi?id=34430.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
Le 13 avr. 05, à 10:30, Upayavira a écrit :
...2) What myself and Reinhard have conceived is a container for ALL
docs. We need first of all to bring the reference docs across, and to
scrap a lot of the crud that has built up over the years. That, I
hope, will establish a foundation upon which
Hi,
sorry I've been too busy lately to participate in anything I've promised
over time. It's not that I don't want to do it any more, just time...
well, you know.
Reading this thread, something clicked as I've been working on a simple
website using Cocoon with simple XML files as backend. So no
Bertrand Delacretaz wrote:
Le 13 avr. 05, 10:30, Upayavira a crit :
...2) What myself and Reinhard have conceived is a container for ALL
docs. We need first of all to bring the reference docs across, and to
scrap a lot of the crud that has built up over the years. That, I
hope, will establish
I could try and write down the process I've gone through and using that
as a base for a tutorial for MyFirstCocoonWebApp. I know I sometimes
work backwards (i.e. develop first, think later ;-)), so things might be
out of (efficient) order.
The website I'm referring to is currently online
Linden H van der (MI) wrote:
Hi,
sorry I've been too busy lately to participate in anything I've promised
over time. It's not that I don't want to do it any more, just time...
well, you know.
Reading this thread, something clicked as I've been working on a simple
website using Cocoon with simple
Hi all,
The OJB block contains a mock for org.apache.ojb.odmg.OJB. Is this one
needed, as db-ojb.jar is in lib/optional and that library contains the
real class?
Thanks,
Bart.
Sounds great. At some point, we've got to come up with a list of the
sort of tutorials and walk-throughs we want, so that we can have
comprehensive coverage. In the meantime, I'd say just go ahead and write it!
or let's try to see if it can't be part of sort of a bigger
complete tutorial.
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration.
This issue affects 35
On 12 Apr 2005, at 15:46, Stefano Mazzocchi wrote:
Pier Fumagalli wrote:
On 11 Apr 2005, at 15:50, Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Ok, I had some remembrance that we had decided to have a particular
directory structure on the COBs, but I couldn't find any
documentation on that, do
Pier Fumagalli wrote:
Ok, here is where I don't agree...
By adding to blocks the capability of bringing components with them,
we enter a quite big minefield, imposed by the restrictions of the Java
VM. The complexity escalates at this point as now blocks must be aware
of their class-loading
[EMAIL PROTECTED] wrote:
Extend CocoonLogFormatter with the ability to log request query string prepended with '?' character.
Nice! I don't get one thing though: why you are adding '?' in the code when you
can easily have it in the format string?
format type=cocoon%5.5{priority} %{time}
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Extend CocoonLogFormatter with the ability to log request query string
prepended with '?' character.
Nice! I don't get one thing though: why you are adding '?' in the code
when you can easily have it in the format string?
format
Leszek Gawron wrote:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Extend CocoonLogFormatter with the ability to log request query
string prepended with '?' character.
Nice! I don't get one thing though: why you are adding '?' in the code
when you can easily have it in the format string?
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
Extend CocoonLogFormatter with the ability to log request query
string prepended with '?' character.
Nice! I don't get one thing though: why you are adding '?' in the
code when you can easily have it in
Pier Fumagalli wrote:
SNIP/
If on the other hand we separate entirely components and java code from
blocks, the implementation becomes _much_ more easy...
My idea would be that a block (for example, our ForrestSkin
implementation) _requires_ a component (not a block) that performs
Hi,
just a quick hack/overview of what I have in mind. All this can be
added/modified etc. This is more or less how I did it. Note: I'm not in
favor of making this tutorial a showcase of all things possible. That
would make the tutorial either too large and too complex.
Another idea: once
The JXTG refactoring is somewhat stalled. I have no time lately to do
serious coding and Daniel went into more complicated things. I'd like
to discuss the development scenario and list what's left.
Some threads ago we have agreed that JXTG should be replaced with it's
refactored version ASAP.
Carsten Ziegeler wrote:
Pier Fumagalli wrote:
SNIP/
If on the other hand we separate entirely components and java code from
blocks, the implementation becomes _much_ more easy...
My idea would be that a block (for example, our ForrestSkin
implementation) _requires_ a component (not a block)
Reinhard Poetz wrote:
Have you tried integrating Hibernate with 2.2 using the new sitemap
classloader?
Hmm, no as we are using 2.1.7 we didn't try it. But yes, that should
have solved the problem as well - at least in theory.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
Carsten Ziegeler wrote:
Pier Fumagalli wrote:
classloading cumbersomeness...
(probably you meant flexibility here? ;-P)
snip/
Ok, long story, short question: do we plan to support such scenaries
with real blocks? I really hope so :)
As Pier outlined in snipped parts above, it's achievable goal. We
Leszek Gawron wrote:
The JXTG refactoring is somewhat stalled. I have no time lately to do
serious coding and Daniel went into more complicated things.
I will certainly get back to Templates. What happened was that some of
the Template work was more about general infrastructure things like
I have just done a huge commit (sorry!) of the old 2.1 documentation,
converted into a flat structure with the content formatted as HTML.
I've also committed a site.xml to go with this.
This means we're ready to start the job of moving content across to the
new structure, bit by bit. I'll start
I propose that we (in trunk) remove the current JXTG and replace it with
the refactored JXTG that is part of the Template block. The refactored
JXTG is supposed to be back compatible with the original JXTG and also
add the ability to use JXTG in the same way in a non flow context. The
only
Daniel Fagerstrom wrote:
Please cast your votes:
[ +1 ] Let's switch to the refactored JXTG in trunk!
[ ] It can wait.
[ +1 ] Mark the Template block core.
[ ] I suggest ...
[ +1 ] Keep JXTG functionality as is and put template development
efforts in CTemplate
[ ] Add new things to JXTG while
Guys, I'm seeing something odd here...
Am I correct in saying that every time the flow is invoked (even if
it's simply a sendPage() without ANY sendPageAndWait()) a new session
is initialized in the servlet container???
Any way to disable this behavior?
Pier
Daniel Fagerstrom wrote:
[+1] Let's switch to the refactored JXTG in trunk!
[ ] It can wait.
[+1] Mark the Template block core.
[ ] I suggest ...
[+1] Keep JXTG functionality as is and put template development efforts
in CTemplate
[ ] Add new things to JXTG while keeping it back compatible
[ ]
Pier Fumagalli wrote:
Guys, I'm seeing something odd here...
Am I correct in saying that every time the flow is invoked (even if it's
simply a sendPage() without ANY sendPageAndWait()) a new session is
initialized in the servlet container???
no, that's no correct. A session is only created if
On 13 Apr 2005, at 14:14, Carsten Ziegeler wrote:
Pier Fumagalli wrote:
SNIP/
If on the other hand we separate entirely components and java code
from
blocks, the implementation becomes _much_ more easy...
My idea would be that a block (for example, our ForrestSkin
implementation) _requires_ a
On 13 Apr 2005, at 15:07, Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Pier Fumagalli wrote:
classloading cumbersomeness...
(probably you meant flexibility here? ;-P)
snip/
Ok, long story, short question: do we plan to support such scenaries
with real blocks? I really hope so :)
As Pier outlined
On 13 Apr 2005, at 12:40, Reinhard Poetz wrote:
Pier Fumagalli wrote:
Ok, here is where I don't agree...
By adding to blocks the capability of bringing components with
them, we enter a quite big minefield, imposed by the restrictions of
the Java VM. The complexity escalates at this point as now
On 13 Apr 2005, at 16:05, Reinhard Poetz wrote:
Pier Fumagalli wrote:
Guys, I'm seeing something odd here...
Am I correct in saying that every time the flow is invoked (even if
it's simply a sendPage() without ANY sendPageAndWait()) a new session
is initialized in the servlet container???
no,
On 13 Apr 2005, at 15:46, Upayavira wrote:
I have just done a huge commit (sorry!) of the old 2.1 documentation,
converted into a flat structure with the content formatted as HTML.
I've also committed a site.xml to go with this.
This means we're ready to start the job of moving content across to
Pier Fumagalli wrote:
I'm
just saying that the concerns are separate: a block provides generators,
transformers, serializers, ... to other blocks, but those are de-coupled
from the real java components (if any) doing the job.
But *real* blocks, IIUC, *are* the only way to bring new (java)
Pier Fumagalli wrote:
Absolutely we do, but not in the very first phase of blocks. Blocks,
in my view, addess separate concerns from the classes they require for
the implementation of the virtual sitemap components that they expose
to other blocks.
At the beginning, and that's what we agreed a
Hi all,
The awaited Lepido [1] newsgroup has been created at Eclipse. If you're
interested and want to participate to this new project, please join
news://news.eclipse.org/eclipse.technology.lepido
Remember, registration is required to access the newsgroup [2].
See you there!
Sylvain
[1]
On 13 Apr 2005, at 18:08, Vadim Gritsenko wrote:
Pier Fumagalli wrote:
I'm just saying that the concerns are separate: a block provides
generators, transformers, serializers, ... to other blocks, but those
are de-coupled from the real java components (if any) doing the job.
But *real* blocks,
Jeremy Quinn wrote:
On 13 Apr 2005, at 15:46, Upayavira wrote:
I have just done a huge commit (sorry!) of the old 2.1 documentation,
converted into a flat structure with the content formatted as HTML.
I've also committed a site.xml to go with this.
This means we're ready to start the job of
...while fighting my way through the block dependencies:
Any objections to move this class
./src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPSessionFwHelper.java
into the session-fw block? Since that seems to be
the only reason for the xsp dependency on the session-fw
Torsten Curdt wrote:
...while fighting my way through the block dependencies:
Any objections to move this class
./src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPSessionFwHelper.java
into the session-fw block? Since that seems to be
the only reason for the xsp dependency on
Daniel Fagerstrom wrote:
Please cast your votes:
[+1] Let's switch to the refactored JXTG in trunk!
[ ] It can wait.
[+1] Mark the Template block core.
[ ] I suggest ...
[+1] Keep JXTG functionality as is and put template development efforts
in CTemplate
[ ] Add new things to JXTG while keeping
Leszek Gawron wrote:
Torsten Curdt wrote:
...while fighting my way through the block dependencies:
Any objections to move this class
./src/blocks/xsp/java/org/apache/cocoon/components/language/markup/xsp/XSPSessionFwHelper.java
into the session-fw block? Since that seems to be
the only reason
is there a logicsheet for session-fw ?
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110813469829620
Hm... another block just because of that one class?
Just curious ...why was it moved in the first place?
cheers
--
Torsten
signature.asc
Description: OpenPGP digital signature
Torsten Curdt wrote:
is there a logicsheet for session-fw ?
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110813469829620
Hm... another block just because of that one class?
Well whatever you do to fix this it won't make it worse :-)
Just curious ...why was it moved in the first place?
Dunno,
Le 13 avr. 05, à 16:47, Daniel Fagerstrom a écrit :
...There are certainly things left to do in the refactoring but
everything is supposed to work as it is right now...
Before voting, what worries me slightly is the supposed to work bit.
I didn't look into the new stuff yet, are there tests
Le 13 avr. 05, à 07:10, Sebastien Arbogast a écrit :
...FTR, I should precise that right now I'm working on a big project
using Cocoon as its core XML server and it's my first project using
Cocoon, which implies that
- I won't be able to spend my whole days on this...
And this is a key point:
So a crucial point is that any docs effort/tool/whatever has to allow
us to work in small increments and be useful, without leaving
half-finished work behind us. Something requiring big stretches of
continuous work is useless ATM.
And still... now I can realize how learning how to use a
62 matches
Mail list logo
