0 Replies Latest reply on Sep 9, 2005 1:37 PM by starksm64

    Need another round of velocity hacking, maybe replacement

    starksm64

      So I'm completely unhappy with the hacking I did on velocity to try to work around its overly promisicuous parsing of things that look like variable references. The three problems that exist are:

      - velocity does not have a way to escape a ${...} expression. Once it sees the $ it will try to parse the {...} according to its notions of what a variable expression syntax should be. All I have done so far is allow ${x,y:default} to be a valid variable syntax.

      - The $x constructs still have problems. One example is a cvs $Id:$ reference inside of an xml comment block in a *-service.xml will cause velocity to barf. What I would like to have is a new #{...} variable reference syntax and a mode to ignore all $x and ${x} references. The #{...} syntax would allow escaping, and use a jsf VariableResolver like delegation of the actual interpretation of the "..." to the resolver. The problem with this is that all existing velocity macros would have to be rewritten to use the new variable syntax.

      - The build for velocity is totally screwed up. The parser that is generated from the javacc .jjt grammar file uses package names that don't match the current ast nodes, and the existing nodes have been modified post generation. This makes introducing semantic parsing changes at the node level undoable. For this reason alone I'm tempted to ditch velocity in favor of something we can actually modify (like FreeMarker) without having to do backflips. The only way we can go forward with velocity is to fix its build such that the parser can be regenerated from the grammar everytime as part of the build.