Re: A WM brain bender: The solution

Marcel

On Sunday 13 March 2005 06:48, marcel.huijkman wrote:
>  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.)

OK, I get your point but that still doesn't solve the problem of having a 
Template that doesn't know where the thing that it is going to evaluate is 
coming from. 

Suppose I give a more concrete example.  I have a series of templates that 
provide "eye candy" around a central template.  These decorator templates 
will have been created by individuals (graphic designers) who have no concept 
of where the template that is going to be nested inside them is coming from.

We therefore have to be able to let them include this nested functionality 
using one standard command that will be forwards compatible with the sources 
of Templates that we haven't yet thought of.

There are two ways of getting a template to be resolved inside a webmacro 
context at present:-

- by #include
- by some variant of #eval

Now, when we contract our graphic designers to build our decorator templates, 
we are going to have to say to them that they should use one or the other 
(and build a test framework that passes in a dummy template using the elected 
technology that lets them evaluate their work).  Once they have completed 
their templates then we should (using whichever technology that we settle on) 
be able to swap out the testing template for the real template using 
whichever template source is appropriate for that particular deployment, 
ideally using the same decorator template in multiple different locations 
with different technologies passing in the Template to be decorated.

So, if we go with #include then we need to be able to pass in a String that 
will resolve to future sources of Templates that haven't yet been defined 
yet.

If we go with #eval then we will want to pass in a Template object that has 
been generated via a method that hasn't yet been defined yet.

These are both fundamentally the same problem, but it is just a question as to 
where in the hierarchy we insert out code to generate our Template from the 
as yet undefined source.  My 'gut feeling' is that as the majority of time 
including a template for evaluation is being performed by #include then 
keeping things consistent for the graphic designer is "a good thing".

Now, earlier you mentioned the problem of knowing what "protocol" we are using 
and the danger of "'infecting' a standard directive".  I don't understand why 
if we have a custom Template source that is resolvable by implementing a 
custom TemplateLoader and registering it with the DelegatingTemplateProvider 
only in deployments where we want to use it is in any way against the design 
of the code as it stands.

The implementation of these custom TemplateLoaders would be associated with 
the individual deployment that they where being utilised for.  If we are 
worried about namespace clashes on protocol names then one could use more 
unique 'namespace' definitions, for example:-

#set $templatePath="<templatePath>:<templateMetaData>"
eg:-
#set $templatePath="org.acme.db.DbTemplateLoader:TemplateTable.24"

This would guarantee that my implementation of a Db resolver wouldn't conflict 
with your implementation of Db resolver (by utilising "Db:" as the standard 
header), plus it would be relatively easy to debug what the problem was as if 
the TemplateLoader wasn't registered then you would get a "cannot find 
template" message which would include the path the TemplateLoader that is 
missing, whereas if the appropriate TemplateLoader was included and record 24 
on the TemplateTable  was not found (or whatever the tech required is) then 
it would be a more informative ResourceException.

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

This kind of depends on who "people" refers to.  If "people" is the graphic 
designers generating the wrapper templates, then they never even need to know 
what is in $templatePath or what tech is being used to resolve it.  From 
their point of view it is already as simple as it can possibly get as they 
just have to '#include as template "$templatePath"'.  If this doesn't work 
then it is not their problem, but rather the problem of the parent template.

From the viewpoint the people writing the framework that is going to invoke 
the parent template, it would just be a case of them selecting the technology 
that they are going to utilise to deliver the templates as is appropriate for 
the task in hand.  If the templates are constant, then they may just use a 
standard TemplateLoader and pass in a 'conventional' $templatePath that gets 
resolved with stock WebMacro TemplateLoader implementations.  If they have 
more complex requirements (eg dynamically generated Template sources) then 
they would create a dedicated binding to them via a custom TemplateLoader and 
register this alone in the WebMacro template file.  This doesn't have to be a 
global "always on" thing for all WebMacro deployments, but just for 
situations when it is required.

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

I fully agree with you. My example:-

<snip>

> >         outer: #set $templatePath = <somethingUnknown>
> >         inner: #if ($Magic.requiresEval($templatePath)) {
> >                         #eval $templatePath
> >                 } #else {
> >                         #include as template "$templatePath"
> >                 }
> >
> > which to me seems to be a disadvantage.

was intended to illustrate something that I wanted to avoid in the decorator 
(or inner) template.

The "custom protocol include" structure currently works and enables a 
decorator template to always include a Template in multiple different 
situations which are delivering the templates from different technologies 
without requiring the decorator template author to have any knowledge of the 
implementation or usage of the delivery method of the Template, and it will 
be very useful to me in some situations.  However, if this is not the most 
correct way of achieving this result then I would of course like to refactor 
my usage patterns into a better solution so would be very happy to get some 
pointers as to alternatives.

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_ide95&alloc_id396&op=click