Hello again!
First of all: Big compliment for such an active users-list!

[...]
> I could not exactly imagine what configuration nedds to be put in certain
> place.
> > More details:
> > - imagine an application that consists of several pet-store-like facades
> > - each facade is responsible for processing several well defined
> requests (the data within them)
> 
> It maps to several separate blocks each containing SitemapServlet mounted
> at certain path. Each
> block can be created using archetype and you will already find default
> configuration of SitemapServlet.
> 
> > - to hook up this with SpringMVC I just define a DispatcherServlet and
> route through different views
> 
> We have DispatcherServlet too but you don't need to bother about it, just
> create servlet beans
> declarations in a file placed at /META-INF/cocoon/spring/*.xml of your
> block, see[1]. Routing to
> servlet beans is done basing on mount-path attribute.
> 
> > - HOW should I port this to cocoon-context to use
> FlowControl/continuations as my controller?
> 
> Once you define high-level routings to your separate SitemapServlet you
> just need to create matchers
> in your sitemap file tied to concrete SitemapServlet and call FlowControl
> functions.
> 
> > - do I 'have to' use several blocks for my application? What I mean here
> is: a persistence-block, view-rendering-block, etc.. how does an elegant
> block-usage look like?
> 
> It's advised to have several blocks if your application can be split into
> separate structure units.
> 
> > - how should the integration of hibernate should look like to enable the
> pooled connections to be used within flows (found hints for
> OpenSessionInView filters)
> 
> It's more question for Spring usage than Cocoon usage. You need to check
> documentation of Spring to
> see how to configure connection pooling.
[...]
> I hope I'll be able to help you more once you came with more concrete
> problems. Feel free to ask
> more questions.
[...]
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. As far as I can see, there should be some kind of
'rootBlock', where I put basic site-rendering.

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.

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

Regards
Patrick

-- 
Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! 
http://games.entertainment.gmx.net/de/entertainment/games/free

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to