On Jan 25, 2008 10:15 AM, Claude Brisson <[EMAIL PROTECTED]> wrote:
> Very interesting work!
ditto! will you open a JIRA issue open so we can start easily sharing
code and tracking these ideas in one place?
> About the different alternatives - none of them really pleases me.
> There's another option: not allowing block macros to be used before they
> are defined. Okay, you cannot make crossed reflexivity with block macros
> without... is it such a big deal?
I dunno. I think discouraging the use of block macros prior to
registering them in combination with having option #4 (the prefix)
available for those who say "but i NEED it!" seems tolerable to me.
We could just state in the documentation that we "strongly recommend
you define your block macros globally in a velocimacro library" or
something like that. I don't think, though, that we need to bother
have the prefix be configurable. It's already confusing enough that
we would need one, without making it worse by having it vary from user
to user.
>
> Claude
>
> Le jeudi 24 janvier 2008 à 19:53 -0500, Raghu Rajah a écrit :
>
> > Apologies for a delayed response on this thread. Was buried in some work for
> > the past couple of weeks. Was able to spend some time on this past couple of
> > days. Here's what I have,
> >
> > I have a working version of the blockmacro as discussed in this thread.
> > Patch attached. Here's the trivial example,
> >
> > #blockmacro(html $style)
> > <html style="$style">
> > ${yield}
> > </html>
> > #end
> >
> >
> > Block Macro Result
> > #html("color:red")
> > <body>Raghu</body>
> > #end
> >
> > In broad brush strokes, here's what I did,
> >
> >
> > - Modified the grammar to look for blockmacro and register just like the
> > regular macro would.
> > - Created a new proxy for this and dealt with creating this one for block
> > macros.
> >
> > I am yet to finish up some things,
> >
> > - Making yield variable configurable
> > - want to make the proxy class interceptable (I need this ability to
> > intercept and manipulate content)
> > - the default templatetests doesn't seem to be comparing with the cmps. Is
> > there something I need to do special to make this work. If I replace the
> > content of any existing content with garbage, the tests still pass. Would
> > appreciate help in pointing me in the right direction here.
> > - refactor my current tests to be in alignment with other tests within the
> > project and add more complex tests.
> >
> > Bumped in to a catch though,
> >
> > - If the block macro is used before it is declared, I would have no idea if
> > the macro is a LINE one or a BLOCK one. Currently, I am defaulting to LINE
> > which will make template parsing fail. There are four alternatives, I can
> > think of,
> >
> > OPTION-1: Put a 'do' after my parameters.
> >
> > #html("something") do
> > #end
> >
> > Of course, 'do' could be optional, if html is defined already. The bad thing
> > about this is it introduces new language semantics into VTL
> >
> > OPTION-2: Create a call semantic for blockmacros
> >
> > #callBlockMacro (html "something")
> > #end
> >
> > Again the callBlockMacro is optional, if you have defined html already.
> >
> > OPTION-3:Forward declaration for block macros.
> >
> > #forwardBlock html
> > #forwardLine strong
> >
> > OPTION-4 (My preference): A configurable convention on prefix & suffix
> > (thank you, Conor, for the suggestion)
> >
> > Blockmacro.default.prefix = _
> >
> > Recommendations, alternate suggestions, would be appreciated.
> >
> > Thanks,
> > Raghu.
> >
> >
> >
>
> > On 1/7/08 11:48 AM, "Will Glass-Husain" <[EMAIL PROTECTED]> wrote:
> >
> > > Not quite sure if I follow how this would work. I'm guessing you'll
> > > have to do some tricks with the parser nodes to make this work (since
> > > at parse time the repository of macros is not yet defined). There's
> > > probably a couple of ways of structuring this.
> > >
> > > Look forward to seeing some code. Thanks again for your interest in
> > > contributing!
> > >
> > > WILL
> > >
> > > On Jan 7, 2008 8:35 AM, Claude Brisson <[EMAIL PROTECTED]> wrote:
> > >> That does make sense. Thanks.
> > >>
> > >>> Since I would have the
> > >>> repository of the defined velocimacros already, I can easily determine
> > >>> if
> > >>> the current macro is a block.
> > >>
> > >> That is the specific point I was missing in your approach. Looks totally
> > >> feasible.
> > >>
> > >>
> > >> Claude
> > >>
> > >> Le lundi 07 janvier 2008 à 10:29 -0500, Raghu Rajah a écrit :
> > >>
> > >>> Maybe we are talking two different things.
> > >>>
> > >>> 1. I don't intend to distinguish the content variable (yield or
> > >>> bodyContent)
> > >>> from any other reference. It is just another reference as far as the
> > >>> parser
> > >>> is concerned. The only variation is in the proxy directive, which would
> > >>> wrap
> > >>> the context to add the capability to yield (trap get on "yield" and
> > >>> render
> > >>> content in-place).
> > >>>
> > >>> 2. I did not intend to add the block-macros as part of the parsing
> > >>> environment. The parser will treat the block macro usage as yet another
> > >>> velocimacro, this one just happens to be a block. Since I would have the
> > >>> repository of the defined velocimacros already, I can easily determine
> > >>> if
> > >>> the current macro is a block. All the Parser does here is to add the
> > >>> content
> > >>> as the child of the current AST, as opposed to a peer.
> > >>>
> > >>> 3. The real problem is to distinguish during definition if a macro is a
> > >>> block-macro or a single-line one. Since there is no begin syntax for the
> > >>> block I (as the parser) won't know for sure if the next line is a
> > >>> beginning
> > >>> of a block or simply another peer node. Which is why I need a new
> > >>> directive
> > >>> "#block"
> > >>>
> > >>> Does this make sense? Let me know what you feel about this.
> > >>>
> > >>> Raghu.
> > >>>
> > >>>
> > >>> On 1/7/08 9:52 AM, "Claude Brisson" <[EMAIL PROTECTED]> wrote:
> > >>>
> > >>>> Le lundi 07 janvier 2008 à 07:34 -0500, Raghu Rajah a écrit :
> > >>>>> Actually, I was saying the opposite. We can keep the calling
> > >>>>> semantics, as
> > >>>>> is. I might have to use an alternate directive (other than #macro) for
> > >>>>> definition.
> > >>>>> The definition parsing would become non-deterministic otherwise
> > >>>>
> > >>>> I don't agree, or maybe I don't understand. In the definition code,
> > >>>> block macros [may] make use of a specific reference that contains the
> > >>>> block itself. At parsing time, nothing makes this reference different
> > >>>> from the others, that is, $yield or $bodyContent or whatever you call
> > >>>> it
> > >>>> is just a reference with no specific meaning from the parser point of
> > >>>> view. How comes you would want to introduce a difference here? Why do
> > >>>> you see it as introducing a non-deterministic behaviour?
> > >>>>
> > >>>>> We already have block handling for directives within the parser
> > >>>>> grammar,
> > >>>>> that I can overload for handling block macro usage as well.
> > >>>>
> > >>>> Standard and custom directives, that alter the behaviour of the parser,
> > >>>> are defined prior to any parsing. We shall call this the parsing
> > >>>> environment. Macros are not part of this environment since they are
> > >>>> defined in parsed files. What I do call determinism in this context is
> > >>>> the fact that in a specific parsing environment, every file can be
> > >>>> parsed independantly from the others.
> > >>>>
> > >>>> I may be wrong but I think that your proposal implies that block
> > >>>> directives be defined only in a preloaded velocimacro library,
> > >>>> conceptually making the library part of the parsing environment if you
> > >>>> want to be able to state that the parsing is deterministic. it means
> > >>>> that block macros cannot be defined inline. I'm not stricly opposed to
> > >>>> it, but I think it'd be easier to use an alternate syntax so that block
> > >>>> macro definitions don't have to be predefined prior to the parsing
> > >>>> stage, and can be defined inline.
> > >>>>
> > >>>>
> > >>>> Claude
> > >>>>
> > >>>>> On Will's suggestion, I personally would prefer to keep the calling
> > >>>>> semantics between #macro and #blockmacro (or #block) the same. That
> > >>>>> would
> > >>>>> give us interesting opportunities to genericize the VTL language in
> > >>>>> the
> > >>>>> future (if we can address the block-breaking structure like elseif)
> > >>>>> and
> > >>>>> perhaps provide support for alternate DSLs.
> > >>>>>
> > >>>>> I prefer "yield" too. I will stick with that for the moment. Should
> > >>>>> be an
> > >>>>> easy one to change if there is disagreement over it
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Raghu.
> > >>>>>
> > >>>>> On 1/7/08 6:22 AM, "Claude Brisson" <[EMAIL PROTECTED]> wrote:
> > >>>>>
> > >>>>>> Yes, Raghu, I'm "+1" if we find a mean of implementing it and agree
> > >>>>>> about the syntax.
> > >>>>>>
> > >>>>>> It's the use of the macro that should be differenciated between block
> > >>>>>> and non-block versions, not definition (for definition, I guess we
> > >>>>>> can
> > >>>>>> keep #macro), for the parsing process to be deterministic.
> > >>>>>>
> > >>>>>> It looks like using a special directive to call the macro -as Will
> > >>>>>> suggests- is the only way to go. And yes, block macros should having
> > >>>>>> both a body and (a variable number of) arguments.
> > >>>>>>
> > >>>>>> #call? #block? #blockmacro? I like #block.
> > >>>>>>
> > >>>>>> #block(onemacro) without arg #end
> > >>>>>> #block(anothermacro,$arg1) only one arg #end
> > >>>>>> #block(themacro,$arg1,$arg2) etc... #end
> > >>>>>>
> > >>>>>> Concerning the name of the reference holding the body: it should
> > >>>>>> anyway
> > >>>>>> be made configurable. $bodyContent looks heavier than $yield but much
> > >>>>>> more explicit.
> > >>>>>>
> > >>>>>> Claude
> > >>>>>>
> > >>>>>> Le dimanche 06 janvier 2008 à 21:18 -0800, Will Glass-Husain a écrit
> > >>>>>> :
> > >>>>>>> I like this idea. Similar to JSP tags that have attributes and
> > >>>>>>> body.
> > >>>>>>>
> > >>>>>>> Question--- would a block macro be able to have both arguments and a
> > >>>>>>> body? I'd think this would be useful.
> > >>>>>>>
> > >>>>>>> Second, to clarify Claude's point about the difficulty. The issue
> > >>>>>>> is
> > >>>>>>> that the parser needs to call the block-macro, but since the actual
> > >>>>>>> macro is defined at run-time, the parser doesn't know whether to
> > >>>>>>> call
> > >>>>>>> a regular macro (no #end required) a block macro (needs an end) or
> > >>>>>>> just pass through verbatim (e.g. not defined macro). I guess to
> > >>>>>>> make
> > >>>>>>> this work the parser would need to open up a macro node any time a
> > >>>>>>> #abc() is included and just have all the following VTL be children.
> > >>>>>>> (either to an #end statement or to the end of the file. Not sure if
> > >>>>>>> this is workable, though it might be.
> > >>>>>>>
> > >>>>>>> An alternative would be to use a unique way of identifying block
> > >>>>>>> macros that could be recognized by the parser. Maybe a special
> > >>>>>>> directive to call the macro? In other words, to call the block
> > >>>>>>> macro
> > >>>>>>> "strong" the syntax would be
> > >>>>>>>
> > >>>>>>> #call(strong)
> > >>>>>>>
> > >>>>>>> #end
> > >>>>>>>
> > >>>>>>> WILL
> > >>>>>>>
> > >>>>>>> On Jan 6, 2008 6:06 PM, Raghu Rajah <[EMAIL PROTECTED]> wrote:
> > >>>>>>>> Nathan - Overloading #macro would be rather hard, especially since
> > >>>>>>>> VTL
> > >>>>>>>> does
> > >>>>>>>> not have a begin token for blocks, the parser lookahead would
> > >>>>>>>> become
> > >>>>>>>> non-deterministic, I think. I can call the inner call
> > >>>>>>>> "contentBody",
> > >>>>>>>> "yield"
> > >>>>>>>> is rather commonly used term for this purpose in the ruby world.
> > >>>>>>>>
> > >>>>>>>> Claude - Was that a +1? Trust you are a committer.
> > >>>>>>>>
> > >>>>>>>> Raghu.
> > >>>>>>>>
> > >>>>>>>>> Subject: Re: Blocks in Velocimacros
> > >>>>>>>>> From: [EMAIL PROTECTED]
> > >>>>>>>>> To: [email protected]
>
> > >>>>>>>>> Date: Sun, 6 Jan 2008 23:39:43 +0100
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> I agree, this would be useful. But since the parser would have to
> > >>>>>>>>> know
> > >>>>>>>>> macros definitions to detect blocks, I'm pretty sure it's very
> > >>>>>>>>> hard to
> > >>>>>>>>> implement.
> > >>>>>>>>>
> > >>>>>>>>> The way to go is the custom directive - that's much easier.
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Claude
> > >>>>>>>>>
> > >>>>>>>>> Le dimanche 06 janvier 2008 à 14:13 -0800, Nathan Bubna a écrit :
> > >>>>>>>>>> Yeah, i'm at least interested. If it works well and we have some
> > >>>>>>>>>> good
> > >>>>>>>>>> tests for it (and, of course, all existing tests pass), i would
> > >>>>>>>>>> even
> > >>>>>>>>>> support putting it into Velocity 1.6 (rather than wait for 1.7).
> > >>>>>>>>>> We've already got a lot of macro improvements in, this would
> > >>>>>>>>>> Though,
> > >>>>>>>>>> i'd want the support of at least one other committer before doing
> > >>>>>>>>>> that. I do have one question and one suggestion at this point:
> > >>>>>>>>>> Would
> > >>>>>>>>>> it work to overload the #macro directive instead of using
> > >>>>>>>>>> #blockmacro?
> > >>>>>>>>>> (Not that big a deal to me, but people will ask.) And i would
> > >>>>>>>>>> suggest using $bodyContent as the default, instead of $yield
> > >>>>>>>>>> since
> > >>>>>>>>>> that is more familiar to people.
> > >>>>>>>>>>
> > >>>>>>>>>> This is a great idea though! People have talked about it, but
> > >>>>>>>>>> no one
> > >>>>>>>>>> has ever taken it upon themselves to work on it.
> > >>>>>>>>>>
> > >>>>>>>>>> On Jan 6, 2008 12:19 PM, Raghu Rajah <[EMAIL PROTECTED]> wrote:
> > >>>>>>>>>>> If I offer to implement block support, is there any interest in
> > >>>>>>>>>>> absorbing
> > >>>>>>>>>>> this contribution into the codebase.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Here's what I intend to do,
> > >>>>>>>>>>>
> > >>>>>>>>>>> 1. Add a new directive called "blockmacro", along the same
> > >>>>>>>>>>> lines as
> > >>>>>>>>>>> macro, subclassing behavior from the current macro processing
> > >>>>>>>>>>> both
> > >>>>>>>>>>> in
> > >>>>>>>>>>> the
> > >>>>>>>>>>> directive and the JJT.
> > >>>>>>>>>>> 2. In order to render the content of the block, one could use a
> > >>>>>>>>>>> special
> > >>>>>>>>>>> context variable called "yield", that could be customized as
> > >>>>>>>>>>> whatever
> > >>>>>>>>>>> in
> > >>>>>>>>>>> the properties.
> > >>>>>>>>>>>
> > >>>>>>>>>>> The net definition would look something like,
> > >>>>>>>>>>>
> > >>>>>>>>>>> #blockmacro strong
> > >>>>>>>>>>> <strong>${yield}</strong>
> > >>>>>>>>>>> #end
> > >>>>>>>>>>>
> > >>>>>>>>>>> and usage would look like
> > >>>>>>>>>>>
> > >>>>>>>>>>> #strong
> > >>>>>>>>>>> This is a strong text for #if (${user.male}) Mr. #else Ms.
> > >>>>>>>>>>> #end
> > >>>>>>>>>>> ${user.name}.
> > >>>>>>>>>>> #end
> > >>>>>>>>>>>
> > >>>>>>>>>>> Regards,
> > >>>>>>>>>>> Raghu.
> > >>>>>>>>>>>
> > >>>>>>>>>>>> From: [EMAIL PROTECTED]
>
> > >>>>>>>>>>>> To: [EMAIL PROTECTED]
> > >>>>>>>>>>>> Subject: RE: Blocks in Velocimacros
> > >>>>>>>>>>>> Date: Thu, 3 Jan 2008 17:49:07 -0500
> > >>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I think I will go the custom directive route.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Thanks for all the pointers. I especially like the Hacking
> > >>>>>>>>>>>> Velocity
> > >>>>>>>>>>>> presentation - rather groovy. It addresses nearly all the
> > >>>>>>>>>>>> issues I
> > >>>>>>>>>>>> had.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Raghu.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Date: Thu, 3 Jan 2008 14:37:35 -0800
> > >>>>>>>>>>>> From: [EMAIL PROTECTED]
> > >>>>>>>>>>>> To: [EMAIL PROTECTED]
> > >>>>>>>>>>>> Subject: Re: Blocks in Velocimacros
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Of course, you would then have to be sure to escape all "
> > >>>>>>>>>>>> characters
> > >>>>>>>>>>>> in your body content:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> #set( $Q = '"' )
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> #myForm( "
> > >>>>>>>>>>>> <!-- some ${Q}arbitrary${Q} -->
> > >>>>>>>>>>>> " )
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> so that you don't prematurely end your $body parameter. this
> > >>>>>>>>>>>> is
> > >>>>>>>>>>>> obviously not ideal, but may be easier than writing a custom
> > >>>>>>>>>>>> directive, depending on the specifics of your case(s).
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Jan 3, 2008 2:35 PM, Nathan Bubna <[EMAIL PROTECTED]> wrote:
> > >>>>>>>>>>>> Also note that as of Velocity 1.5, you can include line breaks
> > >>>>>>>>>>>> in
> > >>>>>>>>>>>> strings, making it reasonable (though not as pretty to do
> > >>>>>>>>>>>> something
> > >>>>>>>>>>>> like:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> #macro( myForm $body )
> > >>>>>>>>>>>> <form...>
> > >>>>>>>>>>>> $body
> > >>>>>>>>>>>> </form>
> > >>>>>>>>>>>> #end
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> #myForm("
> > >>>>>>>>>>>> <!-- some arbitrary html here -->
> > >>>>>>>>>>>> ")
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Jan 2, 2008 7:13 PM, Raghuram Rajah <[EMAIL PROTECTED]>
> > >>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Can I use a block within a velocimacro? Basically, I am trying
> > >>>>>>>>>>>> to
> > >>>>>>>>>>>> create a macro that will emit a XHTML tag with some javascript
> > >>>>>>>>>>>> out.
> > >>>>>>>>>>>> I
> > >>>>>>>>>>>> would hate to create a begin macro and an end macro to
> > >>>>>>>>>>>> accomplish
> > >>>>>>>>>>>> this. That would be rather error prone.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I would ideally like to do something like,
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> #myForm(...)
> > >>>>>>>>>>>> <!-- some arbitrary html here -->
> > >>>>>>>>>>>> #end
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> generating something like
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> <form ....
> > >>>>>>>>>>>> <!-- some arbitrary html here -->
> > >>>>>>>>>>>> </form>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Any suggestions would be greatly appreciated.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Thanks,
> > >>>>>>>>>>>> Raghu.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> _________________________________________________________________
> > >>>>>>>>>>>> Share life as it happens with the new Windows Live.
> > >>>>>>>>>>>> http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelif
> > >>>>>>>>>>>> e_
> > >>>>>>>>>>>> 122007
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> -------------------------------------------------------------------
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>>>>>>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> _________________________________________________________________
> > >>>>>>>>>>>> i'm is proud to present Cause Effect, a series about real
> > >>>>>>>>>>>> people
> > >>>>>>>>>>>> making
> > >>>>>>>>>>>> a difference.
> > >>>>>>>>>>>> http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect
> > >>>>>>>>>>>
> > >>>>>>>>>>> _________________________________________________________________
> > >>>>>>>>>>> Watch "Cause Effect," a show about real people making a real
> > >>>>>>>>>>> difference.
> > >>>>>>>>>>> http://im.live.com/Messenger/IM/MTV/?source=text_watchcause
> > >>>>>>>>>>
> > >>>>>>>>>> ---------------------------------------------------------------------
> > >>>>>>>>>> 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]
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> _________________________________________________________________
> > >>>>>>>> Get the power of Windows + Web with the new Windows Live.
> > >>>>>>>> http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_012008
>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> ---------------------------------------------------------------------
> > >>>>>> 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]
> > >>>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> 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]
