Really great to see your contribution
I haven't had time to review this in detail yet. But I want to make sure
users will be able to use block macros when put at the top of a file, or
when included with #parse. It's not feasible in many setups to include the
block macros in a globally accessible file.
WILL
On Jan 25, 2008 10:28 AM, Nathan Bubna <[EMAIL PROTECTED]> wrote:
> 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]
>
>
--
Forio Business Simulations
Will Glass-Husain
[EMAIL PROTECTED]
www.forio.com
