Nathan Bubna wrote:
I believe your analysis is correct. The parser will have to treat anything in the form of #foo( ... ) is a potential macro at parse time, then leave the check for a matching macro to render time. If it turns out to be a macro, then we should render the macro, if not (and this may turn out to be tricky), we need to render that text exactly as it was, whitespace and all.
Out of idle curiosity, how often do you think that a template writer actually wants to output something like #foo($bar, $baz) to the output? In the cases where you do see that there is no #foo macro in the context, would this not be, in the overwhelming majority of cases, a result of some kind of coding error?
Jonathan Revusky -- lead developer, FreeMarker project, http://freemarker.org/
On 7/18/07, Supun Kamburugamuva <[EMAIL PROTECTED]> wrote:Hi, I was looking into the issue of including macros via the #parse method. Following is the my understanding of the problem. The main reason that causes this to be a hard problem to solve without touching the parser implementation is described below. At the moment when the parser encounter a call to a macro i.e. #foo(123) it looks weather a macro definition exists via the runtime system. If a definition exists everything is going well. This happens in the AST building face of the parser (not in the rendering face). So this means with the current implementation, the macros must be registered with the runtime system before a call occurs and this is the cause of all the troubles. Now this is the problem with #parse directive. #parse directive builds the AST of the files and render them at the same time. This happens when the main template that include the #parse directive get rendered. But when this happens, AST of the template that include the #parse directive is been built already. But the macro calls that are in the main template get invalidated because at the moment AST is built macros are not registered with the runtime system. As I can see the solution for this problem is, parser should not look into the runtime system to determine weather a directive like #foo() is a macro call or not. Instead parser should look ahead for the '(' token when it encounters something like #foo to deside weather it is a macro call or not. I would like to know weather this is solvable without breaking the current system in the way that I have decribed above? Regards, Supun. P.S. If we can do this my first implementation of 'including macros programmatically' can be done using this method. --------------------------------------------------------------------- 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]
