"Stefano Mazzocchi" <[EMAIL PROTECTED]> wrote:
> on 6/23/03 8:29 PM Pier Fumagalli wrote:
>
>> SetAttribute vs Well-formedness:
>> --------------------------------
>> [...]
>>
>> #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>
>> [...]
>
> 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.
The more I look at it, the more I like the second approach myself...
Thinking about it, it's a slightly more significant change in the
parser/tree implementation, but it can be done...
>> Including and "calling" templates:
>> ----------------------------------
>> [...]
>>
>> <html>
>> <body>
>> #foreach {request/header}
>> #call "subtemplate"
>> #end
>> </body>
>> </html>
>>
>> #template "subtemplate"
>> <p>
>> {./value}
>> </p>
>> #end
>
> 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.
As we're using JXPath, passing parameters will simply involve passing a
different reference into the source object tree as our "." (context)
element. But yeah, it's non-trivial, and will deserve more thought.
>> Output caching:
>> ---------------
>> [...]
>>
>> 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.
Well, getRemoteAddr() is enough to screw things up...
>> 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?
That is not "that" hard... When we create the JXPath context to be given to
the tree processor, we can check each object included into it: in the old
days we were checking for the "LastModified" attribute of the object, right
now I still have to figure out what "SourceValidity" is all about, but I
believe it's doable.
>> 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.
Template caching is no-more-no-less difficult than caching an XML file
generated by the FileGenerator.
The only difference is that as we add objects to the JXPath context, we have
to check for the "LastModified" value of each one of them (if they implement
a specific interface).
The "LastModified" value of the result will be the greater value of either
the tree itself, or of the objects making up the context.
>> 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?
As I said, I am positive that it's going to be MUCH faster than processing
the entire template with JXPath evaluations, tree walking, and
yadayadayada... I'll try to come up with some numbers...
Pier
