"Geir Magnusson Jr." wrote:
>
> #include now works. #parse is coming tomorrow (or so). A brief summary
> :
>
> The syntax is
>
> #include( arg1 [arg2 arg3 ...] )
>
> where
> argn = string literal or reference
>
> yes, it requres the () and yes, it takes multiple args if you wish.
>
> Also
> #include( arg1 arg2 )
>
> is equivalent to
>
> #include( arg1 )
> #include( arg2 )
Excellent Geir, that kicks some serious ass. :)
I really like the multi-arg improvement to the directive.
> What else ...
>
> 1) The included files *must* come from the template.path tree for
> security reasons [#include(/etc/passwd) is uncool :) ] So if you have
> content that lives outside of the template tree, link it in. We should
> probably add a staticcontent.path property for this to allow the static
> content to be separated from the templates.
#include'd files are generally not going to contain VTL. I'm all for
narrow interfaces (even in config files), but +1 on adding an additional
property to help manage static content.
> 2) The included filename must not have a .. in it (see #1).
Yup.
> 3) If something other than a reference or stringlit is used as an arg,
> an error will be logged and processing will continue.
>
> 4) If an incorrect filename is given (FileNotFound...) then an error
> will be logged and processing will continue.
>
> 5) If there is an error, default behavior is silent in render output.
> You can change this to make debugging easy for uses with two properties.
> Both must be there to work:
> include.output.errormsg.start = <!-- include error :
> include.output.errormsg.end = see error log -->
> You should see from above why two : so for HTML, you use above. For
> Java, maybe /* and */. A vaguely helpful error will be placed between
> errormsg.start and errormsg.end and written to the output. The point is
> to see that something happened in the stream, to prompt you to look at
> better error messages in the log.
That's beautiful man. The default behavior sounds very reasonable.
--
Daniel Rall <[EMAIL PROTECTED]>
