cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Heiden" <patrickhei...@gmx.de>
Subject Re: Help with Cocoon and Spring
Date Sat, 08 Mar 2008 20:36:55 GMT

-------- Original-Nachricht --------
> Datum: Sat, 08 Mar 2008 19:37:20 +0100
> Von: Grzegorz Kossakowski <grek@tuffmail.com>
> An: users@cocoon.apache.org
> Betreff: Re: Help with Cocoon and Spring

> Patrick Heiden pisze:
> > Hello again!
> > First of all: Big compliment for such an active users-list!
> 
> Thanks! :)
> 
> > [...]
> > To get a bit more specific I am trying to explain what my architecture
> > would/should look like at this state of my cocoon-knowledge. I assume,
> that basic idea
> > behind cocoon-blocks is about to create different parts of an
> application and
> > connect those parts for interoperability. So as you suggested to first
> > establish basic routings, my way would exactly be to split (separable)
> functionality
> > through different blocks.
> 
> Right.
>
[...] 
> > Following little illustration should make clear what I
> want
> > to achieve:
> > 
> > (after login)
> > -------------------> [rootBlock]
> > 			  | (generates)
> > +-- main-site --+	  |
> > |		|<--------+
> > | hello user    |
> > +---------------+
> > 	| (next request)
> > 	|
> > 	|			    (uses)
> > 	+---------> [block foo] ---------->[rootBlock] 
> > 			  | (generates)
> > +-- main-site --+	  |
> > |		|<--------+
> > | hello user    |
> > |		|
> > | block foo-	|
> > | content	|
> > +---------------+
> > 
> > and so on. 
> 
> Oh, your picture is much better. It clearly suggests that the it's
> specific block that generates its
> response to browser and only uses some shared functionality from
> rootBlock. That is kind of design I
> firmly advise.
> 
THANKS !! [1]

> > Therby each block would define its own flow-scripts to reach some
> > part of the domainmodel or global services.
> > Is this way advisable, or are there even simpler ways within cocoons
> > block-context? Asuming, that all blocks are ready to use, there has to
> be a
> > main webApplicationContext (e.g. within rootBlock?), where I put all
> beans for
> > global usage (db-pooling, userManager and the like). 
> 
> You should put such stuff to shared block and make other blocks depend on
> it. Actually, current
> implementation is little bit simplistic in this area because there is only
> one Spring's application
> context (bean container) so even if you don't declare dependencies (in
> Maven's POM file) correctly
> you will be able to use beans from other blocks. However, it's certainly a
> bad practice, because
> Cocoon could eventually implement real block isolation in the near future.
> 

I would say, that I had the same idea about 'sharedBlock', but my naming (rootBlock) sugests
wrong usage-scenario!

> If you are wonder who is setting up this global application context: it's
> job of webapp module
> (generate from archetype) which is used for packaging Cocoon blocks in a
> one Webappliction ready to
> be used in servlet container like Tomcat or Jetty. Anyway, you shouldn't
> bother about such details
> too much. Your job, as Cocoon user, is to create blocks, declare
> dependencies between them and
> develop all the functionality in blocks.
> 


To get this clear: Step 1 to N is creating Blocks 1 to N (some of them are shared). Then I
just create 'my-webapp' with maven archetype. Block-wiring is done through servlet-service-configuration-files
(pom.xml, servlet-service.xml). Usage of the wired blocks is defined through sitemaps and
I am able to define global beans within webApplicationContext.xml and 'block'-specific (local)
beans within META-INF/cocoon/spring/*-context.xml.
And thats it?
Wow!

> > So how should
> > configuration look like to get all blocks interoperate the above way?
> You may
> > think - and it would be right - that I am still a bit confused on how to
> put
> > blocks inside the game. But maybe after all that explanation you are in
> better
> > position to guide me towards better usage of cocoon.
> 
> As I said, you don't need to configure too much. Just declare dependencies
> between blocks in Maven's
> POM file and you are done. If you want to use pipelines from other blocks,
> you will need to connect
> to other blocks' servlets but you already know how to do this.
> 
> I would like to suggest you two nice readings which could probably help
> you understand better
> Cocoon's architecture and avoid common pitfalls:
> http://article.gmane.org/gmane.text.xml.cocoon.devel/74571
> http://thread.gmane.org/gmane.text.xml.cocoon.user/63219 (excellent
> discussion with Rainer Pruy)
> 
> Oh, and in your spare time you could probably take a look at this
> screencast:
> http://people.apache.org/~gkossakowski/cocoon-tutorial-rcl-2.html (I plan
> to move it to our main
> site as soon as I have some free time)

I will check all of your references and reply as far as I am ready with this! Hopefully those
links will wipe out my thoughts about what's definitely beeing packed inside a final an deployable
war. At this point this is something I am not clear with, because every block has it's own
dependencies shiped as complere block-foo.jar. So there maybe some overlapping, e.g. block
foo and block bar could have equal dependencies during usage of the cocoon-forms block and
some block-specific one, such as what-ever-i-need-to-do-my-block-job.jar.
I think that this point will become clear next hours/days.

I could not thank you enough for supporting my first steps with cocoon-2.2, you've really
flattened my learning curve!

Greetings
Patrick

[1]http://en.wikipedia.org/wiki/A_picture_is_worth_a_thousand_words
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/?mc=sv_ext_mf@gmx

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message