cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gelo1234 <>
Subject Re: Cocoon 3.0 generators/aggregators/calling controllers/include/xslt questions
Date Sat, 01 Dec 2012 09:36:34 GMT
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
but backing beans/view integration part and most of its lifecycle
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
In JSF 2.2 Java EE spec finally introduced full support for HTML5, so you
can put things like:

<input .....jsf:id="..." jsf:value="..."/>
<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
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.


2012/12/1 Thorsten Scherler <>

> 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=""/>                     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="" ?
> 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.
> > 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 <>
> codeBusters S.L. - web based systems
> <consulting, training and solutions>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message