cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: [C2]Access control using sitemap
Date Sat, 09 Sep 2000 14:15:01 GMT
Hi all

this is a interesting thread and I like to join in.

Actually I'm thinking of and developing a sitemap administration app
based on C2.

My first step was to develop a stylesheet to render the sitemap.xmap
file to a html document. You'll find it under
webapps/stylesheets/simple-sitemap2html.xsl (commited today). Use the
following command to render the initial html page for that admin app:

  java org.apache.xalan.xslt.Process \
    -IN webapp/sitemap.xmap \
    -XSL webapp/stylesheets/simple-sitemap2html.xsl \
    -OUT a.html \

and look at the generated a.html file with your preferred browser (it
doesn't work under C2 today and I don't know yet why).

I think the C2 sitemap component might be able to give you all you need
to write web apps. Let's have a look at it:

All sitemap component (except Serializers) have access to the so called
objectModel which is a Map containing objects like HttpServletRequest,
HttpServletResponse and ServletContext. The CocoonServlet, as calling
environment of Cocoon, is responsible to provide this objectModel and
its content to the C2 engine. The objectModels lifecycle is the time to
process one response. Objects that have a longer lifecycle can be put
into the Session object as usual. The objectModel can be used to pass
information along all sitemap component participating in the pipeline
selection and resource production process.

Lets have a example how I see a possible sitemap pipeline snipped to
achieve this (I'll abbreviate the elelments :)

  <match type="uri" pattern="myapp/**">
    <!-- the following Matcher make the overall request
         analysis and makes important information available
         to subsequent components through the objectModel and
         a Map for substitution in src= attributes.
         Maybe a Controller sitemap component would be more 
    <match type="myapp-controller" pattern="not really used">
      <select type="myapp-action-selector">
        <when test="add">
          <!-- here the {1} is delivered by the matcher
          <generate src="myapp/{1}/add.xsp"/>
        <when test="remove">
          <generate src="myapp/{1}/remove.xsp"/>
          <generate src="myapp/{1}/index.xml"/>
      <select type="browser">
        <when test="netscape">
          <transform src="myapp/{1}/style-ns.xsl"/>
          <serialize type="html"/>
        <when test="wap">
          <transform src="myapp/{1}/style-wap.xsl"/>
          <serialize type="wap"/>
          <transform src="myapp/{1}/style-ie.xsl"/>
          <serialize type="html"/>
  <-- here we catch all requests not handled by the match above
      and redirect them to the login screen or an error page
  <match pattern="myapp/**">
    <redirect-to uri="myapp/login"/>

Well, this example might not be the best one but I think its
good enough to start a discussion about it. What do you think?

Peter Donald wrote:
> At 11:47  8/9/00 -0400, you wrote:
> >I actually was interested in Cocoon because I thought it could merge
> >multiple pipes into one output. I was in fact using XInclude to include XML
> >fragments (like user info, skins, globals) and XSL to shape (filter) the
> >results into a another XML hierarchy which would then be styled. E.g. a two
> >stage XSLT pipeline. I think this is very powerful.
> yep - but not so easy - especially when you cyndicate content from multiple
> different sources or when the aggregation mapping needs to be dynamic etc.
> >> Aggregation will be served by Jetspeed (an apache project that is
> >> currently
> >> at but will soon be at Jetspeed
> >> does a lot
> >> more than aggregate - it mixes in lots of other options.
> >
> >True. However, as you mention later, it also seems difficult to learn.
> :< yup

I know people doing kinda portals stuff using C2 (but unfortunately they
are still not allowed to give those components back into the open source
community). And personally I think Jetspeed may be used as a sitemap
component doing aggregation mapping in the (near) future.

> >Fair enough. Two comments. First, I thought I read on this list that Turbine
> >was going to be used by C2 at some point. I was hoping that it's
> >functionality would thereby become available to me.
> possibly - in the future. C2 already uses some components (database
> pooling) from turbine) but it conceptually a different beast. Currently
> Cocoon handles dispatching

I have to correct this here. C1 has the database pooling component from
Turbine integrated but not C2 yet. I'll try to port Donalds esql
logicsheet to C2 sometimes (my time is limited as well, but maybe we'll
find some volunteers :) That logicsheet is prepared to use the pooling

> >Second, I've begun to look at Cocoon as a two way pipeline and fooling
> >around to see if I can make it work (please tell me if it's been done
> >already!). That is, each input to the system (e.g. POST) can have multiple
> >outputs (e.g. to calling client and backend system), enumerated in the
> >sitemap as transformations themselves.
> quite possible - thou I would hesitate to say not anywhere as easy as it
> should be.
> >I think it would be interesting, and the proper separation of responsibility
> >in the opposite direction from Cocoon's original design, for the input
> >request to generate multiple outbound 'messages' for other systems. Those
> >messages should of course simply be XML snippets, which can of course be
> >created by XSP and XSL transforms.
> it is an interesting approach - make sure you post to the list if you get
> it up and running :P
> >Am I making any sense? Basically, I could see Cocoon becoming a great way to
> >write middleware, not just a publishing system. The benefit of a system like
> >C2 where you can insert new elements in the pipeline is that you can let
> >Cocoon extend as far in either direction from its center as you want, just
> >add or subtract transforms.

C2 was designed to run in many environments. For now they are Web
(called from a servlet) and command line. I think you can use C2 in any
environment which has a request/response pattern.


PWR GmbH, Organisation & Entwicklung      Tel:   +41 (0)1  856 2202
Giacomo Pati, CTO/CEO                     Fax:   +41 (0)1  856 2201
Hintereichenstrasse 7                     Mobil: +41 (0)78 759 7703 
CH-8166 Niederweningen           

View raw message