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:[EMAIL PROTECTED]> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]>
---------------------------------------------------------------------
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: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
