You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de> on 2001/06/20 14:51:23 UTC
[Patch][C2.1] sitemap redirections + target spec
Hi all.
The attached patch adds the ability to specify a "target" in a
<map:redirect-to resource=""> tag. The "target" is available as "{1}"
in the resource specification.
Example
<map:resources>
<map:resource name="simple-page">
<map:generate type="serverpages" src="test/{1}.xsp"/>
<map:transform src="stylesheets/presentation.xsl"/>
<map:transform src="stylesheets/dynamic-page2html.xsl"/>
<map:serialize/>
</map:resource>
</map:resources>
<map:pipelines>
<map:pipeline>
<map:match pattern="test">
<map:act type="form-validator">
<map:parameter name="descriptor" value="context:///descriptor.xml"/>
<map:parameter name="validate-set" value="user-input"/>
<map:redirect-to resource="simple-page" target="OK"/>
</map:act>
<map:redirect-to resource="simple-page" target="ERROR"/>
</map:match>
</map:pipeline>
</map:pipelines>
This way it is only necessary to specify required transformation steps
only in one place. A redirection to a URL wouldn't work here as that
would create a new request object which discards some values. In
addition resources are not accessible from outside.
Implementation
Since maps (listOfMaps) is handed to resources, a new map is added to
the listOfMaps with just one entry ("1","@target").
Rationale
A thing called "flowmap" has been discussed on this list for a long
time. Recently I felt the need for such a thing as well. Anyway, it
was not clear enough for me in which aspects a flowmap will differ from
the sitemap. All in all I believe all the functionality for a flowmap
is already present in the sitemap concept.
As far as I am concerned, a sitemap would care about the URI mapping
and transformation steps. A flowmap would be a XML representation of a
state chart with states, sub states, transitions, triggers, guards and
actions.
States can be represented by matchers, sub states by nested
matchers. Triggers are requests (request parameters) which could be
represented by selectors. Transitions are allowed paths to other URIs
or resources, guards can be realized by cocoon-actions with nested
content and actions, well be be realized by cocoon-actions.
This way every resource would need a separate definition.
The patch allows to redirect to a common definition for
transformation. So those two different concerns are separated, even if
they live in the same file. Since resources from ancestor sitemaps can
be accessed, this could be split up to that resources are only defined
in the top level sitemap.
Comments?
Chris.
PS: I hope to offer a matcher based on session state shortly. This way
not the requested page is matched but the state that the application
believes the user should be in. Stay tuned.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
Re: AW: [C2] Build targets
Posted by Sergio Carvalho <se...@acm.org>.
On Fri, 22 Jun 2001 10:42:57 +0200
"Carsten Ziegeler" <cz...@sundn.de> wrote:
> Hi,
>
> I just added a very simple command line tool (called st for sitemap tool)
> which is actually a java class. This tool can be called from the build.xml
> during build and can add sitemap entries to the build sitemap.xmap.
> I changed the build.xml so that an entry for the PhpGenerator is added
> to the sitemap if the php generator is compiled.
>
> We could do this for all other "optional" components as well, for example
> even for the fop classes. So we would need to add more complexity to the
> build script.
>
> One could also imagine to add a new constraint saying: "examples or not"
> and we could enhance the st tool to generate (include) example pipelines
> during the build rather then hardcoding in the build.xml.
>
> Carsten
>
This would be very very cool. It would allow one to have a separate dir with the Cocoon apps to deploy in cocoon, and have the build system add them at build time. Alas, I don't master ant, or I would have done it myself (I have a small shell script that strips the cvs webapp and replaces it with mine).
Having the ability to strip fop out when not needed would solve the common "can't connect to X server" errors caused by batik.
Sergio
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2] Build targets
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Martin Rogard wrote:
>
> Hello,
>
> > Carsten Ziegeler wrote:
> > I changed the build.xml so that an entry for the PhpGenerator is added
> > to the sitemap if the php generator is compiled.
>
> I don't find an example/sample/tutorial using the PhP Generator,
> any hints ?
>
Sorry, I never used the Php stuff...
But if you look at http:http://www.php.net/ you will find a lot about php.
Carsten
> - martin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [C2] Build targets
Posted by Martin Rogard <ml...@frenchtouch.net>.
Hello,
> Carsten Ziegeler wrote:
> I changed the build.xml so that an entry for the PhpGenerator is added
> to the sitemap if the php generator is compiled.
I don't find an example/sample/tutorial using the PhP Generator, any hints ?
- martin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2] Build targets
Posted by giacomo <gi...@apache.org>.
On Fri, 22 Jun 2001, Carsten Ziegeler wrote:
> > Giacomo Pati wrote:
> >
> > One thing that we can do for convenience is to update the build.xml to not
> > depend on specific jars and exclude the sources for compilation
> > if those jars
> > are absent (see PhpGenerator).
> >
> Hi,
>
> I just added a very simple command line tool (called st for sitemap tool)
> which is actually a java class. This tool can be called from the build.xml
> during build and can add sitemap entries to the build sitemap.xmap.
> I changed the build.xml so that an entry for the PhpGenerator is added
> to the sitemap if the php generator is compiled.
>
> We could do this for all other "optional" components as well, for example
> even for the fop classes. So we would need to add more complexity to the
> build script.
>
> One could also imagine to add a new constraint saying: "examples or not"
> and we could enhance the st tool to generate (include) example pipelines
> during the build rather then hardcoding in the build.xml.
Sound cool.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2] Build targets
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Giacomo Pati wrote:
>
> Quoting Carsten Ziegeler <cz...@sundn.de>:
>
> > > Konstantin Piroumian wrote:
> > >
> > > > > Hi, Cocooners!
> > > > >
> > > > > Is there a way to build C2 without samples and unnecesary
> > libraries?
> > > >
> > > > Yes, delete them ;).
> > >
> > > How can I know which jar is necessary for Cocoon engine and which one
> > is
> > > used only in a sample? Of course, I can try to delete one-by-one and
> > see
> > > what happens :)
> > >
> > > >
> > > > > I need to get a clear cocoon.war - without specific Actions, jars
> > and
> > > > > samples.
> > > >
> > > > Well, this is a matter of taste and I don't see a general way to
> > specify
> > > > which jars are not needed. the samples are in the webapp subdiretory
> > > > which is easily deletable.
> > >
> > > As I can see, this jars are not necessary if I don't need samples and
> > some
> > > of the actions:
> > >
> > > axis.jar
> > > axis-samples.jar
> > > batik-libs.jar
> > > bsf.jar
> > > fop-0_18_1.jar
> > > hsqldb.jar
> > > jimi-1.0.jar
> > > junit.jar
> > > maybeupload.jar
> > > rhino.jar
> > > Tidy.jar
> > > velocity-1.1-rc1.jar
> > > xt.jar
> > >
> > > Am I right or maybe some this libs is required for Cocoon itself?
> > >
> > Am not sure about all of them but the maybeupload.jar is required as it
> > is
> > directly used by the Request object created for each request.
> > All others seem to be optional, but of course you have to remove all
> > references
> > from the sitemap.xmap, e.g. you have to remove the html generator etc.
> >
> > > >
> > > > > Just the core of Cocoon, so I could add my application files,
> > > > > classes, jars and sitemaps and create a war for my application
> > only.
> > > >
> > > > I don't see what the "core Cocoon" is.
> > >
> > > By "core Cocoon" I mean Cocoon engine without any Form
> > > processing, DB, SVG,
> > > FOP, i18n samples and actions.
> > >
> > > But... maybe you are right saying that it's easier to delete all
> > > unnecessary
> > > things that you don't need in your application.
> > >
> > Personally, I don't like the term "core Cocoon" for this case as I
> > think that the "core Cocoon" is the whole project without examples.
> > But this includes all provided generators, transformers etc. as most
> > of them are very usefull and also required to build web applications.
> > What you think of, I would rather call a "minimal Cocoon".
> > But anyway these are only terms.
>
> One thing that we can do for convenience is to update the build.xml to not
> depend on specific jars and exclude the sources for compilation
> if those jars
> are absent (see PhpGenerator).
>
Hi,
I just added a very simple command line tool (called st for sitemap tool)
which is actually a java class. This tool can be called from the build.xml
during build and can add sitemap entries to the build sitemap.xmap.
I changed the build.xml so that an entry for the PhpGenerator is added
to the sitemap if the php generator is compiled.
We could do this for all other "optional" components as well, for example
even for the fop classes. So we would need to add more complexity to the
build script.
One could also imagine to add a new constraint saying: "examples or not"
and we could enhance the st tool to generate (include) example pipelines
during the build rather then hardcoding in the build.xml.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> Giacomo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: AW: [C2] Build targets
Posted by Giacomo Pati <gi...@apache.org>.
Quoting Carsten Ziegeler <cz...@sundn.de>:
> > Konstantin Piroumian wrote:
> >
> > > > Hi, Cocooners!
> > > >
> > > > Is there a way to build C2 without samples and unnecesary
> libraries?
> > >
> > > Yes, delete them ;).
> >
> > How can I know which jar is necessary for Cocoon engine and which one
> is
> > used only in a sample? Of course, I can try to delete one-by-one and
> see
> > what happens :)
> >
> > >
> > > > I need to get a clear cocoon.war - without specific Actions, jars
> and
> > > > samples.
> > >
> > > Well, this is a matter of taste and I don't see a general way to
> specify
> > > which jars are not needed. the samples are in the webapp subdiretory
> > > which is easily deletable.
> >
> > As I can see, this jars are not necessary if I don't need samples and
> some
> > of the actions:
> >
> > axis.jar
> > axis-samples.jar
> > batik-libs.jar
> > bsf.jar
> > fop-0_18_1.jar
> > hsqldb.jar
> > jimi-1.0.jar
> > junit.jar
> > maybeupload.jar
> > rhino.jar
> > Tidy.jar
> > velocity-1.1-rc1.jar
> > xt.jar
> >
> > Am I right or maybe some this libs is required for Cocoon itself?
> >
> Am not sure about all of them but the maybeupload.jar is required as it
> is
> directly used by the Request object created for each request.
> All others seem to be optional, but of course you have to remove all
> references
> from the sitemap.xmap, e.g. you have to remove the html generator etc.
>
> > >
> > > > Just the core of Cocoon, so I could add my application files,
> > > > classes, jars and sitemaps and create a war for my application
> only.
> > >
> > > I don't see what the "core Cocoon" is.
> >
> > By "core Cocoon" I mean Cocoon engine without any Form
> > processing, DB, SVG,
> > FOP, i18n samples and actions.
> >
> > But... maybe you are right saying that it's easier to delete all
> > unnecessary
> > things that you don't need in your application.
> >
> Personally, I don't like the term "core Cocoon" for this case as I
> think that the "core Cocoon" is the whole project without examples.
> But this includes all provided generators, transformers etc. as most
> of them are very usefull and also required to build web applications.
> What you think of, I would rather call a "minimal Cocoon".
> But anyway these are only terms.
One thing that we can do for convenience is to update the build.xml to not
depend on specific jars and exclude the sources for compilation if those jars
are absent (see PhpGenerator).
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Build targets
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> <skipped>
> > > > >
> > > > Personally, I don't like the term "core Cocoon" for this case as I
> > > > think that the "core Cocoon" is the whole project without examples.
> > > > But this includes all provided generators, transformers etc. as most
> > > > of them are very usefull and also required to build web
applications.
> > > > What you think of, I would rather call a "minimal Cocoon".
> > > > But anyway these are only terms.
> > >
> > > I'm absolutely agree - let it be 'minimal Cocoon'.
> > >
> > > There are options in build.xml that turns off Oracle stuff and
> > > some others,
> > > so maybe it would be convenient to have some 'minimal' param also?
> > > Just suggestions...
> > >
> > Yes, this is something I tried several weeks ago but unfortunately
> > without any success. It is possible to make a dependend compilation,
> > which means to not compile some components, e.g. the FOPSerializer.
> > But the difficult part is to change the sitemap.xmap according to
> > this. The declaration for the fop serializer should only be in the
> > sitemap, if it was compiled. Currently, I don't know how to do it.
> > Perhaps, if someone else has any idea on this?
>
> Maybe the path to sitemap can be a parameter for build.bat?
> In this case you can indicate your application sitemap and it will be
> compiled with that sitemap and all its dependencies?
Immediately appears a new questions: how to specify sub-sitemaps in this
case?
>
> Kot.
>
> >
> > Carsten
> >
> > > >
> > > > Carsten
> > > > > > Giacomo
> > > > >
> > > > > Konstantin.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Build targets
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
<skipped>
> > > >
> > > Personally, I don't like the term "core Cocoon" for this case as I
> > > think that the "core Cocoon" is the whole project without examples.
> > > But this includes all provided generators, transformers etc. as most
> > > of them are very usefull and also required to build web applications.
> > > What you think of, I would rather call a "minimal Cocoon".
> > > But anyway these are only terms.
> >
> > I'm absolutely agree - let it be 'minimal Cocoon'.
> >
> > There are options in build.xml that turns off Oracle stuff and
> > some others,
> > so maybe it would be convenient to have some 'minimal' param also?
> > Just suggestions...
> >
> Yes, this is something I tried several weeks ago but unfortunately
> without any success. It is possible to make a dependend compilation,
> which means to not compile some components, e.g. the FOPSerializer.
> But the difficult part is to change the sitemap.xmap according to
> this. The declaration for the fop serializer should only be in the
> sitemap, if it was compiled. Currently, I don't know how to do it.
> Perhaps, if someone else has any idea on this?
Maybe the path to sitemap can be a parameter for build.bat?
In this case you can indicate your application sitemap and it will be
compiled with that sitemap and all its dependencies?
Kot.
>
> Carsten
>
> > >
> > > Carsten
> > > > > Giacomo
> > > >
> > > > Konstantin.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2] Build targets
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Konstantin Piroumian
>
> > > Konstantin Piroumian wrote:
> > >
> > > > > Hi, Cocooners!
> > > > >
> > > > > Is there a way to build C2 without samples and unnecesary
> libraries?
> > > >
> > > > Yes, delete them ;).
> > >
> > > How can I know which jar is necessary for Cocoon engine and
> which one is
> > > used only in a sample? Of course, I can try to delete
> one-by-one and see
> > > what happens :)
> > >
> > > >
> > > > > I need to get a clear cocoon.war - without specific Actions, jars
> and
> > > > > samples.
> > > >
> > > > Well, this is a matter of taste and I don't see a general way to
> specify
> > > > which jars are not needed. the samples are in the webapp subdiretory
> > > > which is easily deletable.
> > >
> > > As I can see, this jars are not necessary if I don't need samples and
> some
> > > of the actions:
> > >
> > > axis.jar
> > > axis-samples.jar
> > > batik-libs.jar
> > > bsf.jar
> > > fop-0_18_1.jar
> > > hsqldb.jar
> > > jimi-1.0.jar
> > > junit.jar
> > > maybeupload.jar
> > > rhino.jar
> > > Tidy.jar
> > > velocity-1.1-rc1.jar
> > > xt.jar
> > >
> > > Am I right or maybe some this libs is required for Cocoon itself?
> > >
> > Am not sure about all of them but the maybeupload.jar is
> required as it is
> > directly used by the Request object created for each request.
> > All others seem to be optional, but of course you have to remove all
> > references
> > from the sitemap.xmap, e.g. you have to remove the html generator etc.
> >
>
> Ok. I just investigating ways of creating my own customized build.xml for
> our project which is based on Cocoon and most of the features are
> not used:
> we don't use DB directly (only through EJBs), we don't use SVG and we have
> our own form processing and validation.
> Unfortunately, we even don't use XSP/XML/XSL now - only JSP and
> Cocoon as a
> controller.
>
> So, I just wanted to get a 'minimal Cocoon' (it's a better term for that)
> and place all our application specific stuff in it.
>
> > > >
> > > > > Just the core of Cocoon, so I could add my application files,
> > > > > classes, jars and sitemaps and create a war for my
> application only.
> > > >
> > > > I don't see what the "core Cocoon" is.
> > >
> > > By "core Cocoon" I mean Cocoon engine without any Form
> > > processing, DB, SVG,
> > > FOP, i18n samples and actions.
> > >
> > > But... maybe you are right saying that it's easier to delete all
> > > unnecessary
> > > things that you don't need in your application.
> > >
> > Personally, I don't like the term "core Cocoon" for this case as I
> > think that the "core Cocoon" is the whole project without examples.
> > But this includes all provided generators, transformers etc. as most
> > of them are very usefull and also required to build web applications.
> > What you think of, I would rather call a "minimal Cocoon".
> > But anyway these are only terms.
>
> I'm absolutely agree - let it be 'minimal Cocoon'.
>
> There are options in build.xml that turns off Oracle stuff and
> some others,
> so maybe it would be convenient to have some 'minimal' param also?
> Just suggestions...
>
Yes, this is something I tried several weeks ago but unfortunately
without any success. It is possible to make a dependend compilation,
which means to not compile some components, e.g. the FOPSerializer.
But the difficult part is to change the sitemap.xmap according to
this. The declaration for the fop serializer should only be in the
sitemap, if it was compiled. Currently, I don't know how to do it.
Perhaps, if someone else has any idea on this?
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> >
> > Carsten
> > > > Giacomo
> > >
> > > Konstantin.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Build targets
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> > Konstantin Piroumian wrote:
> >
> > > > Hi, Cocooners!
> > > >
> > > > Is there a way to build C2 without samples and unnecesary libraries?
> > >
> > > Yes, delete them ;).
> >
> > How can I know which jar is necessary for Cocoon engine and which one is
> > used only in a sample? Of course, I can try to delete one-by-one and see
> > what happens :)
> >
> > >
> > > > I need to get a clear cocoon.war - without specific Actions, jars
and
> > > > samples.
> > >
> > > Well, this is a matter of taste and I don't see a general way to
specify
> > > which jars are not needed. the samples are in the webapp subdiretory
> > > which is easily deletable.
> >
> > As I can see, this jars are not necessary if I don't need samples and
some
> > of the actions:
> >
> > axis.jar
> > axis-samples.jar
> > batik-libs.jar
> > bsf.jar
> > fop-0_18_1.jar
> > hsqldb.jar
> > jimi-1.0.jar
> > junit.jar
> > maybeupload.jar
> > rhino.jar
> > Tidy.jar
> > velocity-1.1-rc1.jar
> > xt.jar
> >
> > Am I right or maybe some this libs is required for Cocoon itself?
> >
> Am not sure about all of them but the maybeupload.jar is required as it is
> directly used by the Request object created for each request.
> All others seem to be optional, but of course you have to remove all
> references
> from the sitemap.xmap, e.g. you have to remove the html generator etc.
>
Ok. I just investigating ways of creating my own customized build.xml for
our project which is based on Cocoon and most of the features are not used:
we don't use DB directly (only through EJBs), we don't use SVG and we have
our own form processing and validation.
Unfortunately, we even don't use XSP/XML/XSL now - only JSP and Cocoon as a
controller.
So, I just wanted to get a 'minimal Cocoon' (it's a better term for that)
and place all our application specific stuff in it.
> > >
> > > > Just the core of Cocoon, so I could add my application files,
> > > > classes, jars and sitemaps and create a war for my application only.
> > >
> > > I don't see what the "core Cocoon" is.
> >
> > By "core Cocoon" I mean Cocoon engine without any Form
> > processing, DB, SVG,
> > FOP, i18n samples and actions.
> >
> > But... maybe you are right saying that it's easier to delete all
> > unnecessary
> > things that you don't need in your application.
> >
> Personally, I don't like the term "core Cocoon" for this case as I
> think that the "core Cocoon" is the whole project without examples.
> But this includes all provided generators, transformers etc. as most
> of them are very usefull and also required to build web applications.
> What you think of, I would rather call a "minimal Cocoon".
> But anyway these are only terms.
I'm absolutely agree - let it be 'minimal Cocoon'.
There are options in build.xml that turns off Oracle stuff and some others,
so maybe it would be convenient to have some 'minimal' param also?
Just suggestions...
>
> Carsten
> > > Giacomo
> >
> > Konstantin.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [C2] Build targets
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Konstantin Piroumian wrote:
>
> > > Hi, Cocooners!
> > >
> > > Is there a way to build C2 without samples and unnecesary libraries?
> >
> > Yes, delete them ;).
>
> How can I know which jar is necessary for Cocoon engine and which one is
> used only in a sample? Of course, I can try to delete one-by-one and see
> what happens :)
>
> >
> > > I need to get a clear cocoon.war - without specific Actions, jars and
> > > samples.
> >
> > Well, this is a matter of taste and I don't see a general way to specify
> > which jars are not needed. the samples are in the webapp subdiretory
> > which is easily deletable.
>
> As I can see, this jars are not necessary if I don't need samples and some
> of the actions:
>
> axis.jar
> axis-samples.jar
> batik-libs.jar
> bsf.jar
> fop-0_18_1.jar
> hsqldb.jar
> jimi-1.0.jar
> junit.jar
> maybeupload.jar
> rhino.jar
> Tidy.jar
> velocity-1.1-rc1.jar
> xt.jar
>
> Am I right or maybe some this libs is required for Cocoon itself?
>
Am not sure about all of them but the maybeupload.jar is required as it is
directly used by the Request object created for each request.
All others seem to be optional, but of course you have to remove all
references
from the sitemap.xmap, e.g. you have to remove the html generator etc.
> >
> > > Just the core of Cocoon, so I could add my application files,
> > > classes, jars and sitemaps and create a war for my application only.
> >
> > I don't see what the "core Cocoon" is.
>
> By "core Cocoon" I mean Cocoon engine without any Form
> processing, DB, SVG,
> FOP, i18n samples and actions.
>
> But... maybe you are right saying that it's easier to delete all
> unnecessary
> things that you don't need in your application.
>
Personally, I don't like the term "core Cocoon" for this case as I
think that the "core Cocoon" is the whole project without examples.
But this includes all provided generators, transformers etc. as most
of them are very usefull and also required to build web applications.
What you think of, I would rather call a "minimal Cocoon".
But anyway these are only terms.
Carsten
Open Source Group sunShine - b:Integrated
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto: cziegeler@sundn.de
================================================================
> > Giacomo
>
> Konstantin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Build targets
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
> > Hi, Cocooners!
> >
> > Is there a way to build C2 without samples and unnecesary libraries?
>
> Yes, delete them ;).
How can I know which jar is necessary for Cocoon engine and which one is
used only in a sample? Of course, I can try to delete one-by-one and see
what happens :)
>
> > I need to get a clear cocoon.war - without specific Actions, jars and
> > samples.
>
> Well, this is a matter of taste and I don't see a general way to specify
> which jars are not needed. the samples are in the webapp subdiretory
> which is easily deletable.
As I can see, this jars are not necessary if I don't need samples and some
of the actions:
axis.jar
axis-samples.jar
batik-libs.jar
bsf.jar
fop-0_18_1.jar
hsqldb.jar
jimi-1.0.jar
junit.jar
maybeupload.jar
rhino.jar
Tidy.jar
velocity-1.1-rc1.jar
xt.jar
Am I right or maybe some this libs is required for Cocoon itself?
>
> > Just the core of Cocoon, so I could add my application files,
> > classes, jars and sitemaps and create a war for my application only.
>
> I don't see what the "core Cocoon" is.
By "core Cocoon" I mean Cocoon engine without any Form processing, DB, SVG,
FOP, i18n samples and actions.
But... maybe you are right saying that it's easier to delete all unnecessary
things that you don't need in your application.
> Giacomo
Konstantin.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2] Build targets
Posted by giacomo <gi...@apache.org>.
On Wed, 20 Jun 2001, Piroumian, Konstantin wrote:
> Hi, Cocooners!
>
> Is there a way to build C2 without samples and unnecesary libraries?
Yes, delete them ;).
> I need to get a clear cocoon.war - without specific Actions, jars and
> samples.
Well, this is a matter of taste and I don't see a general way to specify
which jars are not needed. the samples are in the webapp subdiretory
which is easily deletable.
> Just the core of Cocoon, so I could add my application files,
> classes, jars and sitemaps and create a war for my application only.
I don't see what the "core Cocoon" is.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
[C2] Build targets
Posted by "Piroumian, Konstantin" <KP...@flagship.ru>.
Hi, Cocooners!
Is there a way to build C2 without samples and unnecesary libraries?
I need to get a clear cocoon.war - without specific Actions, jars and
samples. Just the core of Cocoon, so I could add my application files,
classes, jars and sitemaps and create a war for my application only.
Regards,
Konstantin Piroumian.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Patch][C2.1] sitemap redirections + target spec
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 20.Jun.2001 -- 09:26 PM, giacomo wrote:
>
> Why not as "{target}"? And why not substitutable?
>
Just thought "{1}" is more common. OK, that's probably because the
wildcard matcher is the most common one. Sure I can change it to
"target".
What do you mean by "not substitutable"? It is done by adding a new
map to the listOfMaps that contains just one pair, key "target", value
"value of attribute 'target'". What else could be substitutable?
> > The patch allows to redirect to a common definition for
> > transformation. So those two different concerns are separated, even if
> > they live in the same file. Since resources from ancestor sitemaps can
> > be accessed, this could be split up to that resources are only defined
> > in the top level sitemap.
>
> I don't like the fact that sub sitemap refers to parent ones.
> Admittedly sub sitemap already refers to
> sitemap components defined in the parent sitemap. But also Berin
> proposed to move them out of the sitemap right into the cocoon.xconf
> file (where all components are collected anyway).
Mmmh, yes. But since Cocoon is about separating concerns and here two
aspects meet in the same file although separated within this file,
this would be a way to split it up cleanly. Have common definitions in
a parent sitemap and do special things in children. After all it is
very likely that the application designer is a different person than
the style designer.
Anyway this was meant to say that I don't feel strong urge to separate
these two aspects into different files but think that is is OK the way
it is.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Patch][C2.1] sitemap redirections + target spec
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 20.Jun.2001 -- 04:20 PM, Vadim Gritsenko wrote:
> I would not say why not to use <map:parameters> as elsewhere else...
> Like:
> <map:match pattern="test">
> <map:act type="form-validator">
> <map:parameter name="descriptor" value="context:///descriptor.xml"/>
> <map:parameter name="validate-set" value="user-input"/>
> <map:redirect-to resource="simple-page">
> <map:parameter name="target" value="OK"/>
> </map:redirect-to>
> </map:act>
> <map:redirect-to resource="simple-page">
> <map:parameter name="target" value="ERROR"/>
> </map:redirect-to>
> </map:match>
>
> This would be much more consistent.
Vadim, yes that's right. I have reworked the patch so that it stores
the target value with key "target" and that it uses the get-parameter
template which is what other templates use as well. This way target
can be specified either as attribute or as child element.
BUT get-parameter looks for <map:param name="target"></map:param> as
opposed to <map:parameter name="target" value=""/>
Two reasons why I wouldn't like to change this:
1) <map:parameter> is used with elements that can take an arbitrary
number of parameters depending only on the instantiated class while
here it is an optional attribute but there's not going to be
another implementation of <map:redirect-to> at least it is not likely
to have one configurable by the user.
2) I intent to use it in a setting where there's already a rather deep
and complex tree and I would be glad to have this be a one-liner
:-) Otherwise I could have written an action to create and fill a
new map. Of cause there are other (negative) implications on that
path so that wouldn't be a bright idea.
Of cause this is only my opinion and I will support whatever the core
developers decide on this.
Anyway, thanks for the hint.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
RE: [Patch][C2.1] sitemap redirections + target spec
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 21 Jun 2001, Vadim Gritsenko wrote:
> > about making that a transparent choice? e.g.
> >
> > <map:generate type="file" src="foo"/>
> >
> > and
> >
> > <map:generate type="file">
> > <map:parameter name="src" value="foo"/>
> > </map:generate>
> >
> > would appear the same to the FileGenerator...?
>
> But this seems like even better solution.
>
> BTW, Is it FS or not? :)
gack!!! sometimes, it's okay to have more than one way to do things.
really. :)
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Patch][C2.1] sitemap redirections + target spec
Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: Donald Ball [mailto:balld@webslingerZ.com]
>
> On Wed, 20 Jun 2001, Vadim Gritsenko wrote:
>
> > > > The attached patch adds the ability to specify a "target" in a
> > > > <map:redirect-to resource=""> tag. The "target" is available as "{1}"
> > > > in the resource specification.
> > >
> > > Why not as "{target}"? And why not substitutable?
> >
> > I would not say why not to use <map:parameters> as elsewhere else...
> > Like:
> > <map:match pattern="test">
> > <map:act type="form-validator">
> > <map:parameter name="descriptor" value="context:///descriptor.xml"/>
> > <map:parameter name="validate-set" value="user-input"/>
> > <map:redirect-to resource="simple-page">
> > <map:parameter name="target" value="OK"/>
> > </map:redirect-to>
> > </map:act>
> > <map:redirect-to resource="simple-page">
> > <map:parameter name="target" value="ERROR"/>
> > </map:redirect-to>
> > </map:match>
> >
> > This would be much more consistent.
>
> well, there are other sitemap components, e.g. filegenerator, which needs
> to be parameterized with the location of its datasource - and rather than
> using <map:parameter name="src" ... /> we just use a src attribute... i
> guess a rule of thumb would be that components which use a single
> parameter should use an attribute,
Originally I thought that <map:resource> may easily require more then one attribute - that's
why <map:parameter> was suggested...
> while components which use more than
> one parameter should use map:parameter elements. but maybe we should think
> about making that a transparent choice? e.g.
>
> <map:generate type="file" src="foo"/>
>
> and
>
> <map:generate type="file">
> <map:parameter name="src" value="foo"/>
> </map:generate>
>
> would appear the same to the FileGenerator...?
But this seems like even better solution.
BTW, Is it FS or not? :)
>
> - donald
>
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Patch][C2.1] sitemap redirections + target spec
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 20 Jun 2001, Vadim Gritsenko wrote:
> > > The attached patch adds the ability to specify a "target" in a
> > > <map:redirect-to resource=""> tag. The "target" is available as "{1}"
> > > in the resource specification.
> >
> > Why not as "{target}"? And why not substitutable?
>
> I would not say why not to use <map:parameters> as elsewhere else...
> Like:
> <map:match pattern="test">
> <map:act type="form-validator">
> <map:parameter name="descriptor" value="context:///descriptor.xml"/>
> <map:parameter name="validate-set" value="user-input"/>
> <map:redirect-to resource="simple-page">
> <map:parameter name="target" value="OK"/>
> </map:redirect-to>
> </map:act>
> <map:redirect-to resource="simple-page">
> <map:parameter name="target" value="ERROR"/>
> </map:redirect-to>
> </map:match>
>
> This would be much more consistent.
well, there are other sitemap components, e.g. filegenerator, which needs
to be parameterized with the location of its datasource - and rather than
using <map:parameter name="src" ... /> we just use a src attribute... i
guess a rule of thumb would be that components which use a single
parameter should use an attribute, while components which use more than
one parameter should use map:parameter elements. but maybe we should think
about making that a transparent choice? e.g.
<map:generate type="file" src="foo"/>
and
<map:generate type="file">
<map:parameter name="src" value="foo"/>
</map:generate>
would appear the same to the FileGenerator...?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Patch][C2.1] sitemap redirections + target spec
Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: giacomo [mailto:giacomo@apache.org]
> Sent: Wednesday, June 20, 2001 15:26
> To: cocoon-dev@xml.apache.org; haul@informatik.tu-darmstadt.de
> Cc: dims@yahoo.com
> Subject: Re: [Patch][C2.1] sitemap redirections + target spec
>
>
> On Wed, 20 Jun 2001, Christian Haul wrote:
>
> > Hi all.
> >
> > The attached patch adds the ability to specify a "target" in a
> > <map:redirect-to resource=""> tag. The "target" is available as "{1}"
> > in the resource specification.
>
> Why not as "{target}"? And why not substitutable?
I would not say why not to use <map:parameters> as elsewhere else...
Like:
<map:match pattern="test">
<map:act type="form-validator">
<map:parameter name="descriptor" value="context:///descriptor.xml"/>
<map:parameter name="validate-set" value="user-input"/>
<map:redirect-to resource="simple-page">
<map:parameter name="target" value="OK"/>
</map:redirect-to>
</map:act>
<map:redirect-to resource="simple-page">
<map:parameter name="target" value="ERROR"/>
</map:redirect-to>
</map:match>
This would be much more consistent.
Vadim
>
> >
> >
> > Example
> >
> > <map:resources>
> > <map:resource name="simple-page">
> > <map:generate type="serverpages" src="test/{1}.xsp"/>
> > <map:transform src="stylesheets/presentation.xsl"/>
> > <map:transform src="stylesheets/dynamic-page2html.xsl"/>
> > <map:serialize/>
> > </map:resource>
> > </map:resources>
> >
> >
> > <map:pipelines>
> > <map:pipeline>
> >
> > <map:match pattern="test">
> > <map:act type="form-validator">
> > <map:parameter name="descriptor" value="context:///descriptor.xml"/>
> > <map:parameter name="validate-set" value="user-input"/>
> > <map:redirect-to resource="simple-page" target="OK"/>
> > </map:act>
> > <map:redirect-to resource="simple-page" target="ERROR"/>
> > </map:match>
> >
> > </map:pipeline>
> > </map:pipelines>
> >
> > This way it is only necessary to specify required transformation steps
> > only in one place. A redirection to a URL wouldn't work here as that
> > would create a new request object which discards some values. In
> > addition resources are not accessible from outside.
> >
> >
> > Implementation
> >
> > Since maps (listOfMaps) is handed to resources, a new map is added to
> > the listOfMaps with just one entry ("1","@target").
> >
> >
> >
> > Rationale
> >
> > A thing called "flowmap" has been discussed on this list for a long
> > time. Recently I felt the need for such a thing as well. Anyway, it
> > was not clear enough for me in which aspects a flowmap will differ from
> > the sitemap. All in all I believe all the functionality for a flowmap
> > is already present in the sitemap concept.
> >
> > As far as I am concerned, a sitemap would care about the URI mapping
> > and transformation steps. A flowmap would be a XML representation of a
> > state chart with states, sub states, transitions, triggers, guards and
> > actions.
>
> Yes, as Berin once stated the sitemap represents the "resources" and the
> flowmap the "directed graphs" between them.
>
> >
> > States can be represented by matchers, sub states by nested
> > matchers. Triggers are requests (request parameters) which could be
> > represented by selectors. Transitions are allowed paths to other URIs
> > or resources, guards can be realized by cocoon-actions with nested
> > content and actions, well be be realized by cocoon-actions.
> >
> > This way every resource would need a separate definition.
> >
> > The patch allows to redirect to a common definition for
> > transformation. So those two different concerns are separated, even if
> > they live in the same file. Since resources from ancestor sitemaps can
> > be accessed, this could be split up to that resources are only defined
> > in the top level sitemap.
>
> I don't like the fact that sub sitemap refers to parent ones.
> Admittedly sub sitemap already refers to
> sitemap components defined in the parent sitemap. But also Berin
> proposed to move them out of the sitemap right into the cocoon.xconf
> file (where all components are collected anyway).
>
> Giacomo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Patch][C2.1] sitemap redirections + target spec
Posted by giacomo <gi...@apache.org>.
On Wed, 20 Jun 2001, Christian Haul wrote:
> Hi all.
>
> The attached patch adds the ability to specify a "target" in a
> <map:redirect-to resource=""> tag. The "target" is available as "{1}"
> in the resource specification.
Why not as "{target}"? And why not substitutable?
>
>
> Example
>
> <map:resources>
> <map:resource name="simple-page">
> <map:generate type="serverpages" src="test/{1}.xsp"/>
> <map:transform src="stylesheets/presentation.xsl"/>
> <map:transform src="stylesheets/dynamic-page2html.xsl"/>
> <map:serialize/>
> </map:resource>
> </map:resources>
>
>
> <map:pipelines>
> <map:pipeline>
>
> <map:match pattern="test">
> <map:act type="form-validator">
> <map:parameter name="descriptor" value="context:///descriptor.xml"/>
> <map:parameter name="validate-set" value="user-input"/>
> <map:redirect-to resource="simple-page" target="OK"/>
> </map:act>
> <map:redirect-to resource="simple-page" target="ERROR"/>
> </map:match>
>
> </map:pipeline>
> </map:pipelines>
>
> This way it is only necessary to specify required transformation steps
> only in one place. A redirection to a URL wouldn't work here as that
> would create a new request object which discards some values. In
> addition resources are not accessible from outside.
>
>
> Implementation
>
> Since maps (listOfMaps) is handed to resources, a new map is added to
> the listOfMaps with just one entry ("1","@target").
>
>
>
> Rationale
>
> A thing called "flowmap" has been discussed on this list for a long
> time. Recently I felt the need for such a thing as well. Anyway, it
> was not clear enough for me in which aspects a flowmap will differ from
> the sitemap. All in all I believe all the functionality for a flowmap
> is already present in the sitemap concept.
>
> As far as I am concerned, a sitemap would care about the URI mapping
> and transformation steps. A flowmap would be a XML representation of a
> state chart with states, sub states, transitions, triggers, guards and
> actions.
Yes, as Berin once stated the sitemap represents the "resources" and the
flowmap the "directed graphs" between them.
>
> States can be represented by matchers, sub states by nested
> matchers. Triggers are requests (request parameters) which could be
> represented by selectors. Transitions are allowed paths to other URIs
> or resources, guards can be realized by cocoon-actions with nested
> content and actions, well be be realized by cocoon-actions.
>
> This way every resource would need a separate definition.
>
> The patch allows to redirect to a common definition for
> transformation. So those two different concerns are separated, even if
> they live in the same file. Since resources from ancestor sitemaps can
> be accessed, this could be split up to that resources are only defined
> in the top level sitemap.
I don't like the fact that sub sitemap refers to parent ones.
Admittedly sub sitemap already refers to
sitemap components defined in the parent sitemap. But also Berin
proposed to move them out of the sitemap right into the cocoon.xconf
file (where all components are collected anyway).
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org