You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Hervé Guidetti <he...@idbsoft.ch> on 2001/02/20 09:46:57 UTC
Velocity and wrong file name
Hi,
I use Velocity via the TurbineVelocity service.
I call :
handleRequest(context, filename, bytes);
But if the filename is wrong (the file doesn't exist) the bytes array
(bytes) is empty and no exception is thrown.
Is that normal ?
I'd except an exception ?
It seems logical to get an exception. Isn't it ??
Is that a bug ?
Thanks.
Hervé Guidetti
Re: Velocity and wrong file name
Posted by Jason van Zyl <jv...@periapt.com>.
On Wed, 21 Feb 2001, Geir Magnusson Jr. wrote:
> Was doing a little review of this, and the problem really isn't centered
> around Template.merge() - rather Runtime.getTemplate() may be where we
> should focus.
>
> getTemplate() currently returns a healthy, working Template or null,
> null when it can't find the resource (file) or parse it due to syntax
> error. Now, that hides the reason (although it is logged...)
>
> How about we create a new set of exceptions :
>
> org.apache.velocity.exception.ResourceNotFoundException
> org.apache.velocity.exception.ParseErrorException
>
> to get started, and have getTemplate() throw those. That basically are
> the two problem conditions that are really common and predictable with
> this, and it would make the Turbiners happy.
>
> I am suggesting the new package o.a.v.exception, as we have a
> o.a.v.runtime.exception package already, but that is for internal stuff,
> and o.a.v.runtime.parser.ParserException, but again, that's internal for
> the most part.
>
> Maybe o.a.v.app.exception ? Maybe that's better.
I think o.a.v.Exception is fine.
jvz.
Re: Velocity and wrong file name
Posted by Jason van Zyl <jv...@periapt.com>.
On Wed, 21 Feb 2001, Geir Magnusson Jr. wrote:
> Was doing a little review of this, and the problem really isn't centered
> around Template.merge() - rather Runtime.getTemplate() may be where we
> should focus.
>
> getTemplate() currently returns a healthy, working Template or null,
> null when it can't find the resource (file) or parse it due to syntax
> error. Now, that hides the reason (although it is logged...)
>
> How about we create a new set of exceptions :
>
> org.apache.velocity.exception.ResourceNotFoundException
> org.apache.velocity.exception.ParseErrorException
>
> to get started, and have getTemplate() throw those. That basically are
> the two problem conditions that are really common and predictable with
> this, and it would make the Turbiners happy.
>
> I am suggesting the new package o.a.v.exception, as we have a
> o.a.v.runtime.exception package already, but that is for internal stuff,
> and o.a.v.runtime.parser.ParserException, but again, that's internal for
> the most part.
>
> Maybe o.a.v.app.exception ? Maybe that's better.
I think o.a.v.Exception is fine.
jvz.
Re: Velocity and wrong file name
Posted by Daniel Rall <dl...@collab.net>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
> Daniel Rall wrote:
> >
> > "Geir Magnusson Jr." <ge...@optonline.net> writes:
> >
> > > Paulo Gaspar wrote:
> > > >
> > > > Why not placing user Exceptions and other "most used" classes directly on
> > > > org.apache.velocity?
> > >
> > > I thought about that at first, but figured it would help organize a
> > > bit. Not sure what the convention is around here. I just wanted to get
> > > them out of the bowels...
> >
> > IMHO, exceptions should be placed in the same package as classes that
> > use them the most. If no package looks to be a likely candidate, then
> > go with an exception package.
>
> That makes sense.
>
> I think these are exceptions for 'external use' - things that Vel will
> throw to applications using Velocity, rather than used internally. We
> have exceptions that we use internally, scattered about in the
> appropriate place.
In that case, it sounds like either org.apache.velocity.exception or
org.apache.velocity would be a good place.
--
Daniel Rall <dl...@collab.net>
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Daniel Rall wrote:
>
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
>
> > Paulo Gaspar wrote:
> > >
> > > Why not placing user Exceptions and other "most used" classes directly on
> > > org.apache.velocity?
> >
> > I thought about that at first, but figured it would help organize a
> > bit. Not sure what the convention is around here. I just wanted to get
> > them out of the bowels...
>
> IMHO, exceptions should be placed in the same package as classes that
> use them the most. If no package looks to be a likely candidate, then
> go with an exception package.
That makes sense.
I think these are exceptions for 'external use' - things that Vel will
throw to applications using Velocity, rather than used internally. We
have exceptions that we use internally, scattered about in the
appropriate place.
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
RE: Velocity and wrong file name
Posted by Paulo Gaspar <pa...@krankikom.de>.
The reason I defended placing those exceptions directly in the
"org.apache.velocity" package is just ease of use.
IMO, _if_ you have a framework which functionality can be typical
achieved just trough a small number of classes, you should place
those classes on the "root" of the library (being Velocity root
at "org.apache.velocity").
Following this logic, these Exceptions should be placed there
just because the correct use of the library also depends on them.
Now, noticed my "_if_" above. The reason I just described might
not be the only one. It is just something to consider.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: dlr@despot.finemaltcoding.com
> [mailto:dlr@despot.finemaltcoding.com]On Behalf Of Daniel Rall
>
>
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
>
> > Paulo Gaspar wrote:
> > >
> > > Why not placing user Exceptions and other "most used" classes
> directly on
> > > org.apache.velocity?
> >
> > I thought about that at first, but figured it would help organize a
> > bit. Not sure what the convention is around here. I just wanted to get
> > them out of the bowels...
>
> IMHO, exceptions should be placed in the same package as classes that
> use them the most. If no package looks to be a likely candidate, then
> go with an exception package.
> --
>
> Daniel Rall <dl...@collab.net>
>
Re: Velocity and wrong file name
Posted by Daniel Rall <dl...@collab.net>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
> Paulo Gaspar wrote:
> >
> > Why not placing user Exceptions and other "most used" classes directly on
> > org.apache.velocity?
>
> I thought about that at first, but figured it would help organize a
> bit. Not sure what the convention is around here. I just wanted to get
> them out of the bowels...
IMHO, exceptions should be placed in the same package as classes that
use them the most. If no package looks to be a likely candidate, then
go with an exception package.
--
Daniel Rall <dl...@collab.net>
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Paulo Gaspar wrote:
>
> Why not placing user Exceptions and other "most used" classes directly on
> org.apache.velocity?
I thought about that at first, but figured it would help organize a
bit. Not sure what the convention is around here. I just wanted to get
them out of the bowels...
>
> Otherwise, I also prefer org.apache.velocity.exception as package name.
>
> Have fun,
> Paulo
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
RE: Velocity and wrong file name
Posted by Paulo Gaspar <pa...@krankikom.de>.
Why not placing user Exceptions and other "most used" classes directly on
org.apache.velocity?
Otherwise, I also prefer org.apache.velocity.exception as package name.
Have fun,
Paulo
Re: Velocity and wrong file name
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/21/01 11:39 AM, "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> How about we create a new set of exceptions :
>
> org.apache.velocity.exception.ResourceNotFoundException
> org.apache.velocity.exception.ParseErrorException
>
> to get started, and have getTemplate() throw those. That basically are
> the two problem conditions that are really common and predictable with
> this, and it would make the Turbiners happy.
>
> I am suggesting the new package o.a.v.exception, as we have a
> o.a.v.runtime.exception package already, but that is for internal stuff,
> and o.a.v.runtime.parser.ParserException, but again, that's internal for
> the most part.
>
> Maybe o.a.v.app.exception ? Maybe that's better.
>
> ideas?
Sounds good. The first package name is fine...
o.a.v.e.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/>
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Was doing a little review of this, and the problem really isn't centered
around Template.merge() - rather Runtime.getTemplate() may be where we
should focus.
getTemplate() currently returns a healthy, working Template or null,
null when it can't find the resource (file) or parse it due to syntax
error. Now, that hides the reason (although it is logged...)
How about we create a new set of exceptions :
org.apache.velocity.exception.ResourceNotFoundException
org.apache.velocity.exception.ParseErrorException
to get started, and have getTemplate() throw those. That basically are
the two problem conditions that are really common and predictable with
this, and it would make the Turbiners happy.
I am suggesting the new package o.a.v.exception, as we have a
o.a.v.runtime.exception package already, but that is for internal stuff,
and o.a.v.runtime.parser.ParserException, but again, that's internal for
the most part.
Maybe o.a.v.app.exception ? Maybe that's better.
ideas?
I think this will fit ok into the current resource management
structure...
geir
Rafal Krzewski wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > I guess if that was the case (lots of Velocity-specific exceptions
> > possible) , it can be handled down there in the TurbineVelocityService,
> > and just map to whatever set of exceptions turbine may use internally.
> > It's not clear that Turbine has this kind of support in that the
> > 'template engine agnostic' model may be a figment of my fevered
> > imagination.
>
> I don't see anything wrong with catching the bunch of Velocity specific
> exceptions in VelocityService and mapping them to what ever higher-level
> behaviour is desired. Right now the policy is (or at least I think it
> is) wrapping the exception into a TurbineException and passing it to the
> application (Screen/Layout class etc). If the application doesn't handle
> it, catch-all code at the end main Turbine service method will grab it
> and try to display a '500' page.
>
> You havbe my non-commiter +1 to fine grained exceptions in Velocity
>
> Rafal
>
> --
> Rafal Krzewski
> Senior Internet Developer
> mailto:Rafal.Krzewski@e-point.pl
> +48 22 8534830 http://e-point.pl
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Was doing a little review of this, and the problem really isn't centered
around Template.merge() - rather Runtime.getTemplate() may be where we
should focus.
getTemplate() currently returns a healthy, working Template or null,
null when it can't find the resource (file) or parse it due to syntax
error. Now, that hides the reason (although it is logged...)
How about we create a new set of exceptions :
org.apache.velocity.exception.ResourceNotFoundException
org.apache.velocity.exception.ParseErrorException
to get started, and have getTemplate() throw those. That basically are
the two problem conditions that are really common and predictable with
this, and it would make the Turbiners happy.
I am suggesting the new package o.a.v.exception, as we have a
o.a.v.runtime.exception package already, but that is for internal stuff,
and o.a.v.runtime.parser.ParserException, but again, that's internal for
the most part.
Maybe o.a.v.app.exception ? Maybe that's better.
ideas?
I think this will fit ok into the current resource management
structure...
geir
Rafal Krzewski wrote:
>
> "Geir Magnusson Jr." wrote:
>
> > I guess if that was the case (lots of Velocity-specific exceptions
> > possible) , it can be handled down there in the TurbineVelocityService,
> > and just map to whatever set of exceptions turbine may use internally.
> > It's not clear that Turbine has this kind of support in that the
> > 'template engine agnostic' model may be a figment of my fevered
> > imagination.
>
> I don't see anything wrong with catching the bunch of Velocity specific
> exceptions in VelocityService and mapping them to what ever higher-level
> behaviour is desired. Right now the policy is (or at least I think it
> is) wrapping the exception into a TurbineException and passing it to the
> application (Screen/Layout class etc). If the application doesn't handle
> it, catch-all code at the end main Turbine service method will grab it
> and try to display a '500' page.
>
> You havbe my non-commiter +1 to fine grained exceptions in Velocity
>
> Rafal
>
> --
> Rafal Krzewski
> Senior Internet Developer
> mailto:Rafal.Krzewski@e-point.pl
> +48 22 8534830 http://e-point.pl
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: VTL syntax
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
David Esposito wrote:
>
> <FONT color="#if($Error)red#elseblack#endif">
>
> it just plain doesn't work ... i tried the following, it evaluates correctly
> but the fact that there is a leading space in the color="" value causes the
> browser to not render the font the way I want it ...
>
> <FONT color="#if($Error)red#else black#endif">
<FONT #if($error) color="red" #else color="black" #end >
(we don't have an #endif :)
> any suggestions? any chance that you could add an optional semicolon
> delimiter or something to the keyword so that I can inline it without having
> to use whitespace to seperate it out?
NO.
>
> thanks in advance ..
>
> -dave
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: VTL syntax
Posted by Christoph Reck <Ch...@dlr.de>.
Hi folks,
I'm using a *very* simple solution to this:
<FONT color="#if($Error)red#else#**#black#endif">
it's using a comment as the else delimeter!
Hope this helps you all!
:) Christoph
David Esposito wrote:
>[snip]
> <FONT color="#if($Error)red#elseblack#endif">
>
> it just plain doesn't work ... i tried the following, it evaluates correctly
> but the fact that there is a leading space in the color="" value causes the
> browser to not render the font the way I want it ...
>
> <FONT color="#if($Error)red#else black#endif">
>
> any suggestions? any chance that you could add an optional semicolon
> delimiter or something to the keyword so that I can inline it without having
> to use whitespace to seperate it out?
>
> thanks in advance ..
>
> -dave
Re: VTL syntax
Posted by Steve Ruby <st...@rubysolutions.com>.
Steve Ruby wrote:
>
> Jason van Zyl wrote:
> >
> > > yah, a little hacky but i like it ... in VTL, however, since there are no
> > > delimiters for keywords except whitespace, i can't do it ... If i try:
> > >
> > > <FONT color="#if($Error)red#elseblack#endif">
> >
> > #if($Error)red#elseblack#end">
> >
> > There is no #endif
>
> Something similar on my end did not render properly as
> above, it actually printed out #elseblack
>
> something like this worked with no extra space in the output
>
> #if($Error)red#else black#end">
I'm wrong.. mine didn't work when the test was false..
but Jason's doesn't work either, it outputs #else
IMHO the best way to handle this in velocity would
be to have an if directive that was more like a function
than a statement as many other langes have such as
#iif( $Statement, truevalue, falsevalue )
that sure would be the cleanest way on the template side.
For now you may juave have to expand your font tag
out into multiple lines or better yet make it a macro
Re: VTL syntax
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
jeff wrote:
>
> Steve Ruby wrote:
> >
> > Jason van Zyl wrote:
> > >
> > > > yah, a little hacky but i like it ... in VTL, however, since there are no
> > > > delimiters for keywords except whitespace, i can't do it ... If i try:
> > > >
> > > > <FONT color="#if($Error)red#elseblack#endif">
> > >
> > > #if($Error)red#elseblack#end">
> > >
> > > There is no #endif
> >
> > Something similar on my end did not render properly as
> > above, it actually printed out #elseblack
> >
> > something like this worked with no extra space in the output
> >
> > #if($Error)red#else black#end">
>
> How about
>
> #set ($black = "black")
> <font color="#if($Error)red#else$black#end">
I just *gotta* fix that parser bug.
Hmmm. I was reading on a list just yesterday... Hey! I got it! What
if we started using { and } to delimit blocks?
(I'm not serious...)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: VTL syntax
Posted by jeff <jl...@houseofdistraction.com>.
Steve Ruby wrote:
>
> Jason van Zyl wrote:
> >
> > > yah, a little hacky but i like it ... in VTL, however, since there are no
> > > delimiters for keywords except whitespace, i can't do it ... If i try:
> > >
> > > <FONT color="#if($Error)red#elseblack#endif">
> >
> > #if($Error)red#elseblack#end">
> >
> > There is no #endif
>
> Something similar on my end did not render properly as
> above, it actually printed out #elseblack
>
> something like this worked with no extra space in the output
>
> #if($Error)red#else black#end">
How about
#set ($black = "black")
<font color="#if($Error)red#else$black#end">
Re: VTL syntax
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
David Esposito wrote:
>
> yes yes yes ... that's probably what i'll end up using ... ;) ... i just
> like to torment people a bit ... :)
>
> (btw, is there a way to do this with a velocimacro? ... like the IIF()
> function that steve suggested a few messages ago)
Here's a quickie. Should work :
#macro( iif $val $tr $fal)
#if($val)${tr}#else${fal}#end
#end
Test :
>#iif( true "a" "b")<
geir
> > -----Original Message-----
> > From: gmj@mta4.srv.hcvlny.cv.net [mailto:gmj@mta4.srv.hcvlny.cv.net]On
> > Behalf Of Geir Magnusson Jr.
> > Sent: Wednesday, February 21, 2001 3:49 PM
> > To: velocity-user@jakarta.apache.org
> > Subject: Re: VTL syntax
> >
> >
> > David Esposito wrote:
> > >
> > > hmm ... interesting that you didn't get a space ... i checked and I'm
> > > certainly getting the space ...
> > >
> > > here's a terrible terrible hack ... ;) ... it actually works ...
> > >
> > > <FONT color="#if($Error)red#else$!{dead}black#end">
> > >
> > > where the variable "dead" is not defined (not in the context)...
> >
> >
> > Ugh.
> >
> > Just for grins, what's wrong with :
> >
> > <FONT #if($Error) color="red" #else color="black" #end >
> >
> > ?
> >
> > geir
> >
> >
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
RE: VTL syntax
Posted by David Esposito <es...@newnetco.com>.
yes yes yes ... that's probably what i'll end up using ... ;) ... i just
like to torment people a bit ... :)
(btw, is there a way to do this with a velocimacro? ... like the IIF()
function that steve suggested a few messages ago)
> -----Original Message-----
> From: gmj@mta4.srv.hcvlny.cv.net [mailto:gmj@mta4.srv.hcvlny.cv.net]On
> Behalf Of Geir Magnusson Jr.
> Sent: Wednesday, February 21, 2001 3:49 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: VTL syntax
>
>
> David Esposito wrote:
> >
> > hmm ... interesting that you didn't get a space ... i checked and I'm
> > certainly getting the space ...
> >
> > here's a terrible terrible hack ... ;) ... it actually works ...
> >
> > <FONT color="#if($Error)red#else$!{dead}black#end">
> >
> > where the variable "dead" is not defined (not in the context)...
>
>
> Ugh.
>
> Just for grins, what's wrong with :
>
> <FONT #if($Error) color="red" #else color="black" #end >
>
> ?
>
> geir
>
>
Re: VTL syntax
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
David Esposito wrote:
>
> hmm ... interesting that you didn't get a space ... i checked and I'm
> certainly getting the space ...
>
> here's a terrible terrible hack ... ;) ... it actually works ...
>
> <FONT color="#if($Error)red#else$!{dead}black#end">
>
> where the variable "dead" is not defined (not in the context)...
Ugh.
Just for grins, what's wrong with :
<FONT #if($Error) color="red" #else color="black" #end >
?
geir
> > -----Original Message-----
> > From: Steve Ruby [mailto:steve@rubysolutions.com]
> > Sent: Wednesday, February 21, 2001 2:08 PM
> > To: velocity-user@jakarta.apache.org
> > Subject: Re: VTL syntax
> >
> >
> > Jason van Zyl wrote:
> > >
> > > > yah, a little hacky but i like it ... in VTL, however, since
> > there are no
> > > > delimiters for keywords except whitespace, i can't do it ... If i try:
> > > >
> > > > <FONT color="#if($Error)red#elseblack#endif">
> > >
> > > #if($Error)red#elseblack#end">
> > >
> > > There is no #endif
> >
> >
> > Something similar on my end did not render properly as
> > above, it actually printed out #elseblack
> >
> > something like this worked with no extra space in the output
> >
> > #if($Error)red#else black#end">
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
RE: VTL syntax
Posted by David Esposito <es...@newnetco.com>.
hmm ... interesting that you didn't get a space ... i checked and I'm
certainly getting the space ...
here's a terrible terrible hack ... ;) ... it actually works ...
<FONT color="#if($Error)red#else$!{dead}black#end">
where the variable "dead" is not defined (not in the context)...
> -----Original Message-----
> From: Steve Ruby [mailto:steve@rubysolutions.com]
> Sent: Wednesday, February 21, 2001 2:08 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: VTL syntax
>
>
> Jason van Zyl wrote:
> >
> > > yah, a little hacky but i like it ... in VTL, however, since
> there are no
> > > delimiters for keywords except whitespace, i can't do it ... If i try:
> > >
> > > <FONT color="#if($Error)red#elseblack#endif">
> >
> > #if($Error)red#elseblack#end">
> >
> > There is no #endif
>
>
> Something similar on my end did not render properly as
> above, it actually printed out #elseblack
>
> something like this worked with no extra space in the output
>
> #if($Error)red#else black#end">
Re: VTL syntax
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Keng Wong wrote:
>
> I tried that and it still shows a space before 'black'.
> <font color=" black">
> In freemarker, there is a tag 'compress' which does a similar
> function to remove white spaces. Is there a similar tag in VM ?
There is a little parser bug there. (alas) How about trying
<FONT #if($foo) color="black" #else color="red" #end >
for now?
geir
> -----Original Message-----
> From: Steve Ruby [mailto:steve@rubysolutions.com]
> Sent: Wednesday, February 21, 2001 11:08 AM
> To: velocity-user@jakarta.apache.org
> Subject: Re: VTL syntax
>
> Jason van Zyl wrote:
> >
> > > yah, a little hacky but i like it ... in VTL, however, since there are
> no
> > > delimiters for keywords except whitespace, i can't do it ... If i try:
> > >
> > > <FONT color="#if($Error)red#elseblack#endif">
> >
> > #if($Error)red#elseblack#end">
> >
> > There is no #endif
>
> Something similar on my end did not render properly as
> above, it actually printed out #elseblack
>
> something like this worked with no extra space in the output
>
> #if($Error)red#else black#end">
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
RE: VTL syntax
Posted by Keng Wong <ke...@verizon.net>.
I tried that and it still shows a space before 'black'.
<font color=" black">
In freemarker, there is a tag 'compress' which does a similar
function to remove white spaces. Is there a similar tag in VM ?
-----Original Message-----
From: Steve Ruby [mailto:steve@rubysolutions.com]
Sent: Wednesday, February 21, 2001 11:08 AM
To: velocity-user@jakarta.apache.org
Subject: Re: VTL syntax
Jason van Zyl wrote:
>
> > yah, a little hacky but i like it ... in VTL, however, since there are
no
> > delimiters for keywords except whitespace, i can't do it ... If i try:
> >
> > <FONT color="#if($Error)red#elseblack#endif">
>
> #if($Error)red#elseblack#end">
>
> There is no #endif
Something similar on my end did not render properly as
above, it actually printed out #elseblack
something like this worked with no extra space in the output
#if($Error)red#else black#end">
Re: VTL syntax
Posted by Steve Ruby <st...@rubysolutions.com>.
Jason van Zyl wrote:
>
> > yah, a little hacky but i like it ... in VTL, however, since there are no
> > delimiters for keywords except whitespace, i can't do it ... If i try:
> >
> > <FONT color="#if($Error)red#elseblack#endif">
>
> #if($Error)red#elseblack#end">
>
> There is no #endif
Something similar on my end did not render properly as
above, it actually printed out #elseblack
something like this worked with no extra space in the output
#if($Error)red#else black#end">
RE: VTL syntax
Posted by David Esposito <es...@newnetco.com>.
sorry ... that was a typo ... i don't have #endif anywhere in my code ...
just #end ...
> -----Original Message-----
> From: Jason van Zyl [mailto:jvanzyl@periapt.com]
> Sent: Wednesday, February 21, 2001 1:49 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: VTL syntax
>
>
>
>
> > yah, a little hacky but i like it ... in VTL, however, since
> there are no
> > delimiters for keywords except whitespace, i can't do it ... If i try:
> >
> > <FONT color="#if($Error)red#elseblack#endif">
>
> #if($Error)red#elseblack#end">
>
> There is no #endif
>
> > it just plain doesn't work ... i tried the following, it
> evaluates correctly
> > but the fact that there is a leading space in the color=""
> value causes the
> > browser to not render the font the way I want it ...
> >
> > <FONT color="#if($Error)red#else black#endif">
>
> Really, you got this to work?
>
> jvz.
>
Re: VTL syntax
Posted by Jason van Zyl <jv...@periapt.com>.
> yah, a little hacky but i like it ... in VTL, however, since there are no
> delimiters for keywords except whitespace, i can't do it ... If i try:
>
> <FONT color="#if($Error)red#elseblack#endif">
#if($Error)red#elseblack#end">
There is no #endif
> it just plain doesn't work ... i tried the following, it evaluates correctly
> but the fact that there is a leading space in the color="" value causes the
> browser to not render the font the way I want it ...
>
> <FONT color="#if($Error)red#else black#endif">
Really, you got this to work?
jvz.
VTL syntax
Posted by David Esposito <es...@newnetco.com>.
me again ... ;)
here's what I want to do ... I want to have a section of text change color
based on a variable in the context ... so something like this
if the Error variable is set, print:
<FONT color="red">
else, print:
<FONT color="black">
end if
The way i've implemented this before in languages such as cold fusion are as
follows
<FONT color="<CFIF IsDefined("Error")>red<CFELSE>black</CFIF>">
yah, a little hacky but i like it ... in VTL, however, since there are no
delimiters for keywords except whitespace, i can't do it ... If i try:
<FONT color="#if($Error)red#elseblack#endif">
it just plain doesn't work ... i tried the following, it evaluates correctly
but the fact that there is a leading space in the color="" value causes the
browser to not render the font the way I want it ...
<FONT color="#if($Error)red#else black#endif">
any suggestions? any chance that you could add an optional semicolon
delimiter or something to the keyword so that I can inline it without having
to use whitespace to seperate it out?
thanks in advance ..
-dave
RE: Velocity and wrong file name
Posted by Paulo Gaspar <pa...@krankikom.de>.
Same here!
Paulo Gaspar
> -----Original Message-----
> From: fil@krankikom.de [mailto:fil@krankikom.de]On Behalf Of
> Rafal Krzewski
>
> ...
>
> You havbe my non-commiter +1 to fine grained exceptions in Velocity
>
> Rafal
>
> --
> Rafal Krzewski
> Senior Internet Developer
> mailto:Rafal.Krzewski@e-point.pl
> +48 22 8534830 http://e-point.pl
>
Re: Velocity and wrong file name
Posted by Rafal Krzewski <Ra...@e-point.pl>.
"Geir Magnusson Jr." wrote:
> I guess if that was the case (lots of Velocity-specific exceptions
> possible) , it can be handled down there in the TurbineVelocityService,
> and just map to whatever set of exceptions turbine may use internally.
> It's not clear that Turbine has this kind of support in that the
> 'template engine agnostic' model may be a figment of my fevered
> imagination.
I don't see anything wrong with catching the bunch of Velocity specific
exceptions in VelocityService and mapping them to what ever higher-level
behaviour is desired. Right now the policy is (or at least I think it
is) wrapping the exception into a TurbineException and passing it to the
application (Screen/Layout class etc). If the application doesn't handle
it, catch-all code at the end main Turbine service method will grab it
and try to display a '500' page.
You havbe my non-commiter +1 to fine grained exceptions in Velocity
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:Rafal.Krzewski@e-point.pl
+48 22 8534830 http://e-point.pl
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Magnus ?or Torfason wrote:
>
> >
> > We can, in Velocity, declare a few of our own exceptions, and throw
> > those. The thing I was trying to do is to keep it as simple as possible
> > to keep the number of import classes specific to Velocity to a minimum -
> > especially if Turbine is moving towards a 'template engine agnostic'
> > model. There is not much you can do with really specific information at
> > runtime, I think, and it's logged anyway in the vel runtime log.
> >
> > I guess if that was the case (lots of Velocity-specific exceptions
> > possible) , it can be handled down there in the TurbineVelocityService,
> > and just map to whatever set of exceptions turbine may use internally.
> > It's not clear that Turbine has this kind of support in that the
> > 'template engine agnostic' model may be a figment of my fevered
> > imagination.
> >
> > geir
>
> I have very good experience with having a specific Exception declared for
> each of my subsystems (comparable to org.apache.velocity.VelocityException
> or something like that).
Now, I realize some of you mistakenly think of Velocity as a Turbine
subsystem...
:)
> Classes that wish to communicate specific errors then define INNER classes
> (static) as exceptions, that extend the base Exception. No imports :)
That's good and clean, but that would be for internal use within and
between your subsystem(s), right?
Here, the problem is how to communicate information out of Velocity
into, in this case, Turbine, but this would apply to any app.
Having a set of simple velocity exceptions to throw up to app code would
help here, but I think we really should resist unless there is no way to
clearly communicate this information upwards...
geir
> Magnus
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
RE: Velocity and wrong file name
Posted by Magnus ?or Torfason <ma...@handtolvur.is>.
>
> We can, in Velocity, declare a few of our own exceptions, and throw
> those. The thing I was trying to do is to keep it as simple as possible
> to keep the number of import classes specific to Velocity to a minimum -
> especially if Turbine is moving towards a 'template engine agnostic'
> model. There is not much you can do with really specific information at
> runtime, I think, and it's logged anyway in the vel runtime log.
>
> I guess if that was the case (lots of Velocity-specific exceptions
> possible) , it can be handled down there in the TurbineVelocityService,
> and just map to whatever set of exceptions turbine may use internally.
> It's not clear that Turbine has this kind of support in that the
> 'template engine agnostic' model may be a figment of my fevered
> imagination.
>
> geir
I have very good experience with having a specific Exception declared for
each of my subsystems (comparable to org.apache.velocity.VelocityException
or something like that).
Classes that wish to communicate specific errors then define INNER classes
(static) as exceptions, that extend the base Exception. No imports :)
Magnus
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Paulo Gaspar wrote:
>
> Hi again Geir,
>
> Option 1) does not sound so bat to me:
> - If Turbine does not know the "ParseException" it can just deal with
> it as it would with a generic Exception;
> - Wouldn't then be simple to improve whatever wrappers Turbine has for
> Velocity with this more specific exception?
>
The point is to provide enough information such that Turbine (and anyone
else) can figure out if the problem in a merge is file-ish or parse-ish
at runtime (w/o having to peek at the log) as the application, if
file-ish, may make another attempt and try a different file (the example
given was localized sets of templates...)
We can, in Velocity, declare a few of our own exceptions, and throw
those. The thing I was trying to do is to keep it as simple as possible
to keep the number of import classes specific to Velocity to a minimum -
especially if Turbine is moving towards a 'template engine agnostic'
model. There is not much you can do with really specific information at
runtime, I think, and it's logged anyway in the vel runtime log.
I guess if that was the case (lots of Velocity-specific exceptions
possible) , it can be handled down there in the TurbineVelocityService,
and just map to whatever set of exceptions turbine may use internally.
It's not clear that Turbine has this kind of support in that the
'template engine agnostic' model may be a figment of my fevered
imagination.
geir
> Have fun,
> Paulo
>
> > -----Original Message-----
> > From: gmj@mta8.srv.hcvlny.cv.net [mailto:gmj@mta8.srv.hcvlny.cv.net]On
> > Behalf Of Geir Magnusson Jr.
> >
> > ...
> >
> > The issues I see :
> >
> > 1) If we through something like a org.apache.velocity.XXX.ParseException
> > to indicate a parser exception, would this muddle up anything in Turbine
> > as you now have to import velocity specific things into 'upper' layers
> > of your code? I really don't like this.
> >
> > ...
> >
> > geir
> >
> > --
> > Geir Magnusson Jr. geirm@optonline.com
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity
RE: Velocity and wrong file name
Posted by Paulo Gaspar <pa...@krankikom.de>.
Hi again Geir,
Option 1) does not sound so bat to me:
- If Turbine does not know the "ParseException" it can just deal with
it as it would with a generic Exception;
- Wouldn't then be simple to improve whatever wrappers Turbine has for
Velocity with this more specific exception?
Have fun,
Paulo
> -----Original Message-----
> From: gmj@mta8.srv.hcvlny.cv.net [mailto:gmj@mta8.srv.hcvlny.cv.net]On
> Behalf Of Geir Magnusson Jr.
>
> ...
>
> The issues I see :
>
> 1) If we through something like a org.apache.velocity.XXX.ParseException
> to indicate a parser exception, would this muddle up anything in Turbine
> as you now have to import velocity specific things into 'upper' layers
> of your code? I really don't like this.
>
> ...
>
> geir
>
> --
> Geir Magnusson Jr. geirm@optonline.com
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Hervé Guidetti wrote:
>
> > I checked in a tiny fix - just threw an exception in Template.merge()
> > when we didn't have an AST. It's the same message as what is logged.
> >
> > We might want to split this into two kinds of exceptions, one for
> > 'ResourceNotFound' and the other for 'ParseError', but it may really not
> > add much value...
> >
>
> Not sure...
> I have a multilanguage system. If a file doesn't exist, i use another file
> (default language).
> So it is important if the file exist and has error or if the file doesn't
> exist.
First, you can tell from the velocity log what happened - if it's an
existance or parse problem. Not sure what you would do in the
application anyway - if the file didn't exist, you would try the default
language file. If the file had a syntax error in VTL, there is nothing
you could do at runtime anyway. I guess you could log into the turbine
log that you have a parse error.
The fix may be a little bigger than us doing something for you in
velocity.
For example in TurbineVelocityService.java, if an exception is thrown by
merge(), it is caught, run through renderingError(), and then a Turbine
exception is thrown.
I assume you can find the class of the exception that is wrapped in
TurbineException.
The issues I see :
1) If we through something like a org.apache.velocity.XXX.ParseException
to indicate a parser exception, would this muddle up anything in Turbine
as you now have to import velocity specific things into 'upper' layers
of your code? I really don't like this.
2) Would it be enough to distinquish between an IOException and an
Exception? Since the two problems that can happen, at the largest
length scale are 'some issue about the file' and 'some issue within the
file', you would be able to distinguish between the two.
3) A conceptual issue is that at merge() time, you don't actually go
find the file. That would have happened before you get to call
merge(). We can throw an IOException to indicate that we don't have a
valid parsed template because of file reasons, which may be a little
more honest that a FileNotFoundException, because we can't currently
tell if it's an actual FileNotFoundException, or other things (like if
the FileResourceLoader is enforcing security and rejects a filename
because it has a '..' in the path...).
I will start working down #2/#3 and if no one has any better
suggestions... :)
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Hervé Guidetti wrote:
>
> > I checked in a tiny fix - just threw an exception in Template.merge()
> > when we didn't have an AST. It's the same message as what is logged.
> >
> > We might want to split this into two kinds of exceptions, one for
> > 'ResourceNotFound' and the other for 'ParseError', but it may really not
> > add much value...
> >
>
> Not sure...
> I have a multilanguage system. If a file doesn't exist, i use another file
> (default language).
> So it is important if the file exist and has error or if the file doesn't
> exist.
That's reasonable.
Will see what we can do.
geir
> > I saw in a Turbine list thread that Turbine will handle a thrown
> > exception just fine. (That was one of the concerns about doing this...)
> >
> > Since this didn't change the signature of the method, this shouldn't
> > hurt anyone, because merge() is in a try/catch anyway.
> >
> > See if this makes anyone happy...
> >
> > geir
> >
> >
> > Hervé Guidetti wrote:
> > >
> > > Hi,
> > >
> > > I use Velocity via the TurbineVelocity service.
> > > I call :
> > > handleRequest(context, filename, bytes);
> > >
> > > But if the filename is wrong (the file doesn't exist) the bytes array
> > > (bytes) is empty and no exception is thrown.
> > > Is that normal ?
> > > I'd except an exception ?
> > > It seems logical to get an exception. Isn't it ??
> > > Is that a bug ?
> > >
> > > Thanks.
> > >
> > > Hervé Guidetti
> >
> > --
> > Geir Magnusson Jr. geirm@optonline.com
> >
> > Developing for the web? See http://jakarta.apache.org/velocity
> >
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity
Re: Velocity and wrong file name
Posted by Hervé Guidetti <he...@idbsoft.ch>.
> I checked in a tiny fix - just threw an exception in Template.merge()
> when we didn't have an AST. It's the same message as what is logged.
>
> We might want to split this into two kinds of exceptions, one for
> 'ResourceNotFound' and the other for 'ParseError', but it may really not
> add much value...
>
Not sure...
I have a multilanguage system. If a file doesn't exist, i use another file
(default language).
So it is important if the file exist and has error or if the file doesn't
exist.
> I saw in a Turbine list thread that Turbine will handle a thrown
> exception just fine. (That was one of the concerns about doing this...)
>
> Since this didn't change the signature of the method, this shouldn't
> hurt anyone, because merge() is in a try/catch anyway.
>
> See if this makes anyone happy...
>
> geir
>
>
> Hervé Guidetti wrote:
> >
> > Hi,
> >
> > I use Velocity via the TurbineVelocity service.
> > I call :
> > handleRequest(context, filename, bytes);
> >
> > But if the filename is wrong (the file doesn't exist) the bytes array
> > (bytes) is empty and no exception is thrown.
> > Is that normal ?
> > I'd except an exception ?
> > It seems logical to get an exception. Isn't it ??
> > Is that a bug ?
> >
> > Thanks.
> >
> > Hervé Guidetti
>
> --
> Geir Magnusson Jr. geirm@optonline.com
>
> Developing for the web? See http://jakarta.apache.org/velocity
>
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
I checked in a tiny fix - just threw an exception in Template.merge()
when we didn't have an AST. It's the same message as what is logged.
We might want to split this into two kinds of exceptions, one for
'ResourceNotFound' and the other for 'ParseError', but it may really not
add much value...
I saw in a Turbine list thread that Turbine will handle a thrown
exception just fine. (That was one of the concerns about doing this...)
Since this didn't change the signature of the method, this shouldn't
hurt anyone, because merge() is in a try/catch anyway.
See if this makes anyone happy...
geir
Hervé Guidetti wrote:
>
> Hi,
>
> I use Velocity via the TurbineVelocity service.
> I call :
> handleRequest(context, filename, bytes);
>
> But if the filename is wrong (the file doesn't exist) the bytes array
> (bytes) is empty and no exception is thrown.
> Is that normal ?
> I'd except an exception ?
> It seems logical to get an exception. Isn't it ??
> Is that a bug ?
>
> Thanks.
>
> Hervé Guidetti
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
What would be the most useful here?
We are free to throw an exception here as the definition of merge()
allows that. We don't know, at the moment, what the reason is in
merge(), because either
1) the template wasn't available (invalid filename)
2) the template did exist, but there was a parse error.
In either case, it will be clear from the log what happened.
We can figure it out within Template by being a little more careful in
process() when we get the resource from the loader, and then when we
parse, so we *can* figure it out.
Would it help to have something more structured than simply an Exception
with a nice message, or is having a set of exceptions going to help?
There is not much you can practically do, btw, from your app if your
template doesn't parse...
geir
Hervé Guidetti wrote:
>
> > Hervé Guidetti wrote:
> > >
> > > Hi,
> > >
> > > I use Velocity via the TurbineVelocity service.
> > > I call :
> > > handleRequest(context, filename, bytes);
> > >
> > > But if the filename is wrong (the file doesn't exist) the bytes array
> > > (bytes) is empty and no exception is thrown.
> > > Is that normal ?
> > > I'd except an exception ?
> > > It seems logical to get an exception. Isn't it ??
> > > Is that a bug ?
> > >
> > > Thanks.
> > >
> > > Hervé Guidetti
> >
> >
> > For specific Turbine questions, your best bet would be the Turbine
> > lists. Thanks very much.
> >
> > geir
> >
>
> I did. But this is not a Turbine problem. Turbine just calls Velocity with
> this code :
> handleRequest(context, filename, bytes);
> But if the filename isn't valid, no exception is thrown.
>
> Hervé
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Hervé Guidetti wrote:
>
> > Hervé Guidetti wrote:
> > >
> > > Hi,
> > >
> > > I use Velocity via the TurbineVelocity service.
> > > I call :
> > > handleRequest(context, filename, bytes);
> > >
> > > But if the filename is wrong (the file doesn't exist) the bytes array
> > > (bytes) is empty and no exception is thrown.
> > > Is that normal ?
> > > I'd except an exception ?
> > > It seems logical to get an exception. Isn't it ??
> > > Is that a bug ?
> > >
> > > Thanks.
> > >
> > > Hervé Guidetti
> >
> >
> > For specific Turbine questions, your best bet would be the Turbine
> > lists. Thanks very much.
> >
> > geir
> >
>
> I did. But this is not a Turbine problem. Turbine just calls Velocity with
> this code :
> handleRequest(context, filename, bytes);
> But if the filename isn't valid, no exception is thrown.
Ok. Will take a look. I didn't remember where we had a call
'handleRequest()' though.
Sorry about that....
geir
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity
Re: Velocity and wrong file name
Posted by Hervé Guidetti <he...@idbsoft.ch>.
> Hervé Guidetti wrote:
> >
> > Hi,
> >
> > I use Velocity via the TurbineVelocity service.
> > I call :
> > handleRequest(context, filename, bytes);
> >
> > But if the filename is wrong (the file doesn't exist) the bytes array
> > (bytes) is empty and no exception is thrown.
> > Is that normal ?
> > I'd except an exception ?
> > It seems logical to get an exception. Isn't it ??
> > Is that a bug ?
> >
> > Thanks.
> >
> > Hervé Guidetti
>
>
> For specific Turbine questions, your best bet would be the Turbine
> lists. Thanks very much.
>
> geir
>
I did. But this is not a Turbine problem. Turbine just calls Velocity with
this code :
handleRequest(context, filename, bytes);
But if the filename isn't valid, no exception is thrown.
Hervé
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Hervé Guidetti wrote:
>
> Hi,
>
> I use Velocity via the TurbineVelocity service.
> I call :
> handleRequest(context, filename, bytes);
>
> But if the filename is wrong (the file doesn't exist) the bytes array
> (bytes) is empty and no exception is thrown.
> Is that normal ?
> I'd except an exception ?
> It seems logical to get an exception. Isn't it ??
> Is that a bug ?
>
> Thanks.
>
> Hervé Guidetti
For specific Turbine questions, your best bet would be the Turbine
lists. Thanks very much.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity
Re: Velocity and wrong file name
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Christoph Reck wrote:
>
> Geir, this is a velocity sepcifc question. Poor Hervé already was
> told on the turbine list to post the question on this list.
>
> I did a quick look over the Vel sources and its true that
> Template.merge() does not throw an exception even though it
> declares it would. Somebody with insight must cross-check
> if it breaks something if it is changed to throw one.
>
> It seems that it is a simple change to add a throws clause
> to Template.merge() in addition to the logging.
So all would be well if merge() tossed an exception along with logging?
Is handleRequest( ) in turbine? what is *it* expecting?
Will the exception pass through to the app code?
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity
Re: Velocity and wrong file name
Posted by Christoph Reck <Ch...@dlr.de>.
Geir, this is a velocity sepcifc question. Poor Hervé already was
told on the turbine list to post the question on this list.
I did a quick look over the Vel sources and its true that
Template.merge() does not throw an exception even though it
declares it would. Somebody with insight must cross-check
if it breaks something if it is changed to throw one.
It seems that it is a simple change to add a throws clause
to Template.merge() in addition to the logging.
:) Christoph
"Geir Magnusson Jr." wrote:
>
> Hervé Guidetti wrote:
> >
> > Hi,
> >
> > I use Velocity via the TurbineVelocity service.
> > I call :
> > handleRequest(context, filename, bytes);
> >
> > But if the filename is wrong (the file doesn't exist) the bytes array
> > (bytes) is empty and no exception is thrown.
> > Is that normal ?
> > I'd except an exception ?
> > It seems logical to get an exception. Isn't it ??
> > Is that a bug ?
> >
> > Thanks.
> >
> > Hervé Guidetti
>
> For specific Turbine questions, your best bet would be the Turbine
> lists. Thanks very much.
>
> geir
>
> --
> Geir Magnusson Jr. geirm@optonline.com
> Velocity : it's not just a good idea. It should be the law.
> http://jakarta.apache.org/velocity