cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: [C2] User Authentication
Date Mon, 16 Jul 2001 18:04:11 GMT
At 3:32 PM +0200 16/7/01, Ulrich Mayring wrote:
>Berin Loritsch wrote:
>>
>> For now, I use an Action.  In the future, I want to migrate to formalizing
>> Stefano's FlowMap approach.  It is the process of modeling application flow
>> in XML.  The FlowMap will take care of matching actions and form pages, etc.
>> It will also make sure that when a resource must be authenticated and
>>authorized,
>> you will be redirected to the login form.
>>
>> It is a great idea whose time has come.  The problem is finding the time
>> to implement it.....

I _so_ want to use flowmaps !

>Yeah, this is consistent with Cocoon2's approach to put distinct
>functionality into distinct places using distinct techniques. My idea of
>SoC is a bit different perhaps, but perhaps not so different after all,
>we'll see how it plays out in the long run. For me there are three
>Concerns, which should be seperated in an SoC model:
>
>a) content
>b) logic
>c) output (includes display, but there is more to output than that)
>d) workflow (meaning program flow)
>
>In Cocoon1 we have it like this:
>
>a) Content - in XML files
>b) Logic - in XSP taglibs (forget about processors, they are not very
>useful anymore)

We all tend to mix content and logic here, even if the logic merely comes
for the ride, as logicsheet implemented logic.

So what I am saying is IMHO output starts at the producer/generator stage,
not the transformer stage below.

>c) Output - in XSL files
>d) workflow - defined by XSP taglibs and used in XML files
>
>This model has two weaknesses: first, XSL files cannot really output
>things, that are too different from XML, say PDF or a Word document.

It might not be obvious how to output non-xml, but it is certainly
possible, I have XSLTs that output QuickTime TextTracks .....

>Second, the workflow is spread over a lot of XML files and not centrally
>defined somewhere. Now let's look at Cocoon2:
>
>a) Content - in XML files
>b) Logic - in Actions and XSP taglibs and the Sitemap and ... (did I
>forget something?)
>c) Output - in Formatters and Serializers (is that correct?)
>d) Workflow - in the Sitemap and in Actions, in the future in a Flowmap
>
>So there is an improvement in c) but b) was IMHO easier to use and
>maintain in Cocoon1. As far as d) is concerned, a Flowmap would be an
>improvement over Cocoon1, even though I don't think it is the optimal
>solution due to it being a proprietary concept like the Sitemap.

I feel the benefit that Cocoon 2 brings, is to allow you to break down your
functionality into smaller more reusable parts than is generally achieved
using Cocoon 1.

regards Jeremy
-- 
   ___________________________________________________________________

   Jeremy Quinn                                           Karma Divers
                                                       webSpace Design
                                            HyperMedia Research Centre

   <mailto:sharkbait@mac.com>     		 <http://www.media.demon.co.uk>
    <phone:+44.[0].20.7737.6831>        <pager:jermq@sms.genie.co.uk>

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail: <cocoon-users-help@xml.apache.org>


Mime
View raw message