cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Wagner" <dwag...@sa.kevric.com>
Subject RE: Cocoon2 Design WAS: [cocoon 2] removing bottenecks
Date Thu, 25 May 2000 18:17:52 GMT
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Hmmm, I'm not sure you understood what we mean with "logic".
> For "logic"
> I mean all the programming effort that is required, for example, to
> connect to a database, get data out and format it to XML.
>
Yep.  I did misunderstand.  I read the book chapter referenced on your
home page, did some thinking, and drew some diagrams.  I think my
confusion is clearing.

> But this happens only at server side dynamic generation, if
> you focus on
> static content, you are right, there is no logic to be separated.
>
> > So I cut my system design to just two layers: content and style.
>
> You can do this _only_ when no dynamic generation takes place.
>
Ah, but I consider dynamically generated content as part of the
content layer, encoded in the RDF as is any another resource.  The
programming needed extracts the current value of the resource and
presents it as any other resource request would.  How this happens,
whether we call it a dynamic database request or a static page request
is irrelevant.  Let me try an example using a prototype XML.  Note I
have used a custom java protocol call, and an XPath/XPointer extension
function for illustration.  Also note this example is incomplete (it
does not specify which alternate would be linked (as say an IMG
element) and which would be included as markup); as this relies on
XInclude [http://www.w3.org/TR/xinclude].
...
<resource id="moonphaserightnowpic">
 <alternate xlink:show="embed" dc:format="image/svg"
  xlink:href="../images/moon.svg"/>
 <alternate xlink:show="embed" dc:format="image/gif"
  xlink:href="http://tycho.usno.navy.mil/cgi-bin/phase.gif"/>
 <alternate xlink:show="embed" dc:format="text/html"
  xlink:href="moonphase.html#xpointer(
  id(concat('phase',string(today() mod 123456))) )"/>
 <alternate xlink:show="embed" dc:format="text/plain"
  xlink:href="java:moon.phase.description(today())"/>
 </resource>
...
>
> Yes, the sitemap is the RDF equivalent and cocoon is the engine that
> "merges" this information to provide resources.
>
> Anyway, I'm sorry, but I cannot understand _where_ your views would
be
> different from ours.
>
> I probably missed one of your points and I apologize in advance for
> that.
>
My apologies; this is all new stuff, and .  I have read through your
web site and its references but I am certain I do not grok it fully.
Is this basically how Cocoon works?

[def]Request :: The content desired formatted to the desired style.

- The request selects a producer.
- The producer selects the content specified by the request and makes
a working copy.
- The reactor processes a working copy of the content until it no
longer contains processing instructions.
- The formatter turns the working copy of the content into the
response appropriate to the request.
- The response goes back to the requestor.

Request -> Producer -> Processors -> Formatter -> Response
              ^
              |
Content Sources

Now contrast it to this processing model.

- The style requested selects all the content supported by the style
requested from all available content.  This set of resources is the
context.  (It is also the entire site as it would be delivered in the
requested style.)

- The specific content requested is selected from and transformed
within its context into the style requested.  Context resources needed
are transformed as well, while context not needed is suppressed.  Note
'dynamic' content is generated when the resource containing it is
requested for transformation or delivery, just as a 'static' file is
retrieved when requested for transformation or delivery.

Request + Content Sources + Style Definitions + XSLT -> Processor ->
Response

This can all be done with a single XSLT in one operation, though it
would be a good idea to do it stepwise instead to allow caching of
contexts and the use of only needed XSLT templates for the source
resources of the context and the requested style.

I don't think these systems are all that different, though the chapter
in the book referenced on your web site pointed out how easy it could
be for a Java programmer to go through a heck of a lot of coding just
to pull out and format the title of a chapter to include its
position() and today(), something XSLT (with extension functions or
access to a java:...today() resource) is far more suited to do.  I am
just looking to find a way to minimize the tedious work and maximize
the creative, while leaving perfectly good wheels unreinvented.  I
think this is also one of the goals of Cocoon.

-David

P.S.  All content is dynamic, isn't it?  'Static' files may change
less frequently than records in a database or your clock timer, but
all are subject to change, so why treat them differently?


Mime
View raw message