cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [C2]Access control using sitemap
Date Sat, 09 Sep 2000 15:55:37 GMT
On Sat, 9 Sep 2000, Stefano Mazzocchi wrote:
> I disagree.


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

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

> > So what I see cocoons main strength is building the pipeline and "running" it.
> I agree here, but I do NOT see why this matches with "publishing" only.

it doesn't. It is perfectly capable of building complex
aggregating web-applications - but it aint easy to do it in
it - thats what I am getting at. 

> > There are other requirements for a complete web-development system, two of
> > which are aggregation and application logic.
> Correct. I agree with this separation but unlike you, I see cocoon below
> both, not at the same level. Aggregation is a special way of generating
> content, while application logic is a complex yet specific way of
> building sitemaps and the logic that glues different resources together
> depending on user actions or enviornment parameters.

I see cocoon below aggregation but at same level as
application logic. Both IMHO should be side by side but each
to their own :P

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

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

> > 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.
> Agreed. The goal is: Cocoon2 provides internal aggregation capabilities,
> Jetspeed drives the process.... it's more or less a Cocoon Web
> Application that uses its capabilities for a more specific purpose
> (which is creating portals and bring different informative source to the
> same site).
> I picture Jetspeed2 as a number of additional Cocoon sitemap components
> and some sitemaps prebuilt do mix them together. Everything down below
> is done by Cocoon, so you either can use Jetspeed or rewrite your own
> with Cocoon functionality.

yep agreed.

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

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


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

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.

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.

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? :)


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)

> 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 ?
* will sitemap be able to represent other aspects of system
(like I mentioned a while back on Avalon list ?)

View raw message