velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Finkelstein <dan.finkelst...@emind.com>
Subject Re: Parsing error... ?#~
Date Fri, 13 Jul 2001 22:46:39 GMT
Wow, that was indeed the problem -- it had caught me unawares....

Funny enough, our code was originally implemented with the

         velocimacro.library = <library1>,<library2>,<library3>...

construct, but the Velocity singleton limitation forced me to be "creative" 
and I moved to using the #parse construct -- unfortunately, I butted up 
against this unexpected side-effect.   At least now I know... :)

Thanks for all your insights...

Take care,
Dan

At 11:59 PM 7/11/01 -0400, you wrote:
>Dan Finkelstein wrote:
> >
> > I'm not sure what to try next so I thought I'd bounce this weirdness off
> > you guys...
>
>Oh no... I hate wierdness.
>
> >
> > Our system goes through a bunch of velocity templates and processes
> > them.  When it gets to one, it generates this error:
> >
> >    7 of 21: C:/projects/gusa/builds/common/b0/templates/Wrapup.html
> > Velocity Parsing error:
> >          Message...Encountered "/" at line 67, column 25.
> > Was expecting one of:
>
>[SNIP]
>
> > so I think the line numbers are off.  Anyway, this file does use a macro,
> > #OutputParagraphs(string), which is stored in a library file and accessed
> > as follows from the first line of the template:
> >
> >         #parse ("build/common/b0/templates/include/preprocessorLibrary.vm")
> >
>
>Ah ha.
>
> > If I paste in the contents of this library into the template, replacing the
> > #parse line, velocity processes the file without an error.  I don't know
> > what the differences are between calling a macro "in-line" vs. through a
> > parsed file...
>
>You can't parse in a VM definition like this.  Why?  Because #parse() is
>a run-time thing, and the binding of VMs in the template happens at
>parse time.  So the VMs have to be registered before parsing the
>template. (It's something I'm working on...).
>
> > The final observation I have is that in our system we have something like a
> > "make", where only changed files are processed by velocity.  When we do a
> > "make all" this error doesn't occur.  It only occurs, it we change the
> > template file (that being one only file needing to process) and then run
> > "make".  It's as thought something has "primed" velocity in the "make all"
> > situation...
>
>This is consistant with the above #parse() problem.
>
>Solution?  Well, looking at it, it seems that the preprocessorLibrary.vm
>isn't local to that template.  So you can simply have velocity read it
>and register the VMs at startup using the configuration key
>
>velocimacro.library = <library1>,<library2>,<library3>...
>
>in your velocity.properties (or however you configure the runtime...)
>
>(so yes, you can specify multiple libraries to be read in...)
>
>Does that help?
>
>geir
>
>--
>Geir Magnusson Jr.                           geirm@optonline.net
>System and Software Consulting
>Developing for the web?  See http://jakarta.apache.org/velocity/
>You have a genius for suggesting things I've come a cropper with!

Dan Finkelstein
Senior Architect, Instructional Tools & Technology
eMind LLC
Northern California Annex
1250 Addison St, Suite #210
Berkeley, CA 94702-1700
Tel: (510) 486-2740
Fax: (510)486-2843

Visit us at <http://www.emind.com/>

This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message.


Mime
View raw message