cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <g...@tuffmail.com>
Subject Re: Help with Cocoon and Spring
Date Sat, 08 Mar 2008 18:37:20 GMT
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.

> As far as I can see, there should be some kind of
> 'rootBlock', where I put basic site-rendering.

It shouldn't be root and shouldn't be called root. I mean, you should almost always not have
any
root block, each block should process browser's request directly. For site rendering I would
suggest
"shared" block because other block will use it's basic rendering capabilities in order to
generate
full response with block's specific content.

> Directory structure would look like this:
> 
> ./myProject
> 	|-- (maybe) loginBlock
> 	|-- rootBlock
> 	|-- block 1
> 	|-- block 2
> 	|-- ...
> 	|-- block N
> 
> So maybe after users have logged in via some login-form (wich I would make as
> seperate block as well), they will be routed to my rootBlock. The specific
> sitemap for that block would contain pipelines to render the main-site.

Main site and shared rendering capabilities should be separated.

> After users decision for using a specific app-part in some of the other blocks (by
> clicking some link) the sitemap of that block would be engaged to render
> specific response-content. The trick should be, that this specific block is
> able to use the already defined pipelines from my rootBlock, rendering the
> main-site first. 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.

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

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.

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

-- 
Grzegorz Kossakowski

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


Mime
View raw message