Using Velocity only for scripting purposes

[MS79 <sh...@gmail.com>]

The application I'm working on currently uses Velocity for simple template
processing; some forms, extract data, etc.  

In response to trying to meet a business need of a client, it was proposed
that we use Velocity basically as an engine to allow users of the system to
write custom logic in the system.  This include statement logic and setting
values on objects passed it (which would later be persisted to a database). 
No actual template processing would be done, it is essentially only used to
set values on an object. 

While it would (and in fact, does) work, it just feels horribly wrong,
especially when we have another engine hooked into the system to allow
custom rule writing.  Am I just being overly sensitive to the use of
Velocity here, or are there any other downfalls that this implementation may
have that we should be aware of.  

Volume is supposed to be fairly low (at least as far as I've been told) and
the templates would not be very complex.

Thanks,
Mark
-- 
View this message in context: http://www.nabble.com/Using-Velocity-only-for-scripting-purposes-tp22935096p22935096.html
Sent from the Velocity - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: Using Velocity only for scripting purposes

[MS79 <sh...@gmail.com>]

Byron Foster-2 wrote:
> 
> 
> However, I realize these decisions are more often political then  
> technical, so good luck to you!
> 
> 

This is probably one of the bigger things we've run into.  Since none of the
people on the technical side of the project agreed with the decision.  I
think we've convinced them to go with a stored procedure route to do the
data updating.  Not as user friendly either, but they have DBAs, and will be
a heck of a lot faster than individual Hibernate updates.

Thanks for all the responses.  Good to know I'm actually not crazy :)
-- 
View this message in context: http://www.nabble.com/Using-Velocity-only-for-scripting-purposes-tp22935096p22956836.html
Sent from the Velocity - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: Using Velocity only for scripting purposes

[Byron Foster <by...@base2.cc>]

On Apr 7, 2009, at 13:06 , Nathan Bubna wrote:

>> While it would (and in fact, does) work, it just feels horribly  
>> wrong,
>> especially when we have another engine hooked into the system to  
>> allow
>> custom rule writing.  Am I just being overly sensitive to the use of
>> Velocity here, or are there any other downfalls that this  
>> implementation may
>> have that we should be aware of.
>
> that would feel quite wrong to me too.  Velocity is for templates, not
> scripting.  Using VTL as a scripting language is like trying to pound
> in a nail with a screwdriver.  It might work, but it ain't a good way
> to get the job done.

Especially when there are such great solutions for this type of thing  
available on the JVM, the big ones being Jython, JRuby, Rhino,  
Groovy...  In all of these

foo.name = "bar"

Does the same thing, which is cleaner then

#set($foo.name = "bar")

However, I realize these decisions are more often political then  
technical, so good luck to you!


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: Using Velocity only for scripting purposes

[ap...@recks.org]

VTL is not a good scripting language, apart from the fact that the code will tend to be unreadable - it is also difficult to debug (even though during developing time it is easy to add some random tracing output into the templates, in a production environment it is very hard to track problems).

The upside of using VTL for template and for scripting is that its one syntax to learn.

A few years ago I setup a web framework with pluggable templates that acted partly as the controller and workflow engine - it scripted DB, socket and commandline calls, populated the context and included several rendering templates (for different types of object and parts of the pages). Some pages even setup background threads and fed progress monitoring web output! The major downside was the difficulty to debug.

If you have other workflow capabilities, I recommend to setup your architecture to work without VTL scripting...

Good luck!
Christoph

Nathan Bubna wrote:
> On Tue, Apr 7, 2009 at 11:17 AM, MS79 <sh...@gmail.com> wrote:
>> The application I'm working on currently uses Velocity for simple template
>> processing; some forms, extract data, etc.
>>
>> In response to trying to meet a business need of a client, it was proposed
>> that we use Velocity basically as an engine to allow users of the system to
>> write custom logic in the system.  This include statement logic and setting
>> values on objects passed it (which would later be persisted to a database).
>> No actual template processing would be done, it is essentially only used to
>> set values on an object.
> 
> ugh.
> 
>> While it would (and in fact, does) work, it just feels horribly wrong,
>> especially when we have another engine hooked into the system to allow
>> custom rule writing.  Am I just being overly sensitive to the use of
>> Velocity here, or are there any other downfalls that this implementation may
>> have that we should be aware of.
> 
> that would feel quite wrong to me too.  Velocity is for templates, not
> scripting.  Using VTL as a scripting language is like trying to pound
> in a nail with a screwdriver.  It might work, but it ain't a good way
> to get the job done.
> 
>> Volume is supposed to be fairly low (at least as far as I've been told) and
>> the templates would not be very complex.
> 
> You say that now, but plans change.  Shortcuts like this tend to hurt
> in the long run.  You'll still use more memory than you need to, maybe
> more CPU too. And you'll definitely be working with a "crippled"
> scripting language, so your "scripts" are likely to end up ugly and
> hard to maintain despite your intentions.
> 
>> Thanks,
>> Mark
>> --
>> View this message in context: http://www.nabble.com/Using-Velocity-only-for-scripting-purposes-tp22935096p22935096.html
>> Sent from the Velocity - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
>> For additional commands, e-mail: user-help@velocity.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org

Re: Using Velocity only for scripting purposes

[Nathan Bubna <nb...@gmail.com>]

On Tue, Apr 7, 2009 at 11:17 AM, MS79 <sh...@gmail.com> wrote:
>
> The application I'm working on currently uses Velocity for simple template
> processing; some forms, extract data, etc.
>
> In response to trying to meet a business need of a client, it was proposed
> that we use Velocity basically as an engine to allow users of the system to
> write custom logic in the system.  This include statement logic and setting
> values on objects passed it (which would later be persisted to a database).
> No actual template processing would be done, it is essentially only used to
> set values on an object.

ugh.

> While it would (and in fact, does) work, it just feels horribly wrong,
> especially when we have another engine hooked into the system to allow
> custom rule writing.  Am I just being overly sensitive to the use of
> Velocity here, or are there any other downfalls that this implementation may
> have that we should be aware of.

that would feel quite wrong to me too.  Velocity is for templates, not
scripting.  Using VTL as a scripting language is like trying to pound
in a nail with a screwdriver.  It might work, but it ain't a good way
to get the job done.

> Volume is supposed to be fairly low (at least as far as I've been told) and
> the templates would not be very complex.

You say that now, but plans change.  Shortcuts like this tend to hurt
in the long run.  You'll still use more memory than you need to, maybe
more CPU too. And you'll definitely be working with a "crippled"
scripting language, so your "scripts" are likely to end up ugly and
hard to maintain despite your intentions.

> Thanks,
> Mark
> --
> View this message in context: http://www.nabble.com/Using-Velocity-only-for-scripting-purposes-tp22935096p22935096.html
> Sent from the Velocity - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
> For additional commands, e-mail: user-help@velocity.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@velocity.apache.org
For additional commands, e-mail: user-help@velocity.apache.org