cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Heiden" <patrickhei...@gmx.de>
Subject Re: SSF
Date Thu, 27 Mar 2008 18:05:29 GMT
Hi you both!

> Vadim Gritsenko pisze:
> > On Mar 27, 2008, at 12:55 PM, Grzegorz Kossakowski wrote:
> >> Vadim Gritsenko pisze:
> >>> On Mar 27, 2008, at 10:36 AM, Patrick Heiden wrote:
> >>>> What should one do, if he/she wants to let all requests get routed 
> >>>> through a mainController block first and therefor disabling direct 
> >>>> calls to connected blocks (registered at some mount-path)?
> >>> Sounds like you want to 'mount' a block from mainController's 
> >>> sitemap. :) Grzegorz, do you remember if this was ever implemented? :)
> >>
> >> No, it wasn't and it's not likely it will ever get. ;)
> > 
> > Pity! :) What about forwarding? Does it work? :)
> > 
> >   <map:redirect-to uri="servlet:childBlock:/some/path"/>
> > 
> 
> Won't work either, see: https://issues.apache.org/jira/browse/COCOON-1964
> 
> The good news are that it probably wouldn't be blocked if someone has an
> itch to implement this 
> feature. :-)
> 
> Once again: why do you need such design? Hiding all blocks/servlets apart
> from one is probably a 
> /bad/ idea because it's a DispatcherServlet that is meant to be main,
> basic controller.

Well maybe I get something wrong with block-semantics. I'll try to explain. I thought it would
be a good idea to have a mainController wich is responsible for main routings and authentication.
So users actually logged in can get access to hosted blocks services (checked before any routing
gets through, thats why I called for cocoon-auth details ;)).

Imagine several domainModules wich are connected to blocks - each block responsible for handling
requests of special module. So far there is nothing special about it, reflecting adviced block-design.
Again there would be other blocks, responsible for layout or user-navigation rendering. But
what (and this is the main point) if user calls some block (e.g. rendering block as standalone,
wich should be avoided) in isolation? There would be no security-check and no usage of mainControllers
aggregate, composing final views out of hosted blocks.

Inside mainControllers sitemap I use the conventional pipeline with id="service" to do high-level
routings like:

<map:pipeline id="service">
   <map:match pattern="callSomeServiceBlock/*.do">
              <map:generate 
                   src="servlet:whereEverServiceIs:/{1}.do" 
                   type="file"/>
              <map:serialize type="xml"/>
   </map:match>

   <map:match pattern="callSomeOtherServiceBlock/*.do">
              <map:generate 
                   src="servlet:whereEverOtherIs:/{1}.do" 
                   type="file"/>
              <map:serialize type="xml"/>
   </map:match>
</map:pipeline>

So the *.do's would be processed in serviceBlocks-sitemaps (I would do the same for continuations
as well). I could use some aggregates to build final views:

<map:pipeline id="serviceRouter">
   <map:match pattern="callSome/**.do">
      <map:aggregate element="final">
         <map:part src="part_one.xml"/>
         <map:part src="part_two.xml"/>
         <map:part src="cocoon:/callSomeServiceBlock/{1}.do"/>
      </map:aggregate>

      <SOME TRANSFORMATIONS HERE/>

      <map:serialize type="html"/>
   </map:match>

<!-- more matchers here -->

</map:pipeline>

I hope this makes clear what I want to achieve. My problem is authentication of that as a
whole to avoid the auth-dependence inside every block. With above I could also use a '**'
pattern to redirect to login or something like you-are-not-logged-in... But still there would
be the problem, that one could call mounted blocks direct, bypassing my serviceRouter.
> 
> Do I overlook something obvious?

I wouldn't guess! Hopefully I am the one making things unnecessary  overcomplex ;) - due to
the fact that I have no other auth-source then the block-samples.

Looking forward for comments,
best regards,
Patrick
> 
> -- 
> Grzegorz Kossakowski

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