Paulo Gaspar wrote:
>
> 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.
?
Yea or nea on *.velocity.apps.events ?
>
> > > 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!
If no one cares about this we can drop it, although it's minor overhead
compared to outputting a log message.
>
> > > - 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())
That's good too - I think that the 'Insert' came from the notion of
'inserting' into the output stream.
> and
> NullSetEventHandler.shouldLogNullSetAttempt()
> (for the NullSetEventHandler.nullSetLogMessage())
That's better. Anyone concur, or would be greviously harmed if change?
Since it does return boolean, this makes more sense...
> > 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 certainly will, for sure...
> - 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.
ARGH!
--
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..."