cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Heiden" <patrickhei...@gmx.de>
Subject designing with 22-blocks
Date Mon, 10 Mar 2008 13:48:16 GMT
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message