cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gelo1234 <gelo1...@gmail.com>
Subject Re: Cocoon 3.0 generators/aggregators/calling controllers/include/xslt questions
Date Sat, 01 Dec 2012 09:46:54 GMT
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 <gelo1234@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 <scherler@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
>>
>>
>

Mime
View raw message