You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by gelo1234 <ge...@gmail.com> on 2012/12/01 01:15:18 UTC
Cocoon 3.0 generators/aggregators/calling controllers/include/xslt questions
Hello,
I was trying to find some samples from current C3.0 implementation to know
more
about C3.0 but some information is absent.
Perhaps someone here could answer that:
In some old Cocoon release (2.x) there was a possibility to define
multipart generators, something like:
<map:match="xxx">
<map:aggregate element="Page">
<map:part
src="dir/file1.xml"/> a)
<map:part
src="dir/file2.xml"/> b)
<map:part src="cocoon://call_some_match_generating_XML"/> c)
<map:part src="http://somedomain.com/file3.xml"/>
d)
</map:aggregate>
...
</map:match>
1. Is it still possible with C3.0 ? Especially c) option to call some
sitemapservlet ?
2. If i implement my own SAXGenerator can I use it as c) option here ?
(How?):
<map:part type="my-custom"/> ??
3. Is d) valid ?
4. Can i pass additional parameters to c)
like: <map:part src="cocoon://call_some_match_generating_XML?arg=1&arg=2"/>
Are request parameters INHERITED from calling pipeline match ?
5. Can we use simple Java Controller (but NOT rest-controller?) and still
have access
to QueryString Parameters/HTTP Request object within such sitemapservlet ?
What should such a Java class extend or implement? and how does the spring
bean/config for that Controller may look like ?
Will it be still Controller or SAXGenerator ?
6. What is the main difference between include and xinclude (apart from the
fact the
first is cocoon spec? impl while the other is w3c spec impl by cocoon?)
Isn't include cacheable either ?
Can i include/xinclude external src data e.g. src="
http://somedomain.com/file.xml" ?
5. Can I call other REST Controller from REST Controller ?
6. Do XSLT transformations by default have access to ALL QueryString params
with
<xsl:param name="arg1"/>
<xsl:param name="arg2"/>
...
<xsl:param name="argn"/>
without explicitly defining each one in the pipeline as some
{jexl:cocoon.request.param1}?
as map parameters for the XSL transformer ?
Thank you for your time and answers.
We are still hesitating whether to upgrade to Cocoon3.0/Spring or Java EE
stack.
Greetings,
-Greg
Re: Cocoon 3.0 generators/aggregators/calling controllers/include/xslt
questions
Posted by gelo1234 <ge...@gmail.com>.
You can also have a look at Restlet framework (http://www.restlet.org/)
which I think could be a direct competitor to Cocoon,
but despite its powerful filtering/routing layers, the routes are defined
either in Java code or Spring-like way (too much verbose XML), which
is kind of headache :) to me when you just used to simple and clear sitemap
pipelines :)
That's why I think servlet-sitemap component of Cocoon is really what makes
Cocoon the most flexible/easy in terms of web programming.
Greetings,
-Greg
2012/12/1 gelo1234 <ge...@gmail.com>
>
> One more note:
>
> Typical ESBs don't describe the application structure! They only
> mediate/route messages between external services.
> You can use SCA model (typicall in SOA environment) which DOES
> support/describe/define application structure/architecture - like Apache
> Tuscany with its Assembly Model, but still I consider Tuscany to be less
> powerful and less flexible than Cocoon.
>
> Of course you can also go for BPM frameworks, where you can distincly
> define flows/workflows, processes in the system/application
> but in my opinion BPM should be used to optimize the business processes in
> the system when you already have some system
> architecture in place. BPM should not be used for _integration_ purposes.
>
> Thats why I really consider Cocoon to have features most wanted in terms
> of ESB and EAI.
>
> Greetings,
> -Greg
>
>
> 2012/12/1 gelo1234 <ge...@gmail.com>
>
>>
>> Thank you Thorsten,
>>
>> That clarified a lot of things to me for now. I will take a deeper look
>> into C3.0 docs/samples.
>> Aggregators/Aggregation would be a nice generation-optional module? to
>> add into C3 in the future :)
>>
>> What relates to JSF to be integrated within Cocoon, that would be a kind
>> of interesting feature
>> to have a look at.
>> My private opinion is though that I don't really like JSF, not the flow
>> model,
>> but backing beans/view integration part and most of its lifecycle
>> management.
>> I have to admit even Spring Web MVC is much more "cleaner" in my opinion.
>> I hate also the autogeneration of html (or other view layer format) by
>> JSF.
>> You don't have full control over generated output, when you need to put
>> css/javascript/ajax/html snippets/tweaking
>> into some JSF custom attribute/element tags, not just like it is with RAW
>> html.
>> In JSF 2.2 Java EE spec finally introduced full support for HTML5, so you
>> can put things like:
>>
>> <input .....jsf:id="..." jsf:value="..."/>
>> not
>> <h:inputText id="..." value="..."/>
>>
>> to fully exploit browser features and HTML5.
>> I do like Composite elements because you can use lots of custom
>> templating in output HTML.
>>
>> But in summary there are more cons than pros in JSF for what I want to
>> see in a View part of MVC.
>>
>> What I actually miss in C3.0 is that general type of Controller (in terms
>> of MVC). OK, you have
>> REST Controller, but not everybody wants to or not everywhere you need to
>> use RESTfull services.
>> In very old Cocoon (2.0?) there was XSP. That was a kind of such
>> controller, where you could put
>> some arbitrary Java code and enrich the data in the pipeline however you
>> wanted (call external
>> web services, get data from database, JMS, EJB, whatever). The fact it
>> was very general in nature
>> made it so robust (but for some it was rather a limitation and not very
>> clean technology in terms of separating
>> model/controller/view layers). Perhaps that's why it got deprecated in
>> C2.1 or C2.2. But I do miss
>> that kind of general "controller". What Cocoon always sucked at is
>> database handling.
>> Of course you can have spring/hibernate configuration and use it in REST
>> controller now, or
>> in some custom Aggregators. You can also use SQLTransformer and other
>> kinds of mix&match
>> configs (without Hibernate because not everybody wants to use ORM), but
>> each one mentioned
>> has some drawbacks, depending on what you need. Well you can also use
>> database access
>> from flowscript in C2.1/2? But just a general controller would be a nice
>> to have, where you can
>> put all your persistence logic into (speaking in terms of JPA -
>> EntityManager, PersistenceContext etc.)
>>
>> I tend to consider C3.0 now (from what you said) as a good element (that
>> play nicely) in the Java EE stack,
>> because it can be used as a separate library/component now without even a
>> need for a Java EE container or external servlet engine.
>> But I think the servlet-sitemap component is the most powerful concept in
>> Cocoon when it is used as a web framework.
>> I was looking for the appropriate ESB that would be as much flexible in
>> terms of routing/mediating as older
>> versions of Cocoon were and I didn't find such any. My opinion is that
>> the best advantage of Cocoon lays
>> in its routing/URL handling/RESTfull/pipelining features.
>> And as I see it now I would like Cocoon to be the main part in my system
>> (with its ROLE as a main Enterprise Service Bus) while other
>> Java EE components be used from inside or outside that ESB. I think about
>> that kind of architecture model.
>>
>> Greetings,
>> -Greg
>>
>>
>>
>>
>> 2012/12/1 Thorsten Scherler <sc...@gmail.com>
>>
>>> On 12/01/2012 01:15 AM, gelo1234 wrote:
>>> >
>>> > Hello,
>>> >
>>> > I was trying to find some samples from current C3.0 implementation to
>>> > know more
>>> > about C3.0 but some information is absent.
>>> >
>>> > Perhaps someone here could answer that:
>>> >
>>> > In some old Cocoon release (2.x) there was a possibility to define
>>> > multipart generators, something like:
>>> >
>>> > <map:match="xxx">
>>> > <map:aggregate element="Page">
>>> > <map:part
>>> > src="dir/file1.xml"/>
>>> > a)
>>> > <map:part
>>> > src="dir/file2.xml"/>
>>> > b)
>>> > <map:part src="cocoon://call_some_match_generating_XML"/> c)
>>> > <map:part
>>> > src="http://somedomain.com/file3.xml"/> d)
>>> > </map:aggregate>
>>> > ...
>>> > </map:match>
>>> >
>>> > 1. Is it still possible with C3.0 ? Especially c) option to call some
>>> > sitemapservlet ?
>>>
>>> In general the aggregate has not been implemented in c3. However you can
>>> do the same with a xml file for you define the includes and the
>>> transform it with the include transformer. Regarding c) that is since
>>> 2.2 servlet: you can find some docs around it.
>>>
>>> >
>>> > 2. If i implement my own SAXGenerator can I use it as c) option here ?
>>> > (How?):
>>> > <map:part type="my-custom"/> ??
>>>
>>> not sure what you mean but I think the include example in the c3 samples
>>> will show you how to include.
>>> >
>>> > 3. Is d) valid ?
>>>
>>> well that depend on so many different things. If you refer "as is" yes
>>> as construct. Actually all components work against urls. If you refer
>>> whether the outcome is valid xml - you can make sure with the neko html
>>> generator.
>>> >
>>> > 4. Can i pass additional parameters to c)
>>> > like: <map:part
>>> > src="cocoon://call_some_match_generating_XML?arg=1&arg=2"/>
>>> > Are request parameters INHERITED from calling pipeline match ?
>>> >
>>>
>>> hmm they are normal urls. Query parameter are fully supported. Not sure
>>> about the second part of the point but you can use {map:1} to access the
>>> fist matching group of your match.
>>>
>>> > 5. Can we use simple Java Controller (but NOT rest-controller?) and
>>> > still have access
>>> > to QueryString Parameters/HTTP Request object within such
>>> sitemapservlet ?
>>>
>>> I am currently working on a project that is based on JSF. You can make
>>> cocoon3 work along with anything it always depends on what benefit you
>>> want to get from cocoon or another part. However as soon my project ends
>>> I will look into using JSF in cocoon since I have to admit the form
>>> handling and some contract/widget are really nice and easy to use.
>>> However for form handling see the cocoon-wicket integration where you
>>> integrate wicket into cocoon or vice versa depending on the main usage.
>>> I you have many forms and little content you would go for the second
>>> option.
>>>
>>> However there is no support for other controller then REST to access the
>>> sitemap parameter.
>>>
>>> > What should such a Java class extend or implement? and how does the
>>> spring
>>> > bean/config for that Controller may look like ?
>>>
>>> Not sure.
>>>
>>> > Will it be still Controller or SAXGenerator ?
>>>
>>>
>>> Currently you have either a normal generator/reader/... but you can
>>> implement a sitemap Starter and do as you please. However see the wicket
>>> integration on how to handle other controller and cocoon side by side.
>>> >
>>> > 6. What is the main difference between include and xinclude (apart
>>> > from the fact the
>>> > first is cocoon spec? impl while the other is w3c spec impl by cocoon?)
>>> > Isn't include cacheable either ?
>>> > Can i include/xinclude external src data e.g.
>>> > src="http://somedomain.com/file.xml" ?
>>>
>>> Please see the docs and the mailing archive it is really good covered.
>>>
>>> >
>>> > 5. Can I call other REST Controller from REST Controller ?
>>>
>>> As in URL calls, yeah why not.
>>>
>>> >
>>> > 6. Do XSLT transformations by default have access to ALL QueryString
>>> > params
>>> > with
>>> > <xsl:param name="arg1"/>
>>> > <xsl:param name="arg2"/>
>>> > ...
>>> > <xsl:param name="argn"/>
>>> >
>>> > without explicitly defining each one in the pipeline as some
>>> > {jexl:cocoon.request.param1}?
>>> > as map parameters for the XSL transformer ?
>>>
>>> Not sure about it, in 2.x there where a flag for it AFAIR and if so it
>>> would be easy to migrate to c3.
>>>
>>> HTH
>>>
>>> > Thank you for your time and answers.
>>> >
>>> > We are still hesitating whether to upgrade to Cocoon3.0/Spring or Java
>>> > EE stack.
>>>
>>> It is no either or anymore since you can use c3 in a java based pipeline
>>> for certain processes.
>>>
>>> salu2
>>>
>>> >
>>> > Greetings,
>>> > -Greg
>>> >
>>>
>>>
>>> --
>>> Thorsten Scherler <scherler.at.gmail.com>
>>> codeBusters S.L. - web based systems
>>> <consulting, training and solutions>
>>>
>>> http://www.codebusters.es/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>>> For additional commands, e-mail: users-help@cocoon.apache.org
>>>
>>>
>>
>
Re: Cocoon 3.0 generators/aggregators/calling controllers/include/xslt
questions
Posted by gelo1234 <ge...@gmail.com>.
One more note:
Typical ESBs don't describe the application structure! They only
mediate/route messages between external services.
You can use SCA model (typicall in SOA environment) which DOES
support/describe/define application structure/architecture - like Apache
Tuscany with its Assembly Model, but still I consider Tuscany to be less
powerful and less flexible than Cocoon.
Of course you can also go for BPM frameworks, where you can distincly
define flows/workflows, processes in the system/application
but in my opinion BPM should be used to optimize the business processes in
the system when you already have some system
architecture in place. BPM should not be used for _integration_ purposes.
Thats why I really consider Cocoon to have features most wanted in terms of
ESB and EAI.
Greetings,
-Greg
2012/12/1 gelo1234 <ge...@gmail.com>
>
> Thank you Thorsten,
>
> That clarified a lot of things to me for now. I will take a deeper look
> into C3.0 docs/samples.
> Aggregators/Aggregation would be a nice generation-optional module? to add
> into C3 in the future :)
>
> What relates to JSF to be integrated within Cocoon, that would be a kind
> of interesting feature
> to have a look at.
> My private opinion is though that I don't really like JSF, not the flow
> model,
> but backing beans/view integration part and most of its lifecycle
> management.
> I have to admit even Spring Web MVC is much more "cleaner" in my opinion.
> I hate also the autogeneration of html (or other view layer format) by JSF.
> You don't have full control over generated output, when you need to put
> css/javascript/ajax/html snippets/tweaking
> into some JSF custom attribute/element tags, not just like it is with RAW
> html.
> In JSF 2.2 Java EE spec finally introduced full support for HTML5, so you
> can put things like:
>
> <input .....jsf:id="..." jsf:value="..."/>
> not
> <h:inputText id="..." value="..."/>
>
> to fully exploit browser features and HTML5.
> I do like Composite elements because you can use lots of custom templating
> in output HTML.
>
> But in summary there are more cons than pros in JSF for what I want to see
> in a View part of MVC.
>
> What I actually miss in C3.0 is that general type of Controller (in terms
> of MVC). OK, you have
> REST Controller, but not everybody wants to or not everywhere you need to
> use RESTfull services.
> In very old Cocoon (2.0?) there was XSP. That was a kind of such
> controller, where you could put
> some arbitrary Java code and enrich the data in the pipeline however you
> wanted (call external
> web services, get data from database, JMS, EJB, whatever). The fact it was
> very general in nature
> made it so robust (but for some it was rather a limitation and not very
> clean technology in terms of separating
> model/controller/view layers). Perhaps that's why it got deprecated in
> C2.1 or C2.2. But I do miss
> that kind of general "controller". What Cocoon always sucked at is
> database handling.
> Of course you can have spring/hibernate configuration and use it in REST
> controller now, or
> in some custom Aggregators. You can also use SQLTransformer and other
> kinds of mix&match
> configs (without Hibernate because not everybody wants to use ORM), but
> each one mentioned
> has some drawbacks, depending on what you need. Well you can also use
> database access
> from flowscript in C2.1/2? But just a general controller would be a nice
> to have, where you can
> put all your persistence logic into (speaking in terms of JPA -
> EntityManager, PersistenceContext etc.)
>
> I tend to consider C3.0 now (from what you said) as a good element (that
> play nicely) in the Java EE stack,
> because it can be used as a separate library/component now without even a
> need for a Java EE container or external servlet engine.
> But I think the servlet-sitemap component is the most powerful concept in
> Cocoon when it is used as a web framework.
> I was looking for the appropriate ESB that would be as much flexible in
> terms of routing/mediating as older
> versions of Cocoon were and I didn't find such any. My opinion is that the
> best advantage of Cocoon lays
> in its routing/URL handling/RESTfull/pipelining features.
> And as I see it now I would like Cocoon to be the main part in my system
> (with its ROLE as a main Enterprise Service Bus) while other
> Java EE components be used from inside or outside that ESB. I think about
> that kind of architecture model.
>
> Greetings,
> -Greg
>
>
>
>
> 2012/12/1 Thorsten Scherler <sc...@gmail.com>
>
>> On 12/01/2012 01:15 AM, gelo1234 wrote:
>> >
>> > Hello,
>> >
>> > I was trying to find some samples from current C3.0 implementation to
>> > know more
>> > about C3.0 but some information is absent.
>> >
>> > Perhaps someone here could answer that:
>> >
>> > In some old Cocoon release (2.x) there was a possibility to define
>> > multipart generators, something like:
>> >
>> > <map:match="xxx">
>> > <map:aggregate element="Page">
>> > <map:part
>> > src="dir/file1.xml"/>
>> > a)
>> > <map:part
>> > src="dir/file2.xml"/>
>> > b)
>> > <map:part src="cocoon://call_some_match_generating_XML"/> c)
>> > <map:part
>> > src="http://somedomain.com/file3.xml"/> d)
>> > </map:aggregate>
>> > ...
>> > </map:match>
>> >
>> > 1. Is it still possible with C3.0 ? Especially c) option to call some
>> > sitemapservlet ?
>>
>> In general the aggregate has not been implemented in c3. However you can
>> do the same with a xml file for you define the includes and the
>> transform it with the include transformer. Regarding c) that is since
>> 2.2 servlet: you can find some docs around it.
>>
>> >
>> > 2. If i implement my own SAXGenerator can I use it as c) option here ?
>> > (How?):
>> > <map:part type="my-custom"/> ??
>>
>> not sure what you mean but I think the include example in the c3 samples
>> will show you how to include.
>> >
>> > 3. Is d) valid ?
>>
>> well that depend on so many different things. If you refer "as is" yes
>> as construct. Actually all components work against urls. If you refer
>> whether the outcome is valid xml - you can make sure with the neko html
>> generator.
>> >
>> > 4. Can i pass additional parameters to c)
>> > like: <map:part
>> > src="cocoon://call_some_match_generating_XML?arg=1&arg=2"/>
>> > Are request parameters INHERITED from calling pipeline match ?
>> >
>>
>> hmm they are normal urls. Query parameter are fully supported. Not sure
>> about the second part of the point but you can use {map:1} to access the
>> fist matching group of your match.
>>
>> > 5. Can we use simple Java Controller (but NOT rest-controller?) and
>> > still have access
>> > to QueryString Parameters/HTTP Request object within such
>> sitemapservlet ?
>>
>> I am currently working on a project that is based on JSF. You can make
>> cocoon3 work along with anything it always depends on what benefit you
>> want to get from cocoon or another part. However as soon my project ends
>> I will look into using JSF in cocoon since I have to admit the form
>> handling and some contract/widget are really nice and easy to use.
>> However for form handling see the cocoon-wicket integration where you
>> integrate wicket into cocoon or vice versa depending on the main usage.
>> I you have many forms and little content you would go for the second
>> option.
>>
>> However there is no support for other controller then REST to access the
>> sitemap parameter.
>>
>> > What should such a Java class extend or implement? and how does the
>> spring
>> > bean/config for that Controller may look like ?
>>
>> Not sure.
>>
>> > Will it be still Controller or SAXGenerator ?
>>
>>
>> Currently you have either a normal generator/reader/... but you can
>> implement a sitemap Starter and do as you please. However see the wicket
>> integration on how to handle other controller and cocoon side by side.
>> >
>> > 6. What is the main difference between include and xinclude (apart
>> > from the fact the
>> > first is cocoon spec? impl while the other is w3c spec impl by cocoon?)
>> > Isn't include cacheable either ?
>> > Can i include/xinclude external src data e.g.
>> > src="http://somedomain.com/file.xml" ?
>>
>> Please see the docs and the mailing archive it is really good covered.
>>
>> >
>> > 5. Can I call other REST Controller from REST Controller ?
>>
>> As in URL calls, yeah why not.
>>
>> >
>> > 6. Do XSLT transformations by default have access to ALL QueryString
>> > params
>> > with
>> > <xsl:param name="arg1"/>
>> > <xsl:param name="arg2"/>
>> > ...
>> > <xsl:param name="argn"/>
>> >
>> > without explicitly defining each one in the pipeline as some
>> > {jexl:cocoon.request.param1}?
>> > as map parameters for the XSL transformer ?
>>
>> Not sure about it, in 2.x there where a flag for it AFAIR and if so it
>> would be easy to migrate to c3.
>>
>> HTH
>>
>> > Thank you for your time and answers.
>> >
>> > We are still hesitating whether to upgrade to Cocoon3.0/Spring or Java
>> > EE stack.
>>
>> It is no either or anymore since you can use c3 in a java based pipeline
>> for certain processes.
>>
>> salu2
>>
>> >
>> > Greetings,
>> > -Greg
>> >
>>
>>
>> --
>> Thorsten Scherler <scherler.at.gmail.com>
>> codeBusters S.L. - web based systems
>> <consulting, training and solutions>
>>
>> http://www.codebusters.es/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>
Re: Cocoon 3.0 generators/aggregators/calling controllers/include/xslt
questions
Posted by gelo1234 <ge...@gmail.com>.
Thank you Thorsten,
That clarified a lot of things to me for now. I will take a deeper look
into C3.0 docs/samples.
Aggregators/Aggregation would be a nice generation-optional module? to add
into C3 in the future :)
What relates to JSF to be integrated within Cocoon, that would be a kind of
interesting feature
to have a look at.
My private opinion is though that I don't really like JSF, not the flow
model,
but backing beans/view integration part and most of its lifecycle
management.
I have to admit even Spring Web MVC is much more "cleaner" in my opinion.
I hate also the autogeneration of html (or other view layer format) by JSF.
You don't have full control over generated output, when you need to put
css/javascript/ajax/html snippets/tweaking
into some JSF custom attribute/element tags, not just like it is with RAW
html.
In JSF 2.2 Java EE spec finally introduced full support for HTML5, so you
can put things like:
<input .....jsf:id="..." jsf:value="..."/>
not
<h:inputText id="..." value="..."/>
to fully exploit browser features and HTML5.
I do like Composite elements because you can use lots of custom templating
in output HTML.
But in summary there are more cons than pros in JSF for what I want to see
in a View part of MVC.
What I actually miss in C3.0 is that general type of Controller (in terms
of MVC). OK, you have
REST Controller, but not everybody wants to or not everywhere you need to
use RESTfull services.
In very old Cocoon (2.0?) there was XSP. That was a kind of such
controller, where you could put
some arbitrary Java code and enrich the data in the pipeline however you
wanted (call external
web services, get data from database, JMS, EJB, whatever). The fact it was
very general in nature
made it so robust (but for some it was rather a limitation and not very
clean technology in terms of separating
model/controller/view layers). Perhaps that's why it got deprecated in C2.1
or C2.2. But I do miss
that kind of general "controller". What Cocoon always sucked at is database
handling.
Of course you can have spring/hibernate configuration and use it in REST
controller now, or
in some custom Aggregators. You can also use SQLTransformer and other kinds
of mix&match
configs (without Hibernate because not everybody wants to use ORM), but
each one mentioned
has some drawbacks, depending on what you need. Well you can also use
database access
from flowscript in C2.1/2? But just a general controller would be a nice to
have, where you can
put all your persistence logic into (speaking in terms of JPA -
EntityManager, PersistenceContext etc.)
I tend to consider C3.0 now (from what you said) as a good element (that
play nicely) in the Java EE stack,
because it can be used as a separate library/component now without even a
need for a Java EE container or external servlet engine.
But I think the servlet-sitemap component is the most powerful concept in
Cocoon when it is used as a web framework.
I was looking for the appropriate ESB that would be as much flexible in
terms of routing/mediating as older
versions of Cocoon were and I didn't find such any. My opinion is that the
best advantage of Cocoon lays
in its routing/URL handling/RESTfull/pipelining features.
And as I see it now I would like Cocoon to be the main part in my system
(with its ROLE as a main Enterprise Service Bus) while other
Java EE components be used from inside or outside that ESB. I think about
that kind of architecture model.
Greetings,
-Greg
2012/12/1 Thorsten Scherler <sc...@gmail.com>
> On 12/01/2012 01:15 AM, gelo1234 wrote:
> >
> > Hello,
> >
> > I was trying to find some samples from current C3.0 implementation to
> > know more
> > about C3.0 but some information is absent.
> >
> > Perhaps someone here could answer that:
> >
> > In some old Cocoon release (2.x) there was a possibility to define
> > multipart generators, something like:
> >
> > <map:match="xxx">
> > <map:aggregate element="Page">
> > <map:part
> > src="dir/file1.xml"/>
> > a)
> > <map:part
> > src="dir/file2.xml"/>
> > b)
> > <map:part src="cocoon://call_some_match_generating_XML"/> c)
> > <map:part
> > src="http://somedomain.com/file3.xml"/> d)
> > </map:aggregate>
> > ...
> > </map:match>
> >
> > 1. Is it still possible with C3.0 ? Especially c) option to call some
> > sitemapservlet ?
>
> In general the aggregate has not been implemented in c3. However you can
> do the same with a xml file for you define the includes and the
> transform it with the include transformer. Regarding c) that is since
> 2.2 servlet: you can find some docs around it.
>
> >
> > 2. If i implement my own SAXGenerator can I use it as c) option here ?
> > (How?):
> > <map:part type="my-custom"/> ??
>
> not sure what you mean but I think the include example in the c3 samples
> will show you how to include.
> >
> > 3. Is d) valid ?
>
> well that depend on so many different things. If you refer "as is" yes
> as construct. Actually all components work against urls. If you refer
> whether the outcome is valid xml - you can make sure with the neko html
> generator.
> >
> > 4. Can i pass additional parameters to c)
> > like: <map:part
> > src="cocoon://call_some_match_generating_XML?arg=1&arg=2"/>
> > Are request parameters INHERITED from calling pipeline match ?
> >
>
> hmm they are normal urls. Query parameter are fully supported. Not sure
> about the second part of the point but you can use {map:1} to access the
> fist matching group of your match.
>
> > 5. Can we use simple Java Controller (but NOT rest-controller?) and
> > still have access
> > to QueryString Parameters/HTTP Request object within such sitemapservlet
> ?
>
> I am currently working on a project that is based on JSF. You can make
> cocoon3 work along with anything it always depends on what benefit you
> want to get from cocoon or another part. However as soon my project ends
> I will look into using JSF in cocoon since I have to admit the form
> handling and some contract/widget are really nice and easy to use.
> However for form handling see the cocoon-wicket integration where you
> integrate wicket into cocoon or vice versa depending on the main usage.
> I you have many forms and little content you would go for the second
> option.
>
> However there is no support for other controller then REST to access the
> sitemap parameter.
>
> > What should such a Java class extend or implement? and how does the
> spring
> > bean/config for that Controller may look like ?
>
> Not sure.
>
> > Will it be still Controller or SAXGenerator ?
>
>
> Currently you have either a normal generator/reader/... but you can
> implement a sitemap Starter and do as you please. However see the wicket
> integration on how to handle other controller and cocoon side by side.
> >
> > 6. What is the main difference between include and xinclude (apart
> > from the fact the
> > first is cocoon spec? impl while the other is w3c spec impl by cocoon?)
> > Isn't include cacheable either ?
> > Can i include/xinclude external src data e.g.
> > src="http://somedomain.com/file.xml" ?
>
> Please see the docs and the mailing archive it is really good covered.
>
> >
> > 5. Can I call other REST Controller from REST Controller ?
>
> As in URL calls, yeah why not.
>
> >
> > 6. Do XSLT transformations by default have access to ALL QueryString
> > params
> > with
> > <xsl:param name="arg1"/>
> > <xsl:param name="arg2"/>
> > ...
> > <xsl:param name="argn"/>
> >
> > without explicitly defining each one in the pipeline as some
> > {jexl:cocoon.request.param1}?
> > as map parameters for the XSL transformer ?
>
> Not sure about it, in 2.x there where a flag for it AFAIR and if so it
> would be easy to migrate to c3.
>
> HTH
>
> > Thank you for your time and answers.
> >
> > We are still hesitating whether to upgrade to Cocoon3.0/Spring or Java
> > EE stack.
>
> It is no either or anymore since you can use c3 in a java based pipeline
> for certain processes.
>
> salu2
>
> >
> > Greetings,
> > -Greg
> >
>
>
> --
> Thorsten Scherler <scherler.at.gmail.com>
> codeBusters S.L. - web based systems
> <consulting, training and solutions>
>
> http://www.codebusters.es/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
Re: Cocoon 3.0 generators/aggregators/calling controllers/include/xslt
questions
Posted by Thorsten Scherler <sc...@gmail.com>.
On 12/01/2012 01:15 AM, gelo1234 wrote:
>
> Hello,
>
> I was trying to find some samples from current C3.0 implementation to
> know more
> about C3.0 but some information is absent.
>
> Perhaps someone here could answer that:
>
> In some old Cocoon release (2.x) there was a possibility to define
> multipart generators, something like:
>
> <map:match="xxx">
> <map:aggregate element="Page">
> <map:part
> src="dir/file1.xml"/>
> a)
> <map:part
> src="dir/file2.xml"/>
> b)
> <map:part src="cocoon://call_some_match_generating_XML"/> c)
> <map:part
> src="http://somedomain.com/file3.xml"/> d)
> </map:aggregate>
> ...
> </map:match>
>
> 1. Is it still possible with C3.0 ? Especially c) option to call some
> sitemapservlet ?
In general the aggregate has not been implemented in c3. However you can
do the same with a xml file for you define the includes and the
transform it with the include transformer. Regarding c) that is since
2.2 servlet: you can find some docs around it.
>
> 2. If i implement my own SAXGenerator can I use it as c) option here ?
> (How?):
> <map:part type="my-custom"/> ??
not sure what you mean but I think the include example in the c3 samples
will show you how to include.
>
> 3. Is d) valid ?
well that depend on so many different things. If you refer "as is" yes
as construct. Actually all components work against urls. If you refer
whether the outcome is valid xml - you can make sure with the neko html
generator.
>
> 4. Can i pass additional parameters to c)
> like: <map:part
> src="cocoon://call_some_match_generating_XML?arg=1&arg=2"/>
> Are request parameters INHERITED from calling pipeline match ?
>
hmm they are normal urls. Query parameter are fully supported. Not sure
about the second part of the point but you can use {map:1} to access the
fist matching group of your match.
> 5. Can we use simple Java Controller (but NOT rest-controller?) and
> still have access
> to QueryString Parameters/HTTP Request object within such sitemapservlet ?
I am currently working on a project that is based on JSF. You can make
cocoon3 work along with anything it always depends on what benefit you
want to get from cocoon or another part. However as soon my project ends
I will look into using JSF in cocoon since I have to admit the form
handling and some contract/widget are really nice and easy to use.
However for form handling see the cocoon-wicket integration where you
integrate wicket into cocoon or vice versa depending on the main usage.
I you have many forms and little content you would go for the second option.
However there is no support for other controller then REST to access the
sitemap parameter.
> What should such a Java class extend or implement? and how does the spring
> bean/config for that Controller may look like ?
Not sure.
> Will it be still Controller or SAXGenerator ?
Currently you have either a normal generator/reader/... but you can
implement a sitemap Starter and do as you please. However see the wicket
integration on how to handle other controller and cocoon side by side.
>
> 6. What is the main difference between include and xinclude (apart
> from the fact the
> first is cocoon spec? impl while the other is w3c spec impl by cocoon?)
> Isn't include cacheable either ?
> Can i include/xinclude external src data e.g.
> src="http://somedomain.com/file.xml" ?
Please see the docs and the mailing archive it is really good covered.
>
> 5. Can I call other REST Controller from REST Controller ?
As in URL calls, yeah why not.
>
> 6. Do XSLT transformations by default have access to ALL QueryString
> params
> with
> <xsl:param name="arg1"/>
> <xsl:param name="arg2"/>
> ...
> <xsl:param name="argn"/>
>
> without explicitly defining each one in the pipeline as some
> {jexl:cocoon.request.param1}?
> as map parameters for the XSL transformer ?
Not sure about it, in 2.x there where a flag for it AFAIR and if so it
would be easy to migrate to c3.
HTH
> Thank you for your time and answers.
>
> We are still hesitating whether to upgrade to Cocoon3.0/Spring or Java
> EE stack.
It is no either or anymore since you can use c3 in a java based pipeline
for certain processes.
salu2
>
> Greetings,
> -Greg
>
--
Thorsten Scherler <scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org