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]
