You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2002/01/08 05:33:29 UTC
Re: VelocityDOMContext
On 1/7/02 11:34 PM, "Donnie Hale" <do...@haleonline.net> wrote:
> I looked around for something like this in the javadocs and the most recent
> CVS stuff but didn't see anything (probably blind :).
>
> Has anyone developed an XML and/or DOM-tree version of a VelocityContext? It
> wouldn't really care about what was in the XML, though it could of course
> validate it against a DTD or whatever. The idea, obviously, is that I could
> refer to any piece of the DOM tree in a template (given enough '.'
> characters :).
Did a riff on that idea a while ago : look at the XMLEasyBean in contrib
>
> I've thought about this before, but I have a concrete use for it now. Here's
> what I'm trying to achieve. On a fairly large project for which I am
> defining and implementing all elements of the build, staging, & deployment
> procedures, there are lots of "magic numbers" (e.g. port assignments for the
> different environments) and "magic strings" (e.g. JDBC URLs, relative
> directory locations, .jar file names, etc.). These magic values are
> referenced in various places throughout the elements that make up a complete
> deployment package (as opposed to magic values in source code). This
> includes: the ant build script; manifest files; shell scripts; property
> files; deployment descriptors; etc.
>
> In trying to obey "DRY" (don't repeat yourself - see the terrific recent
> book "The Pragmatic Programmer" if you haven't already), I'd like to
> centralize all those values into a single place. The book discusses
> generation tools, rolling your own, etc. Naturally, xml was a choice for
> storing all the values. But how to take those values and easily stick them
> in all those various file formats. The "ahaa!" went off today - Velocity!
> (Yeah - I'm slow. I know. :)
>
> So now I can create this somewhat large .xml file with all of these values.
> But how do I turn that into something that my "manifest.mf.vm" and
> "deploy.vm" templates use. A "VelocityDOMContext" or some such would seem to
> be appropriate. Thus my question.
Like
$data.network.url.jdbc
?
Try the XMLEasyBean. Will prollie move to tools now that we have it.
> One more related question: Ant build scripts are chock full of "${stuff}"
> text snippets. How in the world would I parameterize some of those in a
> "build.xml.vm" Velocity template? Or maybe I'm just better off putting that
> stuff in a .properties file that's read at the beginning of my build.xml
> script.
The latter is popular
> Thanks,
>
> Donnie
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: VelocityDOMContext
Posted by Donnie Hale <do...@haleonline.net>.
Geir,
Didn't expect it in a .jar file, but I found it. Thanks.
It looks like it's pretty close to what I want. The significant difference
is that I'd like it to use DOM rather than SAX. The main reason for that is
so that I could construct the XMLEasyBeanNodes via a DOM tree as well as
from an XML file. The other thing that would be nice, though I don't know if
it's possible, is to be able to refer to an element's attributes via
$element.attrname rather than $element.getAttribute('attrname'). Is that
feasible? Is there a way to make things smart enough that the context can
try for an attribute if it's the string after the last '.'?
Thanks again,
Donnie
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Tuesday, January 08, 2002 12:10 AM
> To: velocity-user@jakarta.apache.org
> Subject: Re: VelocityDOMContext
>
>
> On 1/8/02 12:09 AM, "Donnie Hale" <do...@haleonline.net> wrote:
>
> > Is XMLEasyBean supposed to be under the "contrib" directory in the most
> > recent head revisions? If so, I don't see it in what I've
> gotten (I think I
> > did a checkout on Saturday). ???
>
> No, I'm just tired today.
>
> Sorry - it's in the whiteboard/geir/xmleb directory
>
> It's been there a while.
>
> It's pretty basic - was more of a proof of concept. See what you think.
>
> >
> > If I can find it, I'll definitely take a look.
> >
> > Thanks,
> >
> > Donnie
> >
> >
> >> -----Original Message-----
> >> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> >> Sent: Monday, January 07, 2002 11:33 PM
> >> To: velocity-user@jakarta.apache.org
> >> Subject: Re: VelocityDOMContext
> >>
> >>
> >> On 1/7/02 11:34 PM, "Donnie Hale" <do...@haleonline.net> wrote:
> >>
> >>> I looked around for something like this in the javadocs and the
> >> most recent
> >>> CVS stuff but didn't see anything (probably blind :).
> >>>
> >>> Has anyone developed an XML and/or DOM-tree version of a
> >> VelocityContext? It
> >>> wouldn't really care about what was in the XML, though it could
> >> of course
> >>> validate it against a DTD or whatever. The idea, obviously, is
> >> that I could
> >>> refer to any piece of the DOM tree in a template (given enough '.'
> >>> characters :).
> >>
> >> Did a riff on that idea a while ago : look at the XMLEasyBean
> in contrib
> >>
> >>>
> >>> I've thought about this before, but I have a concrete use for
> >> it now. Here's
> >>> what I'm trying to achieve. On a fairly large project for which I am
> >>> defining and implementing all elements of the build, staging, &
> >> deployment
> >>> procedures, there are lots of "magic numbers" (e.g. port
> >> assignments for the
> >>> different environments) and "magic strings" (e.g. JDBC URLs, relative
> >>> directory locations, .jar file names, etc.). These magic values are
> >>> referenced in various places throughout the elements that make
> >> up a complete
> >>> deployment package (as opposed to magic values in source code). This
> >>> includes: the ant build script; manifest files; shell
> scripts; property
> >>> files; deployment descriptors; etc.
> >>>
> >>> In trying to obey "DRY" (don't repeat yourself - see the
> terrific recent
> >>> book "The Pragmatic Programmer" if you haven't already), I'd like to
> >>> centralize all those values into a single place. The book discusses
> >>> generation tools, rolling your own, etc. Naturally, xml was a
> choice for
> >>> storing all the values. But how to take those values and easily
> >> stick them
> >>> in all those various file formats. The "ahaa!" went off today -
> >> Velocity!
> >>> (Yeah - I'm slow. I know. :)
> >>>
> >>> So now I can create this somewhat large .xml file with all of
> >> these values.
> >>> But how do I turn that into something that my "manifest.mf.vm" and
> >>> "deploy.vm" templates use. A "VelocityDOMContext" or some such
> >> would seem to
> >>> be appropriate. Thus my question.
> >>
> >> Like
> >>
> >> $data.network.url.jdbc
> >>
> >> ?
> >>
> >> Try the XMLEasyBean. Will prollie move to tools now that we have it.
> >>
> >>> One more related question: Ant build scripts are chock full of
> >> "${stuff}"
> >>> text snippets. How in the world would I parameterize some of
> those in a
> >>> "build.xml.vm" Velocity template? Or maybe I'm just better off
> >> putting that
> >>> stuff in a .properties file that's read at the beginning of
> my build.xml
> >>> script.
> >>
> >> The latter is popular
> >>
> >>> Thanks,
> >>>
> >>> Donnie
> >>>
> >>>
> >>> --
> >>> To unsubscribe, e-mail:
> >>> <ma...@jakarta.apache.org>
> >>> For additional commands, e-mail:
> >>> <ma...@jakarta.apache.org>
> >>>
> >>
> >> --
> >> Geir Magnusson Jr.
> geirm@optonline.net
> >> System and Software Consulting
> >> "Now what do we do?"
> >>
> >>
> >> --
> >> To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> "Now what do we do?"
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: VelocityDOMContext
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 1/8/02 12:09 AM, "Donnie Hale" <do...@haleonline.net> wrote:
> Is XMLEasyBean supposed to be under the "contrib" directory in the most
> recent head revisions? If so, I don't see it in what I've gotten (I think I
> did a checkout on Saturday). ???
No, I'm just tired today.
Sorry - it's in the whiteboard/geir/xmleb directory
It's been there a while.
It's pretty basic - was more of a proof of concept. See what you think.
>
> If I can find it, I'll definitely take a look.
>
> Thanks,
>
> Donnie
>
>
>> -----Original Message-----
>> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
>> Sent: Monday, January 07, 2002 11:33 PM
>> To: velocity-user@jakarta.apache.org
>> Subject: Re: VelocityDOMContext
>>
>>
>> On 1/7/02 11:34 PM, "Donnie Hale" <do...@haleonline.net> wrote:
>>
>>> I looked around for something like this in the javadocs and the
>> most recent
>>> CVS stuff but didn't see anything (probably blind :).
>>>
>>> Has anyone developed an XML and/or DOM-tree version of a
>> VelocityContext? It
>>> wouldn't really care about what was in the XML, though it could
>> of course
>>> validate it against a DTD or whatever. The idea, obviously, is
>> that I could
>>> refer to any piece of the DOM tree in a template (given enough '.'
>>> characters :).
>>
>> Did a riff on that idea a while ago : look at the XMLEasyBean in contrib
>>
>>>
>>> I've thought about this before, but I have a concrete use for
>> it now. Here's
>>> what I'm trying to achieve. On a fairly large project for which I am
>>> defining and implementing all elements of the build, staging, &
>> deployment
>>> procedures, there are lots of "magic numbers" (e.g. port
>> assignments for the
>>> different environments) and "magic strings" (e.g. JDBC URLs, relative
>>> directory locations, .jar file names, etc.). These magic values are
>>> referenced in various places throughout the elements that make
>> up a complete
>>> deployment package (as opposed to magic values in source code). This
>>> includes: the ant build script; manifest files; shell scripts; property
>>> files; deployment descriptors; etc.
>>>
>>> In trying to obey "DRY" (don't repeat yourself - see the terrific recent
>>> book "The Pragmatic Programmer" if you haven't already), I'd like to
>>> centralize all those values into a single place. The book discusses
>>> generation tools, rolling your own, etc. Naturally, xml was a choice for
>>> storing all the values. But how to take those values and easily
>> stick them
>>> in all those various file formats. The "ahaa!" went off today -
>> Velocity!
>>> (Yeah - I'm slow. I know. :)
>>>
>>> So now I can create this somewhat large .xml file with all of
>> these values.
>>> But how do I turn that into something that my "manifest.mf.vm" and
>>> "deploy.vm" templates use. A "VelocityDOMContext" or some such
>> would seem to
>>> be appropriate. Thus my question.
>>
>> Like
>>
>> $data.network.url.jdbc
>>
>> ?
>>
>> Try the XMLEasyBean. Will prollie move to tools now that we have it.
>>
>>> One more related question: Ant build scripts are chock full of
>> "${stuff}"
>>> text snippets. How in the world would I parameterize some of those in a
>>> "build.xml.vm" Velocity template? Or maybe I'm just better off
>> putting that
>>> stuff in a .properties file that's read at the beginning of my build.xml
>>> script.
>>
>> The latter is popular
>>
>>> Thanks,
>>>
>>> Donnie
>>>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>
>> --
>> Geir Magnusson Jr. geirm@optonline.net
>> System and Software Consulting
>> "Now what do we do?"
>>
>>
>> --
>> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
"Now what do we do?"
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: VelocityDOMContext
Posted by Donnie Hale <do...@haleonline.net>.
Is XMLEasyBean supposed to be under the "contrib" directory in the most
recent head revisions? If so, I don't see it in what I've gotten (I think I
did a checkout on Saturday). ???
If I can find it, I'll definitely take a look.
Thanks,
Donnie
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Monday, January 07, 2002 11:33 PM
> To: velocity-user@jakarta.apache.org
> Subject: Re: VelocityDOMContext
>
>
> On 1/7/02 11:34 PM, "Donnie Hale" <do...@haleonline.net> wrote:
>
> > I looked around for something like this in the javadocs and the
> most recent
> > CVS stuff but didn't see anything (probably blind :).
> >
> > Has anyone developed an XML and/or DOM-tree version of a
> VelocityContext? It
> > wouldn't really care about what was in the XML, though it could
> of course
> > validate it against a DTD or whatever. The idea, obviously, is
> that I could
> > refer to any piece of the DOM tree in a template (given enough '.'
> > characters :).
>
> Did a riff on that idea a while ago : look at the XMLEasyBean in contrib
>
> >
> > I've thought about this before, but I have a concrete use for
> it now. Here's
> > what I'm trying to achieve. On a fairly large project for which I am
> > defining and implementing all elements of the build, staging, &
> deployment
> > procedures, there are lots of "magic numbers" (e.g. port
> assignments for the
> > different environments) and "magic strings" (e.g. JDBC URLs, relative
> > directory locations, .jar file names, etc.). These magic values are
> > referenced in various places throughout the elements that make
> up a complete
> > deployment package (as opposed to magic values in source code). This
> > includes: the ant build script; manifest files; shell scripts; property
> > files; deployment descriptors; etc.
> >
> > In trying to obey "DRY" (don't repeat yourself - see the terrific recent
> > book "The Pragmatic Programmer" if you haven't already), I'd like to
> > centralize all those values into a single place. The book discusses
> > generation tools, rolling your own, etc. Naturally, xml was a choice for
> > storing all the values. But how to take those values and easily
> stick them
> > in all those various file formats. The "ahaa!" went off today -
> Velocity!
> > (Yeah - I'm slow. I know. :)
> >
> > So now I can create this somewhat large .xml file with all of
> these values.
> > But how do I turn that into something that my "manifest.mf.vm" and
> > "deploy.vm" templates use. A "VelocityDOMContext" or some such
> would seem to
> > be appropriate. Thus my question.
>
> Like
>
> $data.network.url.jdbc
>
> ?
>
> Try the XMLEasyBean. Will prollie move to tools now that we have it.
>
> > One more related question: Ant build scripts are chock full of
> "${stuff}"
> > text snippets. How in the world would I parameterize some of those in a
> > "build.xml.vm" Velocity template? Or maybe I'm just better off
> putting that
> > stuff in a .properties file that's read at the beginning of my build.xml
> > script.
>
> The latter is popular
>
> > Thanks,
> >
> > Donnie
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
> Geir Magnusson Jr. geirm@optonline.net
> System and Software Consulting
> "Now what do we do?"
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>