Hi,

I think changing the macro syntax is bit tricky. So I'd like to go
with maximum recursive depths.

Supun.


I think I'm getting little bit confused here.

On 5/30/07, Will Glass-Husain <[EMAIL PROTECTED]> wrote:
Hi,

Oh, definitely, we should target our next release, version 1.6.  And we
should aim for JDK 1.4 compile-time / JDK 1.3 run-time compatibility.  No
reason to change that.

Is there a need to change the macro definition syntax?  The other issues
seem more urgent.  (and all backwards compatible).

I think Henning was referring to the *use* of the macros, not the definition
(is that right?).  And we added commas as a delimiter for 1.5.

WILL


On 5/29/07, Claude Brisson <[EMAIL PROTECTED]> wrote:
>
> Le mardi 29 mai 2007 à 06:52 -0700, Will Glass-Husain a écrit :
> > Actually, that's already implemented in Velocity 1.5
> >
> > #somemacro (arg1, arg2, arg3)
>
> I wasn't speaking about argument separators but about the definition
> syntax :
>
> #macro somemacro($arg) vs. #macro (somemacro, $arg)
>
> Both should be supported while only the latter works today. But that is
> maybe more difficult to implement than the two others, so it's probably
> not a priority.
>
> Speaking about Spun's work, did we state the target release? Some
> changes are BC, others not. So the way to go IMO would be to create the
> 2.0 branch (and if possible to commit some BC changes back to the
> trunk).
>
> Ah, and - that is not strictly related but could be of some interest for
> Supun: What is the target Java VM for the 1.6 engine? I'd propose Java
> 1.5, I don't remember at all if we stated somehting about this.
>
>
>   Claude
>
> > works fine. It used to be that spaces were required but  no more.
> > https://issues.apache.org/jira/browse/VELOCITY-430
> >
> > How about limiting the maximum recursion of macros?  VELOCITY-297?
> >
> > Alternately, if you want to tinker with the parser, try letting the
> macro
> > arguments be expressions instead of a single argument, e.g.
> > #somemacro (10 + 10)
> >
> > should work.
> >
> > I think these two ideas would be good starting places.  (both feasible
> to
> > solve in a short period and useful).
> >
> > WILL
> >
> > On 5/29/07, Claude Brisson <[EMAIL PROTECTED]> wrote:
> > >
> > > There is also an implicit syntaxic change in Henning's code example:
> > >
> > > he uses
> > >   #macro myNamedMacro($arg1, $arg2, $arg3)
> > >     ... do something with $arg1, $arg2, $arg3
> > >   #end
> > >
> > > which is quite natural but AFAIK not supported since the valid syntax
> is:
> > >   #macro (myNamedMacro, $arg1, $arg2, $arg3)
> > >     ... do something with $arg1, $arg2, $arg3
> > >   #end
> > >
> > > Supporting the former syntax would be great.
> > >
> > >
> > >   Claude
> > >
> > >
> > > Le mardi 29 mai 2007 à 18:28 +0530, Supun Kamburugamuva a écrit :
> > > > Hi,
> > > >
> > > > I have gone through most of the stuff pointed by Henning and now I
> > > > think I'm ready to start the real work. So I thought I should start
> > > > with a simple thing at the beginning. So I choose the 4th suggestion
> > > > (blank as argument delimiter') from Hennings list (I don't think
> this
> > > > will take much time). At the moment I'm working on it and trying to
> > > > figure out how it should be done.
> > > >
> > > > Regards,
> > > > Supun..
> > > >
> > > >
> > > >
> > > >
> > > > On 5/10/07, Henning P. Schmiedehausen <[EMAIL PROTECTED]> wrote:
> > > > > "Supun Kamburugamuva" <[EMAIL PROTECTED]> writes:
> > > > >
> > > > > Hi Supun,
> > > > >
> > > > > >I would like to start working on the macro issues as soon as
> > > possible.
> > > > > > I know the code writing officially starts on 28th May. But I
> thought
> > > > > >starting early would be better.
> > > > >
> > > > >
> > > > > I added a page to the Wiki about this
> > > > > (http://wiki.apache.org/velocity/GoogleSummerOfCode2007) and also
> some
> > > > > suggestions. Please do not be afraid about my + - ++++ scale, I
> might
> > > > > be terribly off. Also bear with my syntax typos, it's already late
> > > > > here.
> > > > >
> > > > > If we can get one or two ++ items resolved or even one ++++ item,
> I
> > > > > would be very happy with the GSOC project.
> > > > >
> > > > > >I have gone through the macro code and still I don't have a clear
> > > > > >picture of how the macro stuff is working.  What I have done up
> to
> > > now
> > > > > >is setting up debug points where I feel important and debugging
> the
> > > > > >code.
> > > > >
> > > > > Welcome to our world. :-)
> > > > >
> > > > > Here is the whirlwind tour. Let's see how much I still remember
> off
> > > > > the top of my head and how much I must look up in the code base:
> > > > >
> > > > > In the depths of the parser, there is Macro.processAndRegister.
> This
> > > > > is where a macro is registered with the engine. This in turn calls
> > > > > addVelocimacro on the passed RuntimeServices object (which is the
> > > > > actual instance of the engine). This is where the Velocimacro
> Factory
> > > > > comes in, because this call is just a facade before the call in
> the
> > > > > factory. The factory and the VelocimacroManager (which is inside
> the
> > > > > factory) are what keeps the macros inside the engine. The factory
> > > > > manages the macros and the manager the namespaces (yes, we do have
> > > > > such an underdocumented feature).
> > > > >
> > > > > The macros themselves are invoked when the AST is parsed, through
> a
> > > > > lookup in the ASTDirective class. This represents a directive on
> the
> > > > > AST, either one of the defined (#if, #set etc) through
> > > > > parser.isDirective() or a macro (which is similar, e.g. #foo,
> #bar)
> > > > > through rsvc.isVelocimacro()).
> > > > >
> > > > > I'd suggest that you check out src/parser/Parser.jjt which gets
> > > > > compiled by JJTree/JavaCC into the parser-related classes.
> > > > >
> > > > > The most interesting breakpoints are probably the following method
> > > > > entry points:
> > > > >
> > > > > RuntimeInstance:
> > > > >
> > > > >  * addVelocimacro
> > > > >  * getVelocimacro
> > > > >
> > > > > VelociMacroManager:
> > > > >
> > > > >  * addNamespace
> > > > >  * getNamespace (multiple)
> > > > >
> > > > > VelociMacroManager.MacroEntry:
> > > > >
> > > > >  * C'tor
> > > > >  * getNodeTree
> > > > >  * createVelocimacro
> > > > >  * parseTree
> > > > >  * setup
> > > > >
> > > > > VelocimacroFactory:
> > > > >
> > > > >  * getVelocimacro (do not remove the synchronized block!)
> > > > >  * initVelocimacro
> > > > >  * addVelocimacro
> > > > >
> > > > > This is hopefully enough to get you going. Write a small harness
> to
> > > > > test your code (load a template, parse it, render it) and test a
> few
> > > > > very simple templates under the debugger. This should give you an
> idea
> > > > > how inline macros work. Try again with a macro library (configured
> in
> > > > > properties) to understand the difference. Look at the
> setFromLibrary()
> > > > > methods in the MacroEntry class.
> > > > >
> > > > > Find out, what the Twonk is good for. ;-)
> > > > >
> > > > >        Best regards
> > > > >                Henning
> > > > >
> > > > > --
> > > > > Henning P. Schmiedehausen  -- [EMAIL PROTECTED] | J2EE,
> > > Linux,               |gls
> > > > > 91054 Buckenhof, Germany   -- +49 9131 506540  | Apache
> > > person              |eau
> > > > > Open Source Consulting, Development, Design    | Velocity -
> Turbine
> > > guy     |rwc
> > > >
> > >
> >                                                                            
|m
> > > k
> > > > > INTERMETA - Gesellschaft fuer Mehrwertdienste mbH - RG Fuerth, HRB
> > > 7350     |a s
> > > > > Sitz der Gesellschaft: Buckenhof. Geschaeftsfuehrer: Henning
> > > Schmiedehausen |n
> > > > >
> > > > >               "Save the cheerleader. Save the world."
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > 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


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to