cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon2 Design WAS: [cocoon 2] removing bottenecks
Date Fri, 26 May 2000 00:18:29 GMT
David Wagner wrote:
> 
> > 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.  

Ok, I understand.

> 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.  

Well, it's irrelevant to you that never wrote web-applications :)
Anyway, I understand your point.

> 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>

This is another way of expressing a sitemap, right into the document,
unfortunately, this requires client side operation, it has nothing to do
with server side: what does it mean to "embed" a Gif image into a
document on the server side? write the <img src=""> tag? include the
binary as CDATA?

> >
> > 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.

this is correct.
 
> 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, 

well, I'm not so sure you fully understand the paradigm shift between
server side and client side.... If we had a perfectly capable XML
browser with all xml, xslt, xslt-extentions, xlink, RDF, SVG and XSL:FO
in place, there will be very little need for Cocoon or anything like
that.

The problem is we _don't_ have these clients and we must _fake_ them
using server side operation. Unfortunately, things work kind of
different when distributed in client/server enviornment.

> 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.

This is highly subjective and clearly dependent on your programming
background and mindset. Anyway, XSP and XSLT-extentions are completely
equivalent in functionality, this has already been analyzed, but they
represent orthogonal views of the same world.

> 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.

Totally. But, sorry, I still don't understand where is the design flaw
you underlined in your first email.
 
> -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?

You are right, I misused terms here.

I generally call "static files" all those files that are written and
maintained by humans, and cannot be possibly automated by programming
logic, in none of their parts.

The true distintion is "automated/not-automated" content and is totally
orthogonal from the frequency of update. in fact there are automated
documents that change once a week and non-automated documents that
change once a day.

Slashdot front page is automated, even if composed by non-automated
fragments. This allows the whole site to work without publishers, only
editors.

So, logic is _not_ required if you have non-automated documents to show
since they don't need any machine processing since they don't contain
any logic.

The old way to distriminate was to distriminate between URIs that were
"function of enviornment state" that those who were not, but this is not
a clear distintion anyway.

But not all content is dynamic, in my automated sense. A book or poetry,
for example, are non-automated by definition. Also vector art... even if
passed thru a SVG -> JPG converter.

Anyway, the line is very thin, I agree.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message