Re: Cocoon 3.0 generators/aggregators/calling controllers/include/xslt questions
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 mixmatch 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 scher...@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.
Re: Cocoon 3.0 generators/aggregators/calling controllers/include/xslt questions
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 gelo1...@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 gelo1...@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 mixmatch 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
Re: Cocoon 3.0 generators/aggregators/calling controllers/include/xslt questions
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 gelo1...@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 mixmatch 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 scher...@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
Re: Cocoon 3.0 generators/aggregators/calling controllers/include/xslt questions
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=1arg=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-unsubscr...@cocoon.apache.org
For additional commands, e-mail: users-h...@cocoon.apache.org
