Without vote rights (just my 2 cents), I agree with Daniel and Jon. IMHO Velocity should stick to that often mentioned principle of being a really simple template tool - NOT a scripting language, or it will be transformed into a JSP-like pumpkin.
Kick that complex stuff to the Java side. If you like scripting, use one of the numerous Java based scripting languages to put your logic into script (I am doing something like that), but keep it out of the template. Have fun, Paulo Gaspar http://www.krankikom.de http://www.ruhronline.de > -----Original Message----- > From: Jon Stevens [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 26, 2001 7:14 PM > > on 11/26/01 9:13 AM, "Daniel Rall" <[EMAIL PROTECTED]> wrote: > > > "Geir Magnusson Jr." <[EMAIL PROTECTED]> writes: > > > >> Hm. This is kinda cool. I can see where we have to change the code to > >> support this - not bad.... Then the proxy will pass in the > default values > >> on invocation if they aren't in the actual VM invocation. > >> > >> The only downside is that this could be damn confusing for > people to read if > >> they aren't familiar with the idea. > > > > I've used scripting languages with APIs like this before. It would be > > a really bad idea to add such extraneous cruft to a templating tool > > like Velocity. > > +1 > > You can achieve the same effect by having your $var return a default value > instead of null. > > #macro (foo $bar) > This is: $bar > #end > > #foo ($var.getString("ack")) > > > public class Var > { > public String getString(String in) > { > try to get data > if (null) > return "default"; > } > } > > I am strongly -1 on adding that 'enhancement' idea to the #macro > functionality. Now I just get to wait for all of you to flame me for being > -1 on yet another thing. Sigh. > > -jon > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
