Re: A WM brain bender: The solution

On Saturday 12 March 2005 07:47, marcel.huijkman wrote:
> Please don't do this via the #include directive.
>  It's not an include and it sounds like a workaround for a specific
> problem!
>
>  Don't misuse directive for other tasks as for where they were made for.

I fully appreciate your point of view, and am happy to follow what appears to 
be the general consensus, but I would just like to add this usage possiblity 
into the planning:-

If I have a template that knows that it is going to be fed a sub-template that 
needs to be evaluated as a template withint the current context.  I don't 
know what this template is or where it is going to be coming from as this is 
supplied by a process outside the scope of my current template.  I'm going to 
be passing in the name of the template as a String variable to this template.

In a 'normal' model, we would expect the template to be a conventional 
webmacro template and we just do (outer is the template that is including the 
inner template):-

	outer: #set $templatePath = "template/path/file.wm"
	inner: #include as template "$templatePath"

and it goes off and finds and evaluates the Template.

Now, if I've registered a FileTemplateLoader onto my 
DelegatingTemplateProvider then the following will also work (transparently 
to my inner template):-

	outer: #set $templatePath = "/absolute/webmacro/dir/template/path/file.wm"
	inner: #include as template "$templatePath"

And if I implemented an HttpTemplateLoader and registered it with 
DelegatingTemplateProvider then it would be able to do this:-

	outer: #set $templatePath = "http://www.mytemplateserver.com/file.wm"
	inner: #include as template "$templatePath"

Now, supposing that I had a Db that contained templates that where being 
maintained through a different purpose and I made a DbTemplateLoader, then I 
would be able to do this:-

	outer: #set $templatePath = "db:/file.wm"
	inner: #include as template "$templatePath"

and the DbTemplateLoader would accept the request for the template, due to the 
leader header and resolve it via some internal logic from the rest of the 
path and then return a Template object.

So far, I don't feel that I've strayed outside the scope of the what #include 
is supposed to do, and if anything I've improved encapsulation of the inner 
template by not forcing it to know where the Template is coming from or how 
it was generated.

So why would it be a misuse of the task to make it so that the inner template 
could just parse a Template source where the source of the Template was 
completely undefined?

	outer: #set $templatePath = "string:$someTemplateSource"
	inner: #include as template "$templatePath"

If we follow the #eval method that has been proposed then the inner template 
has to magically know that the $templatePath that has been passed to it has 
to be treated differently to other normal templates and the code switches 
into something like:-

	outer: #set $templatePath = <somethingUnknown>
	inner: #if ($Magic.requiresEval($templatePath)) { 
			#eval $templatePath 
		} #else {
			#include as template "$templatePath"
		}

which to me seems to be a disadvantage.

I do of course think that having the #eval syntax with the opportunity to pass 
in dedicated Context scopes etc etc is of course a good thing and should be 
possible and utilised in situations when the inner template _knows_ that this 
is the case, but for the situation that is described above, I fail to see 
where the StringTemplateLoader implementation of TemplateLoader is failing in 
the requirements of TemplateLoader?

Alex


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click