Paulo Gaspar wrote:
>
> But wouldn't it be better to also consider what is essential and what
> is optional? Isn't *.velocity.app the place for application tools?
I guess I don't think of it as tools, but the application-centric API.
I mean, the point of the Velocity class is to not only supply some
useful extra stuff, but decouple application programs from Runtime -
that's why you should use the Velocity class init(), getTemplate(),
setPropert(), etc, rather than use Runtime.
It gives us the degree of freedom to change the underlying impl of
Runtime.
> Of course that my interpretation can be wrong, but one thing I would
> really like (and I hope not to be alone on that) is a clear separation
> from what is essential and what is optional, on a package basis.
me too.
> And, believe me, I already have a lot of trouble with this separation
> since my framework provides a lot of functionality that is redundant
> (for me) in Velocity. A clear separation between "core" and "optional"
> (and this has various levels in Velocity) would make its reuse
> simpler for a wider range of usages.
and smaller :)
> Some extra remarks on the Event Handlers:
> - In NullSetEventHandler, why is the method called
> "nullSetLogMessage()"? One does not have to log the message and no
> message is directly involved. What about "nullSetAttempt()"?
er, the method returns true or false as a vote whether or not to log.
it has nothing to do with the #set() of the LHS.
This is something I added to solve the problem that the
#set($foo = $!bar)
and other variants were supposed to address, meaning a 'quiet #set()'.
> - Why having
> NullReferenceEventHandler.nullReferenceRender() (1)
> and
> ReferenceInsertionEventHandler.referenceInsert() (2)
> AFAIK, they do a similar thing, one for non silent null values and
> the other for non null values. Following the pattern of the first
> (1) case, we should have (instead of the second (2))
> ReferenceEventHandler.referenceRender()
> or
> NonNullReferenceEventHandler.nonNullReferenceRender()
>
> For some people (not you Geir) this might look like a detail, but the
> names of classes and methods are the first (most immediate) level of
> documentation. They can make reading further documentation unnecessary
> or they can induce confusion.
Try and keep up, chief. :)
NullReferenceEventHandler is gone. It's redundant.
> In my case, at a 1st look, I thought that
> ReferenceInsertionEventHandler.referenceInsert()
> was a #set() related event (a bit like in NullSetEventHandler) since
> #set can be used to "insert" a value in the context's hash table.
>
>
> BTW, since I started making big and complex XML exports, I just fell
> in love for these events. I am starting to use them now and it sure
> avoids a lot of template mess... or data structure code mess.
>
If you have some alternate suggestions for the methods, please - now is
the time to fix this - it will be virtually impossible to do later.
And if you have a good suggestion for what package the event stuff can
move to, that would be great as well.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
"still climbing up to the shoulders..."
