on 6/23/03 8:29 PM 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}
> [EMAIL PROTECTED]"myClass"}
> #else
> [EMAIL PROTECTED]"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.
I like the second better. It's more structured, suggests a non-textual
vision of the created content, while the first is too PHP-like for my
personal taste.
But then again, if we are going for utter simplicity, probably newbies
think of text more than they think about an abstract infoset
representation of the content. So #1 might be easier to understand up front.
A verbosity problem, however, comes out if we have several attributes to
be conditionally decided, because that creates an explosion of possible
element/attributes combinations and all of them have to be exposed.
Nah, I vote for #2.
> ----------------------------------------------------------------------------
>
> 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:
>
> <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...
This is what they call "macro" in Velocity and I bet that it might be
something people will ask once include is implemented as you can 'reuse'
parts of the templates between them.
But I would leave the #call concept out for now, also because parameter
passing is not exactly a no brainer to design.
> ----------------------------------------------------------------------------
>
> 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).
Agreed. Also note that if you need to modify stuff in the response, you
have the flow to do it. Views should not mess with the transport but
only with the content and having access to the view allows them to mess
with transport and I dislike it.
> 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...
Hmmm, I don't know here, you might end up copying a bunch of request
stuff into the model passed to the view, but you are right pointing out
that Caching is an important aspect to consider. But I wonder if
performing an hashcode of the bean passed to the view is good enough to
estimate its ergodicity.
> 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).
this is true if and only if the output of the template is a function of
the input only (for example, doesn't depend on things like time or
system load or other environmental inputs). But again, how are you going
to identify if the input to the template hasn't changed?
> 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.
This is true only if you have a way to understand if the input to the
template hasn't changed between the last execution. Understanding this
might, in general, be more expensive than redoing the processing.
Until we implement a caching system that can adapt to efficiency
measurement (as I planned before the current SAX-based cache was
implemented), the whole value of template caching is hard to estimate.
> 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...
this is probably a more transparent way of doing it, but again I'm not
sure how expensive this is going to be.
What do you think?
--
Stefano.
