cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <>
Subject Re: [RFI] Garbage
Date Tue, 24 Jun 2003 01:29:22 GMT
On 23/6/03 23:37, "Stefano Mazzocchi" <> wrote:

> on 6/22/03 2:01 PM Christopher Oliver wrote:
>> OK, I added GarbageGenerator to the scratchpad and integrated it with
>> the flow layer. I also added a copy of the Calculator flowscript sample
>> using the garbage generator to the scratchpad samples.
> Wow, you guys rock! community power at work!

In-diddly-deed (too much Ned Flanders?)

>> I would also like to add a Garbage view to Petstore, but I need you to
>> implement #include first ;)
> Yeah, Pier, do you have a todo list for Garbage? maybe people can jump
> in and help.

I wanted to wait a little to put the code out, but once Chris sent me an
implementation of "#foreach", I decided it would have been better more
visible out in the wild and in bad shape than on my CVS in a better one...

This week I'm haunted by but there are a few things
I'd like to discuss and make happen:


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">
  <paragraph type="outerType">

Or we have setattribute a-la:

#if {something}

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


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

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:

#foreach {request/header}
  #call "subtemplate"

#template "subtemplate"

Allowing "call" to access internally defined subtemplates, and to access
templates defined in other files...



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

(Lame excuse, but! :-) )


View raw message