On 7/26/07, Jonathan Revusky <[EMAIL PROTECTED]> wrote:
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?
Agreed, it would be good to log a warning (perhaps error?) level
message about it as well.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
