Re: A WM brain bender: The solution

Alex,

I get your point. You want some magic to happen based on a given
front-end string.

So you made up some protocols like Db: or String: wich autoMagically
give you the right spot,

where the temple should be.

Okay, some things to think about:

What if I've got more than 1 Db?

(and on different locations, and/or different brands, and /or not all
are rdmbs)?

How would your prefix look like?

Who would decide those prefixes?

What if you have a hashmap, hashtable, array, vector where all the
templates where is

How would your prefix look like?

I think, if you what some magic, you have to make magic by creating the
directive that

you want but not by 'infecting' a standard directive. The nature (and
the absolute advantage)

of WM is that it has pluggable directives. (You might even copy-paste
for your benefit.)

Please rethink this over.

For all I know, we could be getting 1 directive which does it all. The
usage is so complex that

people start looking for more simple solutions.

Real Magic:

Personally, I don't like magic, because the tricks are sometimes
confusing my mind.

I see something is happening, I thinks I know how the trick went, and
at the end,

I still feel cheated.

Programmers Magic:

I do like magic, if the result is predictable and when there is
absolutly no doubt in

the way the trick did it's job.

That's it for now.

- Marcel -

Alex Twisleton-Wykeham-Fiennes wrote:

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
_______________________________________________
Webmacro-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/webmacro-user

.

-------------------------------------------------------
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