Hello together! After one week constantly comming to grasp with usage of cocoon 2.2 there are still several things wich are confusing. Of course, it has to be like that after only one week. As I've done before in some other threads I will go into this one with statement: I am not here to bother anybody! My goal is to share my experience and hopefully this will give some mind-food to think about and as a 'best-possible-result' extend my knowledge via comments from you all. In conjunction, this talk here will look like a 'pros and cons' of beeing guided to usage of cocoon through available documentation. At certain points I will try to examine the consequences of (at this time) distributed and somewhat incomplete cocoon documentation. I will try to achieve this via discussion of the block-design I want to create within a web-application project.
Before getting into that, I'd fairly like to state, that I had some experience with the Spring-framework before getting addicted to cocoons-concepts. Cocoon's spring-integration was the main reason for me to start with 2.2. Also some experience with main concepts like pipelines/generators/transformers/serializers were available (from usage of 2.1). At this point I've finished the 'main' tutorials wich are available at http://cocoon.apache.org/1370_1_1.html, deeling with: - Your first Cocoon application using maven 2 - Your first XML pipeline (publishing) - Modularize Cocoon apps (Using blocks) - Deploying a Cocoon application --> pros and cons <-- --- (1) --- Before cocoon22 I used Ant as my build-tool. After reading some other discussions (e.g. http://danilogurovich.wordpress.com/2007/11/09/struts-vs-cocoon-why-cocoon-lost-the-battle/) I recognized the existing opinions about usage of maven. My impression is, that for cocoon-newbies the maven-way is elegant during first step development. I always enjoy concepts/tools making my life easier. But the tutorials look somewhat inconsistent due to the lack of founded theory introduction to cocoon22 (beside some refinements that need to be done to get the samples run the way they should like, e.g. within the 'mount your block at root level'-step of the last tutorial). I think that such a 'USERS!'-introduction should at least contain information about - main concepts like pipelines/generators/... AND what changed since 2.1! - this should guide absolute newbies and leave them with impressions of the power that those concepts involve (and there is a lot of power!) - If there are dramatic changes of cocoons main-concepts (NOT BLOCKS!!!) this should be stated, even a little state like 'there are no changes in using pipelines/generators/...' would help a lot! - new block concepts - It was Grzegorz Kossakowski (THANKS!) who gives the information about blocks and what problems they generally solve (thread: Help with cocoon and spring [January 2008]) - so what i missed upfront was the theory about 22-blocks in a somwhat 'this-is-the-old-using-servlets-by- yourself'- and the 'this-is-what-cocoon-enable-you-to-do-with-blocks'-like way. - Servlet-Service-Framework (SSF) should be mentioned/introduced - what cocoon-22-archetype-block exaclty contains and WHY! - I am aware of the general block-structure at http://cocoon.apache.org/2.2/core-modules/core/2.2/1263_1_1.html - So what am I confuses about?: - to get involved and start playing with cocoon-22-blocks it is nice to have things like maven-plugin, rcl and eclipse-plugin. Same is true (for first-steps-and-testing puprpose) for jetty. But does it mean that I (as new user) have to rely on those tools (I know, that of course not!). And - more important - what are these tools and wich role the could/should play inside a real-world-app, e.g. how to get rid of them before deploying a final app to some servelt-container? - maybe a connection to mavens running-modes could bring some light inside here - It is the archetype 'block' structure itself, that is confusing: - Why not having final-app archetypes excluding unimportant stuff, but including a more to real- world-app directory-structure for flows/forms/jxtemplates/css/...? - I recognized your goal to standardize app-lifecycle and I agree with that. I assume, that available block-archetypes also aim at freedom in usage. That is very very important! What I miss at this point is a balanced diverse block-archetype-repo. This seamlessly leads to my next thought. - best practice block-patterns (e.g. main controller) - The freedom of creating the blocks I like and put them into an interoperable state (transfere from AOP- concepts into the servlet context) is a concept wich powers I am only able to estimate so far. For me personal (and with the discussion from http://article.gmane.org/gmane.text.xml.cocoon.devel/74571 in mind) your implementation of SSF is the brought-into-beeing promise of Rod Johnson about how AOP possibly changes the thoughts about howto design (web-)applications. - What could result into better documentation of those concepts is a somwhat 'usage-scenario-guide'. - The available spring-framework documentation introduces different usage-scenarios in the very beginning and this leaves the user with an impression what could be achieved with spring. This should be created for cocoon as well. - I think that with cocoon and spring it would be a fairly simple scenario to show how a main-controller (mainBlock) could be created and supported by several sub-controllers all operating on some (simple) domainmodel. - this is what I am trying to achieve at the moment, because it is fancy what cocoon-community makes possible by integrating spring. - At this point it would help a lot if users could get a more detailed introduction of how inter-block- communication works and how it could be configured well. The standard block cogs, represented as several configuration files, should be explained as a whole. My following picture shows (far to simple, but to the point) what such a controller should do (also firmly advised by Grzegorz, showing me that my thoughts are not THAT stupid ;) (after login) -------------------> [mainBlock] | (generates) +-- main-site --+ | | |<--------+ | hello user | +---------------+ | (next request) | | (uses) +---------> [block foo] ---------->[mainBlock] | (generates) +-- main-site --+ | | |<--------+ | hello user | | | | block foo- | | content | +---------------+ What is missing, of course, is how spring comes into play by providing a well contracted service-layer. Hopefully my thoughts are not just for blowing the mailing-list. I am looking forward to feedback, and please, I am cocoon-newbie so don't hit me that hard if i missed some points or you think 'what FUD this dude is telling'. Meanwhile I own some more documentation but I am still not able to get the transfere from sample- to real-world. This - to be fair - could not just be a result of distributed/incomplete documentation but also from myself! I also know that cocoons community has a lot of work with current RC. To twitch a little bit at least: building such ab big beast in spare time is of course not aimed to get used only by the people who build it. No, this is done for users, so please feed them! Greetings Patrick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
