+1, then you don't have to upgrade to 1.7-beta1 and edit all your files. Great idea, Barbara!
On Wed, Sep 1, 2010 at 10:30 AM, Barbara Baughman <[email protected]> wrote: > Why not create a template for every .js file, <jsfilename>.vm that has the > line #include("<filename.js>") > > or, to avoid changing the name of the file called by the ResourceLoader, do > some creative file copying, like filename.js copied to filenamev.js > and the filename.js is changed to just have > #include("filenamev.js") > > If the js file is called within a parsed template, the following precludes > parsing: > #include("filename.js") > > Either way, the original js files will not be parsed. > > Easier than redesigning Velocity. > > Barbara Baughman > Systems Analyst > X2157 > > > Nathan Bubna wrote: >> >> On Wed, Sep 1, 2010 at 10:01 AM, White, Tim <[email protected]> wrote: >>> >>> Perhaps, although we'd have to rewrite 100's of .js files to use that >>> syntax. >> >> i don't think there's an easy solution here. you can hack your own >> versions of Velocity/VelocityTools, you can restructure your app to >> not use a dynamic rendering servlet to serve static content, or you >> can adapt your static files to be served through a template parsing >> system. i don't see any other options at this point. >> >>> It may be possible to use Tools 2.x for just this stuff through some >>> clever URL management, but it doesn't look like the 2.x version of VVS >>> bubbles up getContent either... >> >> yeah, i don't know how upgrading your Tools version would help with >> this, nor am i at all convinced that it should give access to >> getContent(). that's just not what it's for, and i'm not motivated to >> put in time to support what i consider bad practice (serving static >> content via Velocity). sorry. :( >> >>> On Sep 1, 2010, at 10:10 AM, Nathan Bubna wrote: >>> >>>> On Wed, Sep 1, 2010 at 9:02 AM, White, Tim <[email protected]> wrote: >>>>> >>>>> Sure. We have 100k+ templates, and a massive setup to use the resource >>>>> loaders to pull things across from numerous locations. >>>>> >>>>> 90% of the time what we're pulling is Velocity templates, but the >>>>> remaining 10% is .js files and such that aren't valid velocity, so they >>>>> break when we try to load them.... >>>> >>>> can you use Engine 1.7-beta1? It has the textblock feature: >>>> >>>> #[[ this is included but not parsed, >>>> so you can put anything here ]]# >>>> >>>> which you can use to keep your javascript from breaking. of course, >>>> this still means a wee bit of parsing overhead and context >>>> construction. but if you are serving static files through the VVS, >>>> then i think you'll just have to live with that. it's designed only >>>> with dynamic files in mind, where #include is the extent of static >>>> support. >>>> >>>>> On Sep 1, 2010, at 9:56 AM, Nathan Bubna wrote: >>>>> >>>>>> Ick. Why run that stuff through the resource loaders at all? This is >>>>>> not really an intended usage of Velocity, so don't be too surprised >>>>>> that there isn't much (anything?) in the way of support for it. I >>>>>> can't currently think of any way to do this via the VVS that doesn't >>>>>> involve hacking a custom build of Velocity. >>>>> >>>>> This communication is the property of Qwest and may contain >>>>> confidential or >>>>> privileged information. Unauthorized use of this communication is >>>>> strictly >>>>> prohibited and may be unlawful. If you have received this >>>>> communication >>>>> in error, please immediately notify the sender by reply e-mail and >>>>> destroy >>>>> all copies of the communication and any attachments. >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> This communication is the property of Qwest and may contain confidential >>> or >>> privileged information. Unauthorized use of this communication is >>> strictly >>> prohibited and may be unlawful. If you have received this communication >>> in error, please immediately notify the sender by reply e-mail and >>> destroy >>> all copies of the communication and any attachments. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
