velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claude Brisson" <>
Subject New release : Velosurf 0.8
Date Sat, 18 Oct 2003 04:38:09 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 documentation.

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 logic.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message