Answer inline:
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Geir Magnusson Jr.
>
> 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(),
> setProperty(), etc, rather than use Runtime.
>
> It gives us the degree of freedom to change the underlying impl of
> Runtime.
Ok, my bad interpretation.
That way I don't know anymore.
> ... stuff we agree on ...
>
> and smaller :)
YEEEEEESSSSSSSSS!!!!
> > 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()'.
Ops! I should have paid more attention to that one!
The name really says it!
> > - 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.
You are too fast!
I took a look at the cvs log just 2 days ago!
=:o)
The possibility of it being redundant crossed my mind while writing the
previous post, but I was not very sure about the whole thing.
> 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.
My favorite event.method() names would be:
ReferenceRenderEventHandler.referenceRender()
(for the ReferenceInsertionEventHandler.referenceInsert())
and
NullSetEventHandler.shouldLogNullSetAttempt()
(for the NullSetEventHandler.nullSetLogMessage())
> And if you have a good suggestion for what package the event stuff can
> move to, that would be great as well.
No better ideas than *.velocity.app.events, which puts the events a bit
apart because,
- More events can still pop up;
- They do not have as much common use as other *.velocity.app classes,
and this way they do not clutter that app-common-use package.
(I am adapting to your POV on *.velocity.app now.)
I will probably be some 48 hours offline now (ARGH!). I will follow up
this on Sunday. Thanks for the (as usual) fast answer.
Have fun,
Paulo Gaspar
