Created Jira Issue (VELOCITY-583 - http://tinyurl.com/yw5hbh)
Attached code as a patch to the jira issue. I will take a prefix approach with _ as the default, without any configurability of the prefix. Raghu. > Date: Fri, 25 Jan 2008 10:28:32 -0800 > From: [EMAIL PROTECTED] > To: [email protected] > Subject: Re: Blocks in Velocimacros > > 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] > _________________________________________________________________ Need to know the score, the latest news, or you need your Hotmail®-get your "fix". http://www.msnmobilefix.com/Default.aspx
