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.....
>
> 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)
> 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.
> 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.
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).
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.
Truth be told, if you don't need redirection, you can develop your XSP
pages like before. The addition of the FlowMap will handle the XML
modeling of your redirects and such.
Cocoon 2's Transformers and Serializers are a powerful concept that allow
you to take an XML input, and output any kind of stream. Cocoon 2 already
has the ability to take XSL:FO and generate PDF; and take SVG and generate
JPG and PNG images.
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.
I know code speaks louder than words, but I have very limited time...
S/MIME Cryptographic Signature
