Re: Velocity Macro Improvement - GSCO
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]
Re: Velocity Macro Improvement - GSCO
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
Re: Velocity Macro Improvement - GSCO
Actually, that's already implemented in Velocity 1.5 #somemacro (arg1, arg2, arg3) 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
Re: Velocity Macro Improvement - GSCO
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
