cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <>
Subject RE: [C2]Access control using sitemap
Date Sat, 09 Sep 2000 03:47:02 GMT
> Peter Donald wrote:
> At 09:57  8/9/00 -0400, you wrote:
> >Peter,
> >
> >Could you expand a little on exactly what you thing the differences are
> >between a web-publishing framework and a web-application framework (incl.
> >what responsibilities each has)?
> well there is a few ways of looking at it really. The way I choose to look
> at it (which may differ from others :P) is as follows. Cocoon2 is
> primarily
> about passing fragments through a pipeline. By fragments I mean XML
> fragments. The pipeline starts at generators, then transformers and then
> serializers. Each of these are considered "stages" in the pipeline.

Ok, we're talking about C2 here and I agree with your view so far.

> The result of a particular stage is determined by
> 1> What type of stage it is ? (ie generator/transformer/serializer)
> 2> What is purpose of stage ? (ie xslt transformer stage
> transfroms via xsl)
> 3> Context in which pipeline is called (ie user session information, logic
> vairables, web-application parameters etc)
> Cocoon2 is great in that it gives great support to 1 and 2 and minimalist
> support to 3.
> So what I see cocoons main strength is building the pipeline and
> "running" it.
> There are other requirements for a complete web-development system, two of
> which are aggregation and application logic.
> 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).

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.

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

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

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.

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.

For example, I'm hoping to set something up that takes an POST and splits it
into two (or more) pipelines; one which returns a result back to the user,
and one (or more) which makes changes to the system. A simple version can
already be done: XSP page takes a form and executes some Java code to insert
records into the database using JDBC (or, better, the esql taglib).

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.

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.

Browser <- HTML <- XSLT <- XML <- XSP <- {JDBC | XInclude | Files | XML-RPC
| Other}

Browser -> HTTP -> XSL -> XML -> XSP -> {XML store | MSSQLXML | XQL DB |
XML-RPC | ...}

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

As mentioned above, while I use what you're describing right now, I'm hoping
to use only Cocoon in the future.

> 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. There
> are changes
> in place to make usage of these products easier (specifically
> turbine has a
> simple developers kit setup in progress) but that still leaves a
> lot of the
> Integration for you to do. Currently there is also a move to
> standadise the
> packaging of all apache products (I believe PMC is or will in future be
> discussing this possibility) which will help this progress.

Great! But, uh, who's PMC?

> SO in conclusiong, publishing is about managing and running pipelines,
> applications is about doing stuff and filling "context" data to pipeline
> start and aggregation is about binding multiple pipelines to one output.
> >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.


> 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

Sigh again, that's a long time. And good luck on your efforts!

Will let you know if I make any progress.


View raw message