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
