velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claude Brisson" <>
Subject New release anouncement : Velosurf 0.8 is out !
Date Fri, 17 Oct 2003 22:54:12 GMT
The 0.8 release of Velosurf is out. This release adds support for transactions : actions can
now be composed of several consecutive queries. Many additions have also been made to the

Check the homepage at

** What is Velosurf ?

Velosurf is a database access tool for the Velocity template engine. It is meant for ease-of-use,
genericity and efficiency.

Velosurf main features are :

 - dynamic mapping : no need to recompile on any database change 
 - sql queries appear as standard VTL properties 
 - easy VTL grammar 
 - automatic connection recovery 
 - statements pools 
 - very simple xml configuration file 
 - automatic reverse engeenering of database schema   
 - natural type mapping 
 - concurrent accesses 
 - transactions 
 - soft caching 
 - custom overloading of mapping java objects allowed 

Velosurf can be used as a standard Velocity tool, like in frameworks that use the Velocity
Tools subproject (a great architectural component allowing re-usable tools to be easily plugged
in web-applications).

** Why Velosurf ?

The main goal of Velosurf is to avoid the pain of rewriting specific database mapping layers
in java for each project involving velocity and database entities that template writers have
to deal with. It is also meant to have a clean separation between SQL, java and VTL.

Persistence solutions are hard to design and maintain, and are not anymore so much pertinent
with today computers speed. So why not have a thin and generic mapping engine that will fetch
on demand needed values directly from the database ? This is what Velosurf does, also allowing
properties of mapping objects to be complex queries as long as column values, a functionnality
hardly reachable by persistence solutions.

Last but not least : We, the developers, often try to proctect users from many concepts that
may appear too complex or weird to them. But even if a data model is complex, its complexity
has nothing or few to do with technical constraints, rather with logic and modelisation constraints.
To my mind, those constraints should be shared and exposed to all people involved in a project
- like designers - who are as competent as us ("Who said 'More ?' ") to deal with business


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message