cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <Giacomo.P...@pwr.ch>
Subject Re: [C2]Access control using sitemap
Date Sat, 09 Sep 2000 17:00:19 GMT
donaldp@mad.scientist.com wrote:
> 
> On Sat, 9 Sep 2000, Stefano Mazzocchi wrote:
> > I disagree.
> 
> :P
> 
> > The sitemap maps "resources" to "instructions to produce them".
> 
> it has the potential to - but it doesn't now from what I can
> tell (thou I may be wrong).

Don't get this ???

> > The Cocoon Sitemap is a "module-oriented programming languages for web
> > sites".

I think so, too!

> > > Aggregation means the method through which multiple pipelines are merged to
> > > produce 1 oupput. Currently cocoon has support for 1 pipeline producing
> > > multiple outputs but no support for multiple pipelines producing one
> > > output. (thou you can do it with certain hacks and perhaps via XInclude -
> > > it is not easy).
> >
> > ???
> >
> > Do you seriously think that something like this
> >
> >  <page>
> >   <sitebar xinclude:href="/sitebar"/>
> >   <body>
> >    blah blah
> >   </body>
> >  </page>
> >
> > is too hard to use?
> 
> now make that include variable depending on what *mode* you
> are in. ie Admins have different sitebar, people outside
> company have different colors/skinning, and admins outside
> company have both applied. ALso make it variable content
> depending on time of day etc etc .

If you need logic to determine which sitebar to choose use an XSP page
instead of the above to create the xinclude.

> It is all possible - but it is just not easy.

<snip/>

> > > Web-application logic is something different again - it includes all the
> > > "doing" aspects of the system. So if your applications contacts a database
> > > and performs a whole heap of transactions, performs complex processing etc
> > > then this should be done in web-application level. Apache has a
> > > web-application framework (Turbine at java.apache.org) that includes a lot
> > > of this functionality (Identity management, authentication, authorisation,
> > > database pools, "actions" etc).
> >
> > Yes, we need to integrate Turbine functionality in C2 and I have a
> > couple of ideas on how to do this:
> >
> > 1) get turbine-like services from Avalon (db pool, identity manager,
> > etc...) as blocks
> 
> thats what I am aiming for :P
> 
> > 2) create a "web application language" that defines the logic of the web
> > application. This is then "compiled" into sitemap and XSP skeletons.
> 
> I always dislike this approach. I really don't like
> reinventing the wheel - even if it is a slightly better
> wheel. If I want to develope stuff for a large website with
> a lot of application logic I want to do it in straight java
> and not worry about anything else. If there was a way of
> scripting inputs to actions and templating outputs via some
> xsp sheet then brilliant - just don't make me use some ugly
> xml/java/scripting cross :P

That's what I've mentioned in a earlier mail by using matcher/selectors
(or maybe a new Controller component) as Controller to process the users
interaction in straight java and use selectors/matchers to assemble the
pipeline to build the "next screen".

> > Turbine is indeed cool, but it's programmer focused and our pyramid of
> > concerns doesn't fit to their model where the programmer is also the
> > site manager (which is never the case).
> 
> agreed.
> 
> > > So in effect when a request comes in it goes via a "sitemap" (not to be
> > > confused with C2s sitemap) that maps request to a web-application. The
> > > web-application does it's stuff and then chooses a C2 pipeline to output
> > > via. It then fills a "context" with relevent information (like result data)
> > > and executes the pipeline with relevent context. Aggregator sits on top of
> > > this.
> >
> > More or less, this is still unclear to me...
> 
> You seem to get everything except perhaps how contexts are
> filled with data from web-applications ?
> 
> Basically you put data in a context and this is used by
> various stages in pipeline.
> 
> For instance a request comes in and is mapped to a
> particular action. The action may do any number of things
> which result in it putting data in it's context. The
> context-data is then used at various stages in pipeline. For
> instance a username and address may be stored in the
> context-data. This is then pulled out at a generator or
> transformer stage. In many ways it is like "session" data
> per-request (yes that is a contradiction of terms :P).

This is what is called the objectModel in C2. A Map that the calling
Environment provides per request and all sitemap components have access
to and can pass data along the pipeline assembling/processing stage.

> It is especially useful in templating style web-applications
> and I suspect in C2 aswell.
> 
> Context-data can also contain special "escape" commands that
> tell the C2 engine to do other things.

Matchers and Selectors can evaluate the objectModel and instruct the C2
engine what components to choose to build the pipeline. This is already
realized.

> For instance the sitemap may pass incoming data down one
> action path - the path may result in one of 5 outwards bound
> publishing pipelines. The action can place magic-data
> in context to say which pipeline to choose etc.

Exactly! That is C2 behaviour. This is easily done. Write a Selector
that inspects the objectModel and choose the pipeline to build like that

  <select type="actions">
    <when test="add">
      <generate .../>
    </when>
    <when test="remove">
      <generate .../>
    </when>
    <otherwise>
      <generate .../>
    </otherwise>
  </select>

> Does that make any sense ? :P
> 
> > > None of these applications are yet easy to use with cocoon. I have been
> > > trying to get people to adopt diferent apache products for a while but so
> > > far I have only got them to se cocoon out of these three.
> >
> > I wonder why? :)
> 
> :P
> 
> well it is not what you think - I think cocoon is probably
> THE leading publishing framework - I am not even familiar
> with any comparable products - but the people I got to use
> it just love it because it is easy to use (at least compared
> to other OS frameworks) and lets them do what they want
> (basically publishing from a db)

This is true for C1 but C2 can do much more.

> > More or less, I agree. But I do not see why Cocoon2 can't fit all of
> > them in fuctionality. Don't get me wrong, it's indeed hard to write web
> > applications on C2 "today"... but the functionality you need it's
> > there.. we just have to "tune it" for web applications and create
> > helpers for you.
> 
> yep. It is possible - just not easy and I have not seen any
> discussion about action-orientated processing. I saw a while
> back that someone was discussing form validation but that is
> only a small part of picture.
> 
> > > >And, if Cocoon isn't a web-app framework,
> > > >are there any web-app frameworks it'll integrate with easily?
> > >
> > > Well currently Jetspeed does it and it wouldn't be hard to add it to
> > > turbine. The problem is that neither is yet easy to set up and they require
> > > a lot of knowledge. Personally I wouldn't recomend it atm but in the future
> > > that is the way to go.
> >
> > I don't think it's possible to integrate turbine and Cocoon. They are
> > too different. But Cocoon can clone Turbine functionality and provide
> > better separation of concerns.
> 
> actually I demo-ed cocoon pages in turbine a bit back to try
> and entice people to use turbine (they already used
> cocoon) but they disliked the difficulty of setting it
> up. It was also a major code-hack :(
> 
> > > If you have a product out in next few months just write xsp to do it for
> > > you - if your product timeline is longer (end of next year) then doing it
> > > the *right* way may be in order. I am trying at the moment to get some
> > > funding to setup an integrated solution and if so will start an OS frontend
> > > next march. Heres hoping :P
> >
> > Well, that will clearly fork this project then, since we'll be aiming at
> > the same target :)
> 
> hmm - Perhaps I should just wait and see :P
> 
> A few questions thou -
> 
> * in the future do you plan to be able to map incoming
> requests to event mosaics ?

can you explain that more in detail?

> * will sitemap be able to represent other aspects of system
> (like I mentioned a while back on Avalon list ?)

Oops, probably missed that one.

> From reading the code I was under the impression that is
> publishing orientated and from a few comments here I was
> under the same impression (which could quite possibly be
> completely wrong as I don't always pay attention :P)

I definitely beleave it can do more than only publishing.

Giacomo

-- 
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                    Mailto:Giacomo.Pati@pwr.ch 
                                          Web:   http://www.pwr.ch

Mime
View raw message