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:21:48 GMT
At 9:52 AM -0400 16/7/01, Berin Loritsch wrote:
>Ulrich Mayring wrote:
>>
>> Berin Loritsch wrote:
>> >

[snip]

>> 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.
>
>The way it will change (once FlowMap is introduced):
>
>Content - in XML/XSP files (XSP is used for complex content generation).
>Logic - in Actions.
>Output - XSLT/Serializers (Readers are for non-transformed content)
>Workflow - FlowMap (currently in Actions).

I am still struggling with where and how to implement 'ContentLogic'
something that has never fitted into the simple SoC model.

We have content that depends heavily on runtime parameters, often with
logic nesting 3 or 4 levels deep. This is webapp 'display' logic rather
than webapp 'funtionality' logic (which is in the Bean), whereby an
application needs to show you different strings depending on several
different parameters.

The content needs to be readily editable by content authors, so it needs to
be in XML files, so we end up developing a publishing DTD which
'surreptitiously' encodes the conditions under which the different bits of
content get output.

>This is not really a fundamental shift in the original concepts behind
>Cocoon 1.  XSP was really only intended to provide a way to create dynamic
>content.  It is the absence of any other mechanism in Cocoon 1 that forces
>you to violate the original intent of XSP.

Agreed.

This is why I would like to be able to compile Actions from XSP, because
there are already useful XSP languages that currently perform roles that
can now be separated into Actions and Generation.

It would mean we could continue to take advantage of the investment that
went into developing those TagLibs.

eg. esql, fp, crudlet, auth, soap etc. etc.

If I were to use esql for example, I would do updating of the db in an
XSPAction, and outputting from an XSPGenerator, and only have to use esql
for the whole lot, instead of going back to Java to write custom Actions
that I already have an XSP TagLib for.

[snip]

>On the developer's list, I have been proposing ways of limiting the sitemap's
>involvement in the overall method of creating your web resources.  The reason
>is that the Sitemap MERGES certain concerns that hinder each site developer's
>role from functioning the way it is envisioned.
>
>My proposals have been meet with mixed emotions.  Some of the developers like
>the better markup, and structure.  Some are of the oppinion that the sitemap
>is good enough.  A large part of it has to do with the overall complexity of
>the sites being produced.  Those who create complex sites tend to favor my
>approach, and those who create simple sites like the sitemap the way it is.
>That last statement is a broad generalization, and I have only had feedback
>from a few folks.

Being someone who is trying to learn the SiteMap ML at the moment your
proposal looked refreshingly simple.


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