Bernhard,
paah back from a heaty political discussion on a
"Sponsionsfeier" at a bar in Vienna ;-).
>From: Bernhard Huber [mailto:[EMAIL PROTECTED]]
>
>Hi,
>
>>
>>
>>Therefor I would like to propose a new document structure.
>>The aim is, that people find quicker the correct document
>>to there
Gianugo Rabellino wrote:
> David Crossley wrote:
> >Gianugo Rabellino wrote:
> >>Now... I tried to turn validation off in cocoon.xconf. No luck. I tried
> >>then to resort to the entity resolver by adding the line
> >>SYSTEM "sdocbook.dtd" "sdocbook.dtd"
> >>to the end of resources/entities/cata
In keeping with my last post...
There have been some great discussions on this list, and presumably on
other lists such as those devoted to Avalon, that imply some deep
underlying models of what makes good web architecture and good software
design. In some cases these discussions have led to
Hi,
>
>
>Therefor I would like to propose a new document structure.
>The aim is, that people find quicker the correct document
>to there Problem!
>
The Cocoon webapp now has the ability to search the documentation.
Thus if the use has managed to install Cocoon, and generated the index
it's possi
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>
> Vadim Gritsenko wrote:
>
> > -10 on changing current sitemap semantics. It's even worse then
breaking
> > compatibility. For before pipeline execution / after pipeline
execution
> > actions, it is better to have another kind of componen
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>
> Vadim Gritsenko wrote:
>
> > you have product catalog sub-sitemap:
> >
> >
> > ...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ...
> >
> > Example might be not perfect, but it gives an idea...
>
> Yeah, gives me the
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>
> Vadim Gritsenko wrote:
> >
> > > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> > >
> > > - only match is allowed as top-level element
> >
> > It is not correct.
>
> No, it *is* correct. You are proposing to change what the original
>
***
__ __ __ __ __ __
(___ (__) (___ (__) (__) | )
__ __ _|_ __ |__ _____
|__) (__( |_, (___ | ) (__/_ __)
|
***
Jason,
>With respect to the new outline for documentation I would like to suggest
>that we leverage the concept of "views" and present the same content in
>different ways for different audiences. As I see it, there are 5 audiences
>for the documentation.
>
>Four of these (Manager, Logician, A
On Saturday, January 05, 2002 , Torsten Curdt wrote:
> So I'm +1 for the servlet context dir as basedir
+1
BTW, I asked some days ago on the fop-dev list if this is the only way of
setting this parameter, because
in this mail I read:
- Original Message -
From: "Keiron Liddle" <[EMAIL PR
With respect to the new outline for documentation I would like to suggest
that we leverage the concept of "views" and present the same content in
different ways for different audiences. As I see it, there are 5 audiences
for the documentation.
Four of these (Manager, Logician, Author?, Stylis
On Thu, 3 Jan 2002, Nicola Ken Barozzi wrote:
> > Cool! Will invesitgate further. Maybe we can set the context
> > path for fop processing then!!
> >
> > If you already have more insight in this please give me a direct
> > mail or post to cocoon-dev.
>
> Ok so Configuration is static and here is
John Morrison wrote:
> > Agreed. -1 as well. Well, until somebody comes up with the need for an
> > action to be executed *after* a serializer.
>
> How about this one: if the serializer doesn't throw an exception then
> you *know(?)* the client recieved the request. An action after
> serializat
>From the xml.apache.org Project Guidelines
(http://xml.apache.org/guidelines.html)
>Status Files
>
>Each of the Project's active source code repositories contain a file named
>STATUS which is used to keep track of the agenda and plans for work within
>that repository. The status file includes in
Hi Team,
I like to propose a new Document structure for
a) our homepage b) for the Cocoon overall userguide.
The motivation behind are the performance issues.
I realized that some of the problems are caused, because
people don't find the correct documents. All tuning
hints are somewhere hidden in
froehlich02/01/05 04:02:17
Modified:src/documentation/xdocs newtoc.txt
Log:
added new chapters
Revision ChangesPath
1.2 +21 -3 xml-cocoon2/src/documentation/xdocs/newtoc.txt
Index: newtoc.txt
==
froehlich02/01/05 03:47:38
Added: src/documentation/xdocs newtoc.txt
Removed: src/documentation/xdocs newtoc.xml
Log:
added ToC proposal for the new document structure
Revision ChangesPath
1.1 xml-cocoon2/src/documentation/xdocs/newtoc.txt
I
Vadim Gritsenko wrote:
> you have product catalog sub-sitemap:
>
>
> ...
>
>
>
>
>
>
>
>
>
>
> ...
>
> Example might be not perfect, but it gives an idea...
Yeah, gives me the idea that the whole concept is screwed and can
potentially be very harmful in the future!
>F
Vadim Gritsenko wrote:
> But you can rephrase this:
>
>
>
>...
>
>...
>...
>
>
>
> This is perfectly legal now and leaves possibility for the same
> questions.
> So it does not make sense to disable this functionality (unmatched
> actions)
> because of such argument
Vadim Gritsenko wrote:
>
> > From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> >
> > Hi,
>
> Hi Carsten and all,
>
> >
> > before we continue discussion things like pre/intra/post-matching
> actions,
> > can someone summarize the current semantics of the sitemap as it
> *should*
> > be? I can
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
> Carsten Ziegeler wrote:
> > Stefano Mazzocchi wrote:
> > For b) I'm not sure. It might make sense to execute actions after
> > the xml pipeline is executed. But changing this is incompatible!
> > Existing sitemaps would then be executed d
21 matches
Mail list logo
