You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Claude Brisson <cl...@savoirweb.com> on 2003/10/18 06:38:09 UTC

New release : Velosurf 0.8

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 http://velosurf.sourceforge.net

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

CloD



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