Re: [WebMacro-user] A WM brain bender: The solution

[Alex Twisleton-Wykeham-F. <al...@fi...>]

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-e=
nd
> 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=C2=A0 (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=20
Template that doesn't know where the thing that it is going to evaluate is=
=20
coming from.=20

Suppose I give a more concrete example.  I have a series of templates that=
=20
provide "eye candy" around a central template.  These decorator templates=20
will have been created by individuals (graphic designers) who have no conce=
pt=20
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=
=20
using one standard command that will be forwards compatible with the source=
s=20
of Templates that we haven't yet thought of.

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

=2D by #include
=2D by some variant of #eval

Now, when we contract our graphic designers to build our decorator template=
s,=20
we are going to have to say to them that they should use one or the other=20
(and build a test framework that passes in a dummy template using the elect=
ed=20
technology that lets them evaluate their work).  Once they have completed=20
their templates then we should (using whichever technology that we settle o=
n)=20
be able to swap out the testing template for the real template using=20
whichever template source is appropriate for that particular deployment,=20
ideally using the same decorator template in multiple different locations=20
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=
=20
will resolve to future sources of Templates that haven't yet been defined=20
yet.

If we go with #eval then we will want to pass in a Template object that has=
=20
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=20
where in the hierarchy we insert out code to generate our Template from the=
=20
as yet undefined source.  My 'gut feeling' is that as the majority of time=
=20
including a template for evaluation is being performed by #include then=20
keeping things consistent for the graphic designer is "a good thing".

Now, earlier you mentioned the problem of knowing what "protocol" we are us=
ing=20
and the danger of "'infecting' a standard directive".  I don't understand w=
hy=20
if we have a custom Template source that is resolvable by implementing a=20
custom TemplateLoader and registering it with the DelegatingTemplateProvide=
r=20
only in deployments where we want to use it is in any way against the desig=
n=20
of the code as it stands.

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

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

This would guarantee that my implementation of a Db resolver wouldn't confl=
ict=20
with your implementation of Db resolver (by utilising "Db:" as the standard=
=20
header), plus it would be relatively easy to debug what the problem was as =
if=20
the TemplateLoader wasn't registered then you would get a "cannot find=20
template" message which would include the path the TemplateLoader that is=20
missing, whereas if the appropriate TemplateLoader was included and record =
24=20
on the TemplateTable  was not found (or whatever the tech required is) then=
=20
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=C2=A0 looking for more simple solut=
ions.

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

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

>  Real Magic:
>  Personally, I don't like magic, because the tricks are sometimes confusi=
ng
> 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 =3D <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 decorato=
r=20
(or inner) template.

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

Alex