EventCartridge

[Brian Lloyd-Newberry <ne...@yahoo.com>]

Hey All,

    Frequently in processor that I am writing/using I need to be able
to give users (i.e. me) a "intelligent" message in regards to what is
happening when there are null references or other velocity odditities
in their templates.

    Right now I can use an EventCartridge to catch a NullSetEvent or a
MethodExceptionEvent, but I am at a loss as to how to make use of the
event to display a line and resource identifier so the user can fix
their problem. As I see the code it is not possible to get information
relative to the node that an event came from (where I could get the
line and column) and even if i had a node get the resource it was
parsed from.

    The "look in the velocity log" argument is not really an option for
writing a viable tool as far as I see it for several reasons. Is this
something that would be desirable to others? Is this the intention of
the EventCartridge? It seems like an Event in the Cartridge should
contain the source node for the event. I would be willing to look at
the code and "work on it" unless I get screamed down. :)

    Another issue is that sometimes I get messed up line numbers or
line numbers without reference to a resource in the log when something
funky happens. Usually I am merging multiple resources one after
another in the same Velocity instance with the same Context. Is this a
known issue? I can probably come up with test cases to show it
happening if need be.

-Brian


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Re: I would like to stop now, please. Re: EventCartridge

[Jonathan Revusky <jr...@terra.es>]

Paulo Gaspar wrote:
> 
> Mirror talk?

Possibly. I'm not entirely innocent on that front either. It's normal
that, if you put a lot of hard work into something, you can be very
sensitive about people saying anything bad about your "baby". At this
stage of life, I am probably more self-aware and try to keep it under
control....

> 
> > -----Original Message-----
> > From: revusky@jr.revusky.com [mailto:revusky@jr.revusky.com]On Behalf Of
> > Jonathan Revusky
> >
> > ...
> >
> > You're so damned ego-involved that you cannot seem to react to comments
> > that even remotely resemble criticism in a balanced way. It is sad that
> > you wear your hyper-sensitivity on your sleeve like this. But it's like
> > something is now stuck in your craw and you're not letting go and it's
> > really tiresome...
> >
> > <sigh>
> >
> > Jonathan Revusky

Jonathan Revusky
--
available for Java/Delphi/Internet consulting
If you want to...
- make your .class files double-clickable with SmartJ
- do Delphi/Java mixed programming with easy-to-use JNI wrapper classes
- build robust web applications with the Niggle Application Framework
then...
check out the Revusky Hacks Page: http://www.revusky.com/hacks/

RE: I would like to stop now, please. Re: EventCartridge

[Paulo Gaspar <pa...@krankikom.de>]

Mirror talk?

> -----Original Message-----
> From: revusky@jr.revusky.com [mailto:revusky@jr.revusky.com]On Behalf Of
> Jonathan Revusky
>
> ...
>
> You're so damned ego-involved that you cannot seem to react to comments
> that even remotely resemble criticism in a balanced way. It is sad that
> you wear your hyper-sensitivity on your sleeve like this. But it's like
> something is now stuck in your craw and you're not letting go and it's
> really tiresome...
> 
> <sigh>
> 
> Jonathan Revusky

I would like to stop now, please. Re: EventCartridge

[Jonathan Revusky <jr...@terra.es>]

"Geir Magnusson Jr." wrote:
> 
> Brian Lloyd-Newberry wrote:
> >
> > Hey All,
> >
> >     Frequently in processor that I am writing/using I need to be able
> > to give users (i.e. me) a "intelligent" message in regards to what is
> > happening when there are null references or other velocity odditities
> > in their templates.
> >
> >     Right now I can use an EventCartridge to catch a NullSetEvent or a
> > MethodExceptionEvent, but I am at a loss as to how to make use of the
> > event to display a line and resource identifier so the user can fix
> > their problem. As I see the code it is not possible to get information
> > relative to the node that an event came from (where I could get the
> > line and column) and even if i had a node get the resource it was
> > parsed from.
> 
> Yes, that's something we didn't think of when we did it.  I think the
> general feeling was to make it more for runtime use, but this certainly
> is valid.
> 
> Ug.
> 
> I read the message a while ago when I got home, and have been stewing
> over it... makes me wonder what to do other than tell you to read the
> manual.
> 
> (Sorry, I couldn't resist the last part :)
> 
> >     The "look in the velocity log" argument is not really an option for
> > writing a viable tool as far as I see it for several reasons. Is this
> > something that would be desirable to others? Is this the intention of
> > the EventCartridge? It seems like an Event in the Cartridge should
> > contain the source node for the event. I would be willing to look at
> > the code and "work on it" unless I get screamed down. :)
> 
> No, looking at the log isn't that hip for your use, I suppose, although
> it's easy for you to implement a custom logger so you get the log
> messages programatically.  I don't know if that would help.  Take a look
> at the ExternalLoggerTest test case (org.apache.velocity.test) or the
> logger_example in /examples.  And read the docs too.
> 
> (aw, sorry, did it again...)

Please give it a rest. I never said that someone trying to use velocity
in a very advanced, specific way, like the person you're replying to
should not have to read the docs, or quite possibly root around in the
source. And I certainly never said, as somebody was implying in a recent
(pile-on) email that people are specifically *not supposed to* read the
docs!!!???

I was making a simple point about the undesirability of having
out-of-the-box defaults that are anti-intuitive. That's about it. 

Look, you've put a lot of work in, hard, good work, and you're proud of
it and you have the right to be proud of it. BUT:

You're so damned ego-involved that you cannot seem to react to comments
that even remotely resemble criticism in a balanced way. It is sad that
you wear your hyper-sensitivity on your sleeve like this. But it's like
something is now stuck in your craw and you're not letting go and it's
really tiresome...

<sigh>

Jonathan Revusky
--
available for Java/Delphi/Internet consulting
If you want to...
- make your .class files double-clickable with SmartJ
- do Delphi/Java mixed programming with easy-to-use JNI wrapper classes
- build robust web applications with the Niggle Application Framework
then...
check out the Revusky Hacks Page: http://www.revusky.com/hacks/

Re: EventCartridge

["Geir Magnusson Jr." <ge...@optonline.net>]

Brian Lloyd-Newberry wrote:
> 
> Hey All,
> 
>     Frequently in processor that I am writing/using I need to be able
> to give users (i.e. me) a "intelligent" message in regards to what is
> happening when there are null references or other velocity odditities
> in their templates.
> 
>     Right now I can use an EventCartridge to catch a NullSetEvent or a
> MethodExceptionEvent, but I am at a loss as to how to make use of the
> event to display a line and resource identifier so the user can fix
> their problem. As I see the code it is not possible to get information
> relative to the node that an event came from (where I could get the
> line and column) and even if i had a node get the resource it was
> parsed from.

Yes, that's something we didn't think of when we did it.  I think the
general feeling was to make it more for runtime use, but this certainly
is valid.

Ug.

I read the message a while ago when I got home, and have been stewing
over it... makes me wonder what to do other than tell you to read the
manual.

(Sorry, I couldn't resist the last part :)

>     The "look in the velocity log" argument is not really an option for
> writing a viable tool as far as I see it for several reasons. Is this
> something that would be desirable to others? Is this the intention of
> the EventCartridge? It seems like an Event in the Cartridge should
> contain the source node for the event. I would be willing to look at
> the code and "work on it" unless I get screamed down. :)

No, looking at the log isn't that hip for your use, I suppose, although
it's easy for you to implement a custom logger so you get the log
messages programatically.  I don't know if that would help.  Take a look
at the ExternalLoggerTest test case (org.apache.velocity.test) or the
logger_example in /examples.  And read the docs too.

(aw, sorry, did it again...)

The intention of the EventCartridge was to handle runtime issues, such
as escaping XML on insertion into the stream, catching exceptions when a
method invoked by the template threw one, or squelching log messages
that the programmer didn't care about.  Very runtime-ish/production-ish
issues. It wasn't really intended to be a diagnostic tool like this for
development, mainly because we felt that the runtime features were
needed, and you could look at the log :)

I wonder if you could combine the features of the external logger with
that of the event firings...

Hmmm. Ah!  How about this - we work out some way where the event
cartridge you are attached to will tell you information about the
current event.  That way, we don't have to spooge the interfaces...

I'll see if I can sketch something out and post it.


>     Another issue is that sometimes I get messed up line numbers or
> line numbers without reference to a resource in the log when something
> funky happens. Usually I am merging multiple resources one after
> another in the same Velocity instance with the same Context. Is this a
> known issue? I can probably come up with test cases to show it
> happening if need be.

Yes please.  That would be great!

geir

-- 
Geir Magnusson Jr.                           geirm@optonline.net
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
You have a genius for suggesting things I've come a cropper with!