cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [C2]Access control using sitemap
Date Sat, 09 Sep 2000 11:55:44 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.
> 
> 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.

I disagree.

The sitemap maps "resources" to "instructions to produce them".

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's like saying that since Java strenght is building a program (compile
it) and run it (executing it), it cannot do 3D games.

C1 is totally focused on publishing and I grant you that, but C2
introduced the pipeline to be able to do "everything" (see below)
 
> 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.
 
> 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?
 
> Aggregation will be served by Jetspeed (an apache project that is currently
> at java.apache.org but will soon be at xml.apache.org). 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.
 
> 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 
2) create a "web application language" that defines the logic of the web
application. This is then "compiled" into sitemap and XSP skeletons.
 
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...
 
> 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? :)

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

yes, but it will take time.
 
> 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.

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.

Just like taglibs require XSP down below, but it's a pain to use XSP
with logic built in.

Sitemaps will be the same: you can write your own sitemap if it's easy,
or use tools to "autogenerate" your sitemap from some more specific
schema that defines what to do with your application and where to fit
actions/screens and all that.
 
> >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.
 
> 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 :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message