cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Variations on a theme by Cocoon
Date Wed, 16 Feb 2000 14:17:54 GMT
Pierpaolo Fumagalli wrote:
> 
> Niclas Hedhman wrote:
> >
> > > I match xsp/*.html, I associate the source sources/xsp/*.xsp. I parse
> > > the source, apply the xsp-java.xsl filter, and serialize it with JavaC
> > > (wich will create a nifty .class file).
> > > The class file becomes my producer, wich spits out XML, to whom I apply
> > > the stylesheet and (AGAIN) serialize as HTML...
> >
> > In a way I like it, but with a second thought...
> >
> > Is this not the same as;
> > xml = processXML( processXML( "whatever.xml" ) );
> > ??
> >
> > What I mean, nesting of independent requests.
> > Would that then means is that the execution of compiled stuff calls an URI to
> > obtain what to execute, and that URI is just another resource, which,
> > technically, can be nested to any level.
> >
> > Wouldn't that reduce the complexity by a magnitude?
> >
> > <process uri="xsp/*.html" source="src/xsp/*.xsp">
> >   <generator class="org.apache.cocoon.xsp.Executor" />
> >   <filter name="xslt">
> >     <parameter name="stylesheet" value="doc-html.xsl"/>
> >   </filter>
> >   <serializer name="html"/>
> > </process>
> >
> > <process uri="src/xsp/*.xsp">
> >   <generator class="org.apache.cocoon.xsp.Compiler" />
> >     <filter name="xslt">
> >       <parameter name="stylesheet" value="xsp-java.xsl"/>
> >     </filter>
> >     <serializer name="javac"/>
> >   </generator>
> > </sitemap>
> 
> What is the Compiler generator??? The generator is something that
> translates (stream?+request+response)->XML.
> 
> stream? means something that is read from a stream or nothing.
> 
> > Again, not 100% clear at the moment how things are chained together in
> > XSP (I really need to take a closer look), making the above incorrect.
> >
> > BUT, I think you get the idea.
> 
> However you make XSP, or JSP or however you create your producers from
> XML, splitting the two things into two different chains at the same
> level, will not allow you to perform link rewriting, since there is no
> information on how the source URI space in the target uri space...
> 
> Your example cannot work, as it is described, because, since the source
> and the target URI spaces are decoupled, you cannot access to the
> generated class. I'd rewrite it this way:
> 
> <process uri="xsp/*.html" source="cocoon:src/xsp/*.class">
> ...
> </process>
> 
> <process uri="src/xsp/*.class" source="src/xsp/*.xsp">
> ...
> </process>
> 
> Basically, when I get a request for "xsp/index.html" the Cocoon engine
> sees that it needs to get the source in the target cocoon uri space, in
> src/xsp/index.class, then it needs to post a subrequest to himself, for
> "src/xsp/index.class", this get translated to src/xsp/index.xsp,
> filtered and serialized (compiled), then executed, the second output,
> again filtered and serialized...
> So, this doesn't change what cocoon needs to do.
> BUT, if in the source page I have a link to "news.xsp", for example, and
> I need to translate it to "news.html", I have to:
> - see the source "src/xsp/index.xsp"
> - retrieve the target of the link "src/xsp/news.xsp"
> - find what <process> matches "/src/xsp/index.xsp"
> - translate it into its target space "src/xsp/news.class"
> - see if the where the original request came from (was it
>   "src/xsp/index.class" or "index.html"????
> - see if "src/xsp/news.class" is matched by its rule
>   "cocoon:src/xsp/*.class"
> - we're lucky, it matches (if not we're in deep trouble),
>   so translate it into the target "news.html"...
> 
> Quite complicated... And if we build a bigger sitemap (with more than 1
> entry that produces generators), the process will become not impossible,
> but highly complicate...
> 
> See the point????????

yes, and this is exactly what I mean by flexibility syndrome.

What Niclas saw was recursion... and man, this pattern will curse us for
life... anyway, this would be sane if the two things were _totally_
incorrelated and if more than one recursion was required.

But this is _not_ the case: I don't see something like this happening

 <process uri="*" source="*">
   <generator class="xmlcompiler"/>
     <generator class="sqlcompiler"/>
      <filter name="sql">
        <parameter name="database" value="host"/>
      </filter>
      <serializer name="javac"/>
     </generator>
     <filter name="xslt">
       <parameter name="stylesheet" value="whatever1.xsl"/>
     </filter>
     <serializer name="javac"/>
   </generator>
   <filter name="xslt">
     <parameter name="stylesheet" value="doc-html.xsl"/>
   </filter>
   <serializer name="html"/>
 </process>

it simply doesn't make sense! There is _NO_ need of going deeper in the
nesting. I'm already worried by the complexity added by this nested pipe
for generators... but I like it's power so much that I can't really see
alternatives that simply the sitemap.

Well, consider that we are talking about "pure" XML. If we come up with
something like XML-inheritance or self-referencing... then the sitemap's
verbosity gets reduced extremely, but this is totally orthogonal.

> > What would then only be required is that the Executor calls Cocoon to retrieve
> > the executable with a recursive call.
> > Seems to me to be a lot easier to explain, and understand what will actually
> > happen. No??
> 
> You're not considering link translation and the fact that the source uri
> space and the target uri space do not coexist... they're not the same...
> 
> > That means that XSP is 2, perhaps 3, independant components which interacts
> > over the URI namespace. I think it will also ease the caching considerations
> > for XSP and similar technologies.
> 
> I don't think that it'll ease the cache implementation...

No, I don't either... expecially because the sitemap interpreter and
engine will be much more specialized.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message