cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject Re: [RFI] Garbage
Date Tue, 24 Jun 2003 22:58:20 GMT
Pier Fumagalli wrote:
> SetAttribute vs Well-formedness:
> --------------------------------
> Briefly, I wanted to check with you people if a functionality like the XSLT
> setattribute is required, or the non-well-formedness of Garbage is better
> (see previous messages on this thread)... Both approaces have advantages,
> but it's either an out-out choice: either we have non-well-formedness a-la
> #if {something}
>   <paragraph class="myClass">
> #else
>   <paragraph type="outerType">
> #end
> </paragraph>
> Or we have setattribute a-la:
> <paragraph>
> #if {something}
>   #@class={"myClass"}
> #else
>   #@type={"outerType"}
> #fi
> </paragraph>
> Think also in the case in which the attribute starts with "xmlns", so, the
> attribute defines a namespace scoping... I don't know... I need input on
> this.

You know I prefer the second one. This would also allow to use XML 
editors while you need a Garbage editor for the first one - or do you 
already have one in your sleeve ;-)

> ----------------------------------------------------------------------------
> Including and "calling" templates:
> ----------------------------------
> I believe that Chris outlined that we definitely need to have an #include or
> #import function to import templates defined in other source files, but I
> also wanted to know if there's the need to have a parallel to templates
> matching and application as in XSLT...

How to handle context switching? Or is it not needed because it's just 
used as simple template language?

Simple sample:

#foreach {row}
     #foreach {cell}

In more complex cases templates would allow reusability. Depends on the 
use cases for this template language.

> Personally, I don't need it... I believe that the source template should
> exactly look like the output we want to produce, so "applying templates on
> matching template rules" should be out of the question, but maybe something
> like this might be useful:
> <html>
> <body>
> #foreach {request/header}
>   #call "subtemplate"
> #end
> </body>
> </html>
> #template "subtemplate"
>   <p>
>      {./value}
>   </p>
> #end
> Allowing "call" to access internally defined subtemplates, and to access
> templates defined in other files...
> Dunno...
> ----------------------------------------------------------------------------
> Output caching:
> ---------------
> I believe it is wrong to give to the template a copy of the "response"
> object in any case (the response should be available only to serializers,
> not to generators).
> Also, I think that the "request" object should not always be given to the
> template (and included in the set of objects available to JXPath) because of
> problems with caching...
> I believe that (correct me if I'm wrong), if every object in the root JXPath
> context is cacheable and valid, and if the template has not changed, its
> output should not be re-generated, and therefore the entire generation can
> be cached (as we do with the FileGenerator).
> Imagine that somehow, in a factory somewhere, I create an "Article" object,
> and that is cached in my JVM by my "ArticleFactory"
> If "Article" implements "CacheableProcessingComponent", and at request time
> this has not changed, and the template itself has not changed, I don't think
> that we need to re-run the generation stage again.
> Giving access to "Request" to the template at all times, implies that we
> cannot really make sure whether the generator will (or will not) produce the
> same output over and over again...
> I'd say to make it optional, or to have a way to "map" the objects going
> into the JXPath context of the GarbageGenerator...
> ----------------------------------------------------------------------------
> I hope I am making some sense... If not, flame me badly... It's 2:30 am, and
> I spent the whole day coding JSPs with a bad fever :-(

Not so bad :-)


> (Lame excuse, but! :-) )
>     Pier

View raw message