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 <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. > > > > 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-unsubscr...@cocoon.apache.org > For additional commands, e-mail: users-h...@cocoon.apache.org > >
