You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Lloyd Llewellyn <su...@twilight-systems.com> on 2001/07/23 06:50:20 UTC
Velocity wishlist :-)
Hello - I am new on this list.
I'm fairly new to Java and have started using Tomcat and Velocity for a
new project. I really like the template concept, and the "YMTD" article
was right on the money, IMHO.
Having used it a bit, I have some suggestions. I know the way to do
this is to shut up and contribute code, but I simply don't have the
resources. I thought I might bring this up to get feedback on whether
these features would be conceptually appropriate for Velocity, whether
or not they are actually implemented:
1) Support for floats - that one had me going for awhile :-) I also
seem to recall some problems with other types, e.g. comparing them to
literal values and not getting the expected results.
2) Formatting utilities - I understand the approach is to have the
developer supply utility objects to the context, but it would be a big
overall labor savings for everyone if a comprehensive set of formatting
facilities could be made available by default to the template designers.
This is a fundamental job of the UI/presentation layer, so it seems like
it would belong. (There may be other common presentation-oriented tasks
that would merit inclusion in a standard set of Velocity template
designer utility classes...?) Even if this does not belong in Velocity
Proper, it would make a good sub-project.
3) Some simple string functions would be handy - I'd like to be able to
inspect substrings:
#if ( #substring($dateText, 1, 3) = "Sat" ||
#substring($dateText, 1, 3) = "Sun" )
<place special formatting for weekends here>
#end
Otherwise the programmer has to add otherwise unneeded and redundant
fields to his objects:
public boolean getIsWeekend() {...}
4) A prototyping tool that would allow the velocity template designer
to define test objects, populate them with data, and then use them to
render actual web pages. It would be useful for the designer (or
developer for that matter) to just create some bogus sample objects to
design with. This would allow the designer to play around with the
structure of the objects a bit, add a field here or there, without
depending on the programmer who writes the servlets. While I agree that
close cooperation between developer and designer is important, you
don't want to make the progress of one dependent on the other.
BTW, I'd like to make the following philosophical observation:
Velocity's stated purpose is to keep the programming logic out of the
presentation. However, by not having the formatting and simple
inspection (e.g. substring) tools available to template designers, it
seems to force some presentation tasks onto the programmers.
Finally, an unrelated question - are there any indications that Sun
intends to make Velocity a sort of "official" Java tool? Or are they
married to JSP for presentation?
Thanks for listening, and thanks for a great product! It's a big help
as we convert our IIS/COM applications over to Java! :-)
Re: Velocity wishlist :-)
Posted by Christoph Reck <Ch...@dlr.de>.
See embedded responses.
Lloyd Llewellyn wrote:
>
> Hello - I am new on this list.
>
> I'm fairly new to Java and have started using Tomcat and Velocity for a
> new project. I really like the template concept, and the "YMTD" article
> was right on the money, IMHO.
Velicity rocks!
>
> Having used it a bit, I have some suggestions. I know the way to do
> this is to shut up and contribute code, but I simply don't have the
> resources. I thought I might bring this up to get feedback on whether
> these features would be conceptually appropriate for Velocity, whether
> or not they are actually implemented:
>
> 1) Support for floats - that one had me going for awhile :-) I also
> seem to recall some problems with other types, e.g. comparing them to
> literal values and not getting the expected results.
To be considered, I believe this is somewhere with higher priority in
Geirs list.
>
> 2) Formatting utilities - I understand the approach is to have the
> developer supply utility objects to the context, but it would be a big
> overall labor savings for everyone if a comprehensive set of formatting
> facilities could be made available by default to the template designers.
> This is a fundamental job of the UI/presentation layer, so it seems like
> it would belong. (There may be other common presentation-oriented tasks
> that would merit inclusion in a standard set of Velocity template
> designer utility classes...?) Even if this does not belong in Velocity
> Proper, it would make a good sub-project.
The problem here is that each application will have its own objects,
requirements, and approaches. It will be hard to create a generic set.
We have started on this in the jakarta org.apache.commons.ruppert on
this.
I guess that some date, number, currency, sprintf, regexp, etc. might
come handy. Please contribute as you complete your requirements and
approach. DateTool is already in commons.ruppert, the NumberFormatter
is part of Java (see a previous mail about this), I've used the
ORO regexp for some s/// patterns within template macros.
>
> 3) Some simple string functions would be handy - I'd like to be able to
> inspect substrings:
>
> #if ( #substring($dateText, 1, 3) = "Sat" ||
> #substring($dateText, 1, 3) = "Sun" )
>
> <place special formatting for weekends here>
>
> #end
>
> Otherwise the programmer has to add otherwise unneeded and redundant
> fields to his objects:
>
> public boolean getIsWeekend() {...}
How about:
#if( $dateText.substring(1, 3) == "Sat" ||
$dateText.substring(1).startswith("Sun") )
<place special formatting for weekends here>
#end
Java is quite rich in string processing functions directly on the
string object instance.
>
> 4) A prototyping tool that would allow the velocity template designer
> to define test objects, populate them with data, and then use them to
> render actual web pages. It would be useful for the designer (or
> developer for that matter) to just create some bogus sample objects to
> design with. This would allow the designer to play around with the
> structure of the objects a bit, add a field here or there, without
> depending on the programmer who writes the servlets. While I agree that
> close cooperation between developer and designer is important, you
> don't want to make the progress of one dependent on the other.
I've created a wonderful VTL scripted controller servlet application
for this purpose. The servlet initializes a root context with a
init.vm script (with global constants, tools: e.g. COLORS hashtable,
applcation constants, etc.) It allows instantiation of anything via $Class.getInstance("name"). Then, per request loads a request.vm script
(which defines/instantiates request dependent stuff and thread unsafe
tools). The request.vm defines a view template which is then loaded by
the servlet (by defining the "template" variable in the context). And
finally a layout.vm template is loaded (or whatever is defined in the
"layout" variable name), to provide a common layout for the output
(e.g. with menu, navigation bar formatting, footer, etc.).
This allows defining any variable on the fly within request.vm to be
used by the designer template.
For performance enhancement or for complex business logic then the
request processing part can be substituted independently by the
java programmer as needed.
I can send the controller servlet source to anyone who is interested.
The context tools for this are in the commons.ruppert package.
>
> BTW, I'd like to make the following philosophical observation:
> Velocity's stated purpose is to keep the programming logic out of the
> presentation. However, by not having the formatting and simple
> inspection (e.g. substring) tools available to template designers, it
> seems to force some presentation tasks onto the programmers.
see above.
>
> Finally, an unrelated question - are there any indications that Sun
> intends to make Velocity a sort of "official" Java tool? Or are they
> married to JSP for presentation?
>
> Thanks for listening, and thanks for a great product! It's a big help
> as we convert our IIS/COM applications over to Java! :-)
:) Christoph
Re: Velocity wishlist :-)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Lloyd Llewellyn wrote:
>
> Hello - I am new on this list.
>
> I'm fairly new to Java and have started using Tomcat and Velocity for a
> new project. I really like the template concept, and the "YMTD" article
> was right on the money, IMHO.
>
> Having used it a bit, I have some suggestions. I know the way to do
> this is to shut up and contribute code, but I simply don't have the
> resources. I thought I might bring this up to get feedback on whether
> these features would be conceptually appropriate for Velocity, whether
> or not they are actually implemented:
>
> 1) Support for floats - that one had me going for awhile :-) I also
> seem to recall some problems with other types, e.g. comparing them to
> literal values and not getting the expected results.
Yes, this is an area that seems to be causing problems lately.
Generally speaking, it's considered not necessary to support floats in
VTL. This is a philosophical argument - some people take it to the
extreme and suggest that there is no need for integer math either. I
believe that the integer math is necessary - as a designer, it can be
very effective in doing calculations for layout and such, even the %
operator has come in handy for me from time to time for purely layout
uses.
However, floats to me are a different story. I agree that we need to fix
up ints a bit though.
Do you have a good argument to make to the community? To give you a
hint, the idea here is that VTL is aimed for designers, and not intended
to be a programming language.
>
> 2) Formatting utilities - I understand the approach is to have the
> developer supply utility objects to the context, but it would be a big
> overall labor savings for everyone if a comprehensive set of formatting
> facilities could be made available by default to the template designers.
> This is a fundamental job of the UI/presentation layer, so it seems like
> it would belong. (There may be other common presentation-oriented tasks
> that would merit inclusion in a standard set of Velocity template
> designer utility classes...?) Even if this does not belong in Velocity
> Proper, it would make a good sub-project.
We have started a subproject in Commons, called Rupert (don't ask...) in
the sandbox, so if there is something you find there, great. If you
want to dig into Rupert and help maintain/add/develop/whatever you can
contribute, that's even better.
The idea in Velocity (unlike WebMacro) is that we feel that these tools
shouldn't be handled by the Velocity core, but should be something that
is done in the app. We do make it easy to do in the app, as we offer
something called 'Context chaining' (or wrapping) where you can make a
context that has tools in it, and then wrap another context around it
for each request, keeping the 'tool context' clean for use again for
another request.
VelocityContext requestContext = new VelocityContext( toolContext );
and then add your data elements to requestContext - when the rendering
process is done, you can reuse the toolContext for another request.
>
> 3) Some simple string functions would be handy - I'd like to be able to
> inspect substrings:
>
> #if ( #substring($dateText, 1, 3) = "Sat" ||
> #substring($dateText, 1, 3) = "Sun" )
>
> <place special formatting for weekends here>
>
> #end
>
> Otherwise the programmer has to add otherwise unneeded and redundant
> fields to his objects:
>
> public boolean getIsWeekend() {...}
Or just drop a tool into the context. Nathan Bubna just sent me a date
formatting tool for Rupert that I will drop into the Rupert CVS.
> 4) A prototyping tool that would allow the velocity template designer
> to define test objects, populate them with data, and then use them to
> render actual web pages. It would be useful for the designer (or
> developer for that matter) to just create some bogus sample objects to
> design with. This would allow the designer to play around with the
> structure of the objects a bit, add a field here or there, without
> depending on the programmer who writes the servlets. While I agree that
> close cooperation between developer and designer is important, you
> don't want to make the progress of one dependent on the other.
+1, 100%. This is one of the few soft points that Velocity has relative
to JSP, and something that we will solve with a little prototyping
'framework'. Christoph has one, and I am playing with one I will offer
here or in Rupert if it seems useful.
> BTW, I'd like to make the following philosophical observation:
> Velocity's stated purpose is to keep the programming logic out of the
> presentation. However, by not having the formatting and simple
> inspection (e.g. substring) tools available to template designers, it
> seems to force some presentation tasks onto the programmers.
No, I don't agree - all you do is force the programmers to provide
formatting tools in the context, which I think is a legit compromise.
There is an uncountable infinity of tools that people need - so Velocity
can't even begin to supply them as part of the distro. We are trying to
solve this problem with community-donated tools (Rupert). This way, we
don't have to worry about having to make decisions to limit what ships
with Velocity tool-wise (because nothing does :)
> Finally, an unrelated question - are there any indications that Sun
> intends to make Velocity a sort of "official" Java tool? Or are they
> married to JSP for presentation?
In general - they are very married to JSP. However, work is going on to
address this ;) The important idea there is twofold :
1) Velocity isn't just for the web - it is a general templating tool
useful in applications that aren't web-based.
2) Having a choice in presentation technologies in the J2EE platform I
believe makes the platform that much more valuable. Users get to make a
choice between two solution, choosing that which best solves their
problems, or simply which they like better. Either way, the apps get
written in Java for the J2EE platform, and thus it benefits.
> Thanks for listening, and thanks for a great product! It's a big help
> as we convert our IIS/COM applications over to Java! :-)
:)
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: Documentation bug and more
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Tal Dayan wrote:
>
> > Is this a commercial product? If so, can it be mentioned on the
> > powered-by page? (Where we brag...)
> >
> >
> > geir
> >
>
> Yes, but I am not sure that they will want to expose it since they work in
> stealth mode. I will check it with them.
>
> I am involved in another commercial product, (Ontero InfoCentral from Ontero
> Inc, a zero administration
> Intranet solution, www.ontero.com). We are now in the process of integrating
> velocity in it.
>
> In the first phase Velocity will be used for peripheral facilities, one is
> to generate
> at runtime a server.xml configuration for Tomcat and the other is a mail
> template. Later
> we will consider using it also in the publishing engine.
>
> If you think this qualifies it for the Velocity 'seal', we may add it to the
> Velocity site.
Anything that uses Velocity is interesting!
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
RE: Documentation bug and more
Posted by Tal Dayan <ta...@zapta.com>.
> Is this a commercial product? If so, can it be mentioned on the
> powered-by page? (Where we brag...)
>
>
> geir
>
Yes, but I am not sure that they will want to expose it since they work in
stealth mode. I will check it with them.
I am involved in another commercial product, (Ontero InfoCentral from Ontero
Inc, a zero administration
Intranet solution, www.ontero.com). We are now in the process of integrating
velocity in it.
In the first phase Velocity will be used for peripheral facilities, one is
to generate
at runtime a server.xml configuration for Tomcat and the other is a mail
template. Later
we will consider using it also in the publishing engine.
If you think this qualifies it for the Velocity 'seal', we may add it to the
Velocity site.
Tal
Re: Documentation bug and more
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Tal Dayan wrote:
>
> Hi Gier,
>
> >
> > Nope. Thanks. I fixed the typo, and claified the following text.
>
> Thanks, it looks good. You may want to clarify also the semantic of the '=='
> operator.
> Does it uses the Java 'equals' method, the identity operator, or both,
> depending on the
> context ?
Equals - that's a good point...
>
> Take for example the following case:
>
> $s1 <- new String("a")
> $s2 <- new String("a")
>
> $i1 <- new Integer(1)
> $i2 <- new Integer(1)
>
> $f1 <- new Float(1.0)
> $f2 <- new Float(1.0)
>
> What will be the value of the conditions:
>
> ($s1 == $s2) // false ?
>
> ($i1 == $i2) // true ?
>
> ($f1 == $f2) // false ?
Yep - would be good to illustrate that as well.
> > > This raises again the issue of handling errors in the template.
> > >
> > > Velocity seems to be very casual about errors (or at least
> > > 'misunderstandings') in the template
> > > which makes it difficult to debug or test new templates. The
> > other case we
> > > encountered was
> > > when we the number we used in the comparison was a Long rather than an
> > > Integer. Between these
> > > two cases, we (that is, I) spent significant time to figure out what is
> > > going wrong and had to resort
> > > to consulting the source code.
> >
> > Did you consult the log? It should have listed something like -
> >
> > Tue Jul 24 06:27:26 EDT 2001 [error] Error in evaluation of ==
> > expression. Both arguments must be of the same Class. Currently left =
> > class java.lang.Long, right = class java.lang.Integer. tal.vm [line 3,
> > column 16] (ASTEQNode)
>
> This looks like a great error diagnostic. I should check the log.
> The point is that the log is not that visible, at least when you embed an
> out of the box Velocity in an existing application.
>
> How about making the error messages more 'in your face'. For example by
> sending the
> log to the standard output or even throwing an exception.
Not a chance :)
It would get lost to std out, and an exception would be horrendous (in
my opinion).
What you can do, if you like, is implement a logger, and hand that to
velocity. Velocity's logging system is quite simple and extensable -
you can make your own logger class, or even hand it a living object that
supports the right interface to use for logging.
See the logger example, as well as the ExternalLoggerTest in o.a.v.test
Once you have your own logging class, you can throw exceptions to your
hearts delight...
>
> > > BTW, we are using it from an application, not as a servlet.
> > >
> >
> > Cool. What does it do? (I love hearing about the app uses...)
>
> Velocity saved us a lot of development time and is much better than
> anything we could budget its developement.
>
> The application is a web based CRM product of a client of mine. They need to
> send email
> messages when certain events are past due so we use a velocity template to
> customize the email messages.
Coolness and beauty.
> There are few features of Velocity that helped us doing so:
>
> 1. The ability to return values back to the Java code. The email template
> uses this to control various email fields (to, cc, subject, etc) not just
> the message body. Otherwise
> we would have to use a template for each field or use a kludge that extracts
> the fields values form the text genrated by the template.
>
> 2. The ability to pass and access beans. Since the system already
> had beans for User, Acount, etc, we are just passing them to the template
> and all data
> is immedietly available to the tmeplate with virtually zero development (on
> our side ;-) ).
>
> 3. The ability to isolate the template from the rest of the Java code. With
> JSP, a
> template writer has full access to the Java VM and can modify global values,
> write
> to files, etc. We need to have a stricter control for security and
> maintenance reasons.
>
> 4. Ease of integration. It took us only few hours for the first activation
> of a simple
> template.
>
> The introduction of Velocity to that project was a great success and they
> are considering
> using it for other purposes.
Is this a commercial product? If so, can it be mentioned on the
powered-by page? (Where we brag...)
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: Documentation bug and more
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Tal Dayan wrote:
>
> I don't get any error or warning for the following:
>
> #if ($day = 3)
>
> #end
>
> Isn't the assignment operator illegal here ?
>
> If I get the Velocity Principle, shmoo is sacred but built in directives
> are open game. Following this approach, the above should generate and error.
> The same
> is $day is not an integer or undefined.
>
Hm. Yes, that should generate an error.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
RE: Documentation bug and more
Posted by Tal Dayan <ta...@zapta.com>.
I don't get any error or warning for the following:
#if ($day = 3)
#end
Isn't the assignment operator illegal here ?
If I get the Velocity Principle, shmoo is sacred but built in directives
are open game. Following this approach, the above should generate and error.
The same
is $day is not an integer or undefined.
Tal
> -----Original Message-----
> From: Barbara Baughman [mailto:baughman@utdallas.edu]
> Sent: Tuesday, July 24, 2001 12:05 PM
> To: velocity-user@jakarta.apache.org
> Subject: RE: Documentation bug and more
>
>
> You can catch the ParseErrorException from getTemplate() and output the
> error message wherever you please, including the context. I send mine to
> the console.
>
> I like the log as it is.
>
> Barbara Baughman
> X2157
>
> On Tue, 24 Jul 2001, Tal Dayan wrote:
>
> > > > This raises again the issue of handling errors in the template.
> > > >
> > > > Velocity seems to be very casual about errors (or at least
> > > > 'misunderstandings') in the template
> > > > which makes it difficult to debug or test new templates. The
> > > other case we
> > > > encountered was
> > > > when we the number we used in the comparison was a Long
> rather than an
> > > > Integer. Between these
> > > > two cases, we (that is, I) spent significant time to figure
> out what is
> > > > going wrong and had to resort
> > > > to consulting the source code.
> > >
> > > Did you consult the log? It should have listed something like -
> > >
> > > Tue Jul 24 06:27:26 EDT 2001 [error] Error in evaluation of ==
> > > expression. Both arguments must be of the same Class. Currently left =
> > > class java.lang.Long, right = class java.lang.Integer. tal.vm [line 3,
> > > column 16] (ASTEQNode)
> >
> > This looks like a great error diagnostic. I should check the log.
> > The point is that the log is not that visible, at least when
> you embed an
> > out of the box Velocity in an existing application.
> >
> > How about making the error messages more 'in your face'. For example by
> > sending the
> > log to the standard output or even throwing an exception.
>
>
RE: Documentation bug and more
Posted by Barbara Baughman <ba...@utdallas.edu>.
You can catch the ParseErrorException from getTemplate() and output the
error message wherever you please, including the context. I send mine to
the console.
I like the log as it is.
Barbara Baughman
X2157
On Tue, 24 Jul 2001, Tal Dayan wrote:
> > > This raises again the issue of handling errors in the template.
> > >
> > > Velocity seems to be very casual about errors (or at least
> > > 'misunderstandings') in the template
> > > which makes it difficult to debug or test new templates. The
> > other case we
> > > encountered was
> > > when we the number we used in the comparison was a Long rather than an
> > > Integer. Between these
> > > two cases, we (that is, I) spent significant time to figure out what is
> > > going wrong and had to resort
> > > to consulting the source code.
> >
> > Did you consult the log? It should have listed something like -
> >
> > Tue Jul 24 06:27:26 EDT 2001 [error] Error in evaluation of ==
> > expression. Both arguments must be of the same Class. Currently left =
> > class java.lang.Long, right = class java.lang.Integer. tal.vm [line 3,
> > column 16] (ASTEQNode)
>
> This looks like a great error diagnostic. I should check the log.
> The point is that the log is not that visible, at least when you embed an
> out of the box Velocity in an existing application.
>
> How about making the error messages more 'in your face'. For example by
> sending the
> log to the standard output or even throwing an exception.
RE: Documentation bug and more
Posted by Tal Dayan <ta...@zapta.com>.
Hi Gier,
>
> Nope. Thanks. I fixed the typo, and claified the following text.
Thanks, it looks good. You may want to clarify also the semantic of the '=='
operator.
Does it uses the Java 'equals' method, the identity operator, or both,
depending on the
context ?
Take for example the following case:
$s1 <- new String("a")
$s2 <- new String("a")
$i1 <- new Integer(1)
$i2 <- new Integer(1)
$f1 <- new Float(1.0)
$f2 <- new Float(1.0)
What will be the value of the conditions:
($s1 == $s2) // false ?
($i1 == $i2) // true ?
($f1 == $f2) // false ?
> > This raises again the issue of handling errors in the template.
> >
> > Velocity seems to be very casual about errors (or at least
> > 'misunderstandings') in the template
> > which makes it difficult to debug or test new templates. The
> other case we
> > encountered was
> > when we the number we used in the comparison was a Long rather than an
> > Integer. Between these
> > two cases, we (that is, I) spent significant time to figure out what is
> > going wrong and had to resort
> > to consulting the source code.
>
> Did you consult the log? It should have listed something like -
>
> Tue Jul 24 06:27:26 EDT 2001 [error] Error in evaluation of ==
> expression. Both arguments must be of the same Class. Currently left =
> class java.lang.Long, right = class java.lang.Integer. tal.vm [line 3,
> column 16] (ASTEQNode)
This looks like a great error diagnostic. I should check the log.
The point is that the log is not that visible, at least when you embed an
out of the box Velocity in an existing application.
How about making the error messages more 'in your face'. For example by
sending the
log to the standard output or even throwing an exception.
> > BTW, we are using it from an application, not as a servlet.
> >
>
> Cool. What does it do? (I love hearing about the app uses...)
Velocity saved us a lot of development time and is much better than
anything we could budget its developement.
The application is a web based CRM product of a client of mine. They need to
send email
messages when certain events are past due so we use a velocity template to
customize the email messages.
There are few features of Velocity that helped us doing so:
1. The ability to return values back to the Java code. The email template
uses this to control various email fields (to, cc, subject, etc) not just
the message body. Otherwise
we would have to use a template for each field or use a kludge that extracts
the fields values form the text genrated by the template.
2. The ability to pass and access beans. Since the system already
had beans for User, Acount, etc, we are just passing them to the template
and all data
is immedietly available to the tmeplate with virtually zero development (on
our side ;-) ).
3. The ability to isolate the template from the rest of the Java code. With
JSP, a
template writer has full access to the Java VM and can modify global values,
write
to files, etc. We need to have a stricter control for security and
maintenance reasons.
4. Ease of integration. It took us only few hours for the first activation
of a simple
template.
The introduction of Velocity to that project was a great success and they
are considering
using it for other purposes.
My next usage of Velocity (for a different organization) will be a dynamic
generation of configuration
files. One of the problem we have with Tomcat (standalone mode) is that the
port on which
it listens on is hard coded in server.xml. For various reasons we need
something more
flexible that can be determined in the command line (e.g. -htt_port
80 -ajp_port 8007) so
we plan to write a wrapper around Tomcat startup that will use Velocity to
generate
the server.xml from a template. It would be nice if Tomcat would support
Velocity in the various
configuration files and will allow to use system properties and command line
arguments
as Velocity variables.
Velocity rocks !
Tal
>
> geir
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> Developing for the web? See http://jakarta.apache.org/velocity/
> Be well, do good work, and keep in touch.
>
Re: Documentation bug and more
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Tal Dayan wrote:
>
> The example at
> http://jakarta.apache.org/velocity/user-guide.html#Conditionals
>
> #elseif( $bar = 6 )
>
> seems to be incorrect. For a proper numeric comparison, it should be '=='
> not '='. At
> least this is what we figured our at the end of a long day. Also, the
> following documentation
> regarding the '==' as the identity misled us since it is not the case when
> you compare
> numeric values (which are represented by Integer instances) which means that
> ($foo == 5) is
> different from ($foo == $bar) even if $bar is set to 5. Am I missing
> somthing ?
>
Nope. Thanks. I fixed the typo, and claified the following text.
> This raises again the issue of handling errors in the template.
>
> Velocity seems to be very casual about errors (or at least
> 'misunderstandings') in the template
> which makes it difficult to debug or test new templates. The other case we
> encountered was
> when we the number we used in the comparison was a Long rather than an
> Integer. Between these
> two cases, we (that is, I) spent significant time to figure out what is
> going wrong and had to resort
> to consulting the source code.
Did you consult the log? It should have listed something like -
Tue Jul 24 06:27:26 EDT 2001 [error] Error in evaluation of ==
expression. Both arguments must be of the same Class. Currently left =
class java.lang.Long, right = class java.lang.Integer. tal.vm [line 3,
column 16] (ASTEQNode)
This issue, namely numeric comparison, is something I will get to right
after we come to some conclusion about the separate instance version of
vel that is languishing on my local machine :)
>
> Is there any way to make velocity more helpful in similar situations ? If it
> already spits
> errors or warning to a log file, is it possibly to make them more visible ?
To whom? Log messages, which I would argue are rather descriptive, go
to the log file under [error], so you could always grep for that to
avoid reading through all the goop.
> If it ignore these
> cases, is it possible to make it more strict (even a runtime flag that sets
> the levels or
> errors/warning reporting).
It's *very* strict right now, and logs as such.
> BTW, we are using it from an application, not as a servlet.
>
Cool. What does it do? (I love hearing about the app uses...)
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Documentation bug and more
Posted by Tal Dayan <ta...@zapta.com>.
The example at
http://jakarta.apache.org/velocity/user-guide.html#Conditionals
#elseif( $bar = 6 )
seems to be incorrect. For a proper numeric comparison, it should be '=='
not '='. At
least this is what we figured our at the end of a long day. Also, the
following documentation
regarding the '==' as the identity misled us since it is not the case when
you compare
numeric values (which are represented by Integer instances) which means that
($foo == 5) is
different from ($foo == $bar) even if $bar is set to 5. Am I missing
somthing ?
This raises again the issue of handling errors in the template.
Velocity seems to be very casual about errors (or at least
'misunderstandings') in the template
which makes it difficult to debug or test new templates. The other case we
encountered was
when we the number we used in the comparison was a Long rather than an
Integer. Between these
two cases, we (that is, I) spent significant time to figure out what is
going wrong and had to resort
to consulting the source code.
Is there any way to make velocity more helpful in similar situations ? If it
already spits
errors or warning to a log file, is it possibly to make them more visible ?
If it ignore these
cases, is it possible to make it more strict (even a runtime flag that sets
the levels or
errors/warning reporting).
BTW, we are using it from an application, not as a servlet.
Thanks for a great product,
Tal
Re: Velocity wishlist :-)
Posted by Brian Lloyd-Newberry <ne...@yahoo.com>.
--- Lloyd Llewellyn <su...@twilight-systems.com> wrote:
> Hello - I am new on this list.
>
>
> I'm fairly new to Java and have started using Tomcat and Velocity for
> a
> new project. I really like the template concept, and the "YMTD"
> article
> was right on the money, IMHO.
>
> Having used it a bit, I have some suggestions. I know the way to do
> this is to shut up and contribute code, but I simply don't have the
> resources. I thought I might bring this up to get feedback on
> whether
> these features would be conceptually appropriate for Velocity,
> whether
> or not they are actually implemented:
>
>
> 1) Support for floats - that one had me going for awhile :-) I
> also
> seem to recall some problems with other types, e.g. comparing them to
> literal values and not getting the expected results.
>
I can see this as a partial problem too at the moment. Havn't gotten
bit by it myself thought.
>
> 2) Formatting utilities - I understand the approach is to have the
> developer supply utility objects to the context, but it would be a
> big
> overall labor savings for everyone if a comprehensive set of
> formatting
> facilities could be made available by default to the template
> designers.
> This is a fundamental job of the UI/presentation layer, so it seems
> like
> it would belong. (There may be other common presentation-oriented
> tasks
> that would merit inclusion in a standard set of Velocity template
> designer utility classes...?) Even if this does not belong in
> Velocity
> Proper, it would make a good sub-project.
>
What do you mean by formatting?
>
> 3) Some simple string functions would be handy - I'd like to be able
> to
> inspect substrings:
>
> #if ( #substring($dateText, 1, 3) = "Sat" ||
> #substring($dateText, 1, 3) = "Sun" )
>
> <place special formatting for weekends here>
>
> #end
>
> Otherwise the programmer has to add otherwise unneeded and redundant
> fields to his objects:
>
> public boolean getIsWeekend() {...}
>
>
I have macros wrapping objects put in the context in the code I am
using so that I can do exactly that. If I can survive today without
sleep I will try to get the code contributed tonight. What is the best
way to contribute this kind of code BTW?
> 4) A prototyping tool that would allow the velocity template
> designer
> to define test objects, populate them with data, and then use them to
> render actual web pages. It would be useful for the designer (or
> developer for that matter) to just create some bogus sample objects
> to
> design with. This would allow the designer to play around with the
> structure of the objects a bit, add a field here or there, without
> depending on the programmer who writes the servlets. While I agree
> that
> close cooperation between developer and designer is important, you
> don't want to make the progress of one dependent on the other.
>
>
Got one. I will contribute it. It is bleeding edge and has some work
to be a true tool but it works for me/us.
> BTW, I'd like to make the following philosophical observation:
> Velocity's stated purpose is to keep the programming logic out of the
> presentation. However, by not having the formatting and simple
> inspection (e.g. substring) tools available to template designers, it
> seems to force some presentation tasks onto the programmers.
>
That is a slippery slope though. A great deal of damage can be done
to the MVC seperation by putting some of that functionality on the
presentation side. (That is only my opinion, and YES I did read the
manual... ;} )
>
> Finally, an unrelated question - are there any indications that Sun
> intends to make Velocity a sort of "official" Java tool? Or are they
> married to JSP for presentation?
>
>
> Thanks for listening, and thanks for a great product! It's a big
> help
> as we convert our IIS/COM applications over to Java! :-)
>
>
>
-Brian
=====
Brian S. Lloyd-Newberry
Vertical Learning Curve Solutions
newbeb@yahoo.com
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/