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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
