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 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 >>> >>> >> >
