[Webmacro-devel] ContextTool: A different approach

[Eric B. R. <eb...@tc...>]

I sent this to the -devel list earlier today, but it seems it never 
made it through.  :(  This, I think is actually a good idea.  So I'm 
sending it again...

........

Been thinking about this more, and here's yet another different 
approach.

My main issue swith ContextTools are: 1) they're configuration options, 
2) definition of which tools are available is hard to find, 3) and WM 
has some magical code to handle them.

Keats said something in an earlier post that got me thinking:  "Why 
would we want to load every tool into every request when nothing is 
referencing it?"

You wouldn't.  That's a given.  But what if a template could define 
which tools it uses, similar to how it defines each #macro it uses.  
Example (syntax open for discussion):

#use "org.webmacro.servlet.tools.FormTool" as tool named $Form
#use "org.webmacro.servlet.tools.RequestTool" as tool named $Request
#use "org.webmacro.tools.TypeTool" as tool named $Type

#use is a "build-time" directive similar to #const and #macro in that 
during the build phase of the template a list (or map?) of the defined 
tools is stored in the template (similar to #macro's).

If these tools implement the ContextTool method, they are stuffed into 
the context somewhere at the start of the template evaluation at 
*run-time* (either template.write(), .getTemplate(), or even a new 
wm.getContext(template) method).  If these tools do NOT implement 
ContextTool, we can do some build time optimization by creating a new 
instance of the object and putting it into the Template during *build 
time* (similiar to #const).

Another build-time optimization (post-build, really) could be to walk 
the Template elements and make sure the defined #use variables are 
actually referenced.  If they're not, don't bother creating instances 
of them at all.

Advantages to this idea:

1) #use definitions could be #included globally across an entire site
2) "as tool" would allow us to do other things like "as foo", "as bar", 
"as whatever" in the future ("as function", maybe???)
3) Definition of the tools is *explicit* per template... in the place 
one would like to know what is available
4) It maintains a bit of backwards compatibility with pre-2.0.  We 
might need to allow for a "globals.wm" template configuration option, 
but we've wanted to do that for awhile now anyways
5) It takes all the magic out of Context.java... and might even allow 
us to get rid of WebContext too (ie, standalone-globals.wm v/s 
servlet-globals.wm)
6) It gives us the ability to do build-time optimizations based on if 
these things are actually referenced
7) It puts the power of tool use into the hands of the template 
designer (this could be a disadvantage too)
8) With the addition of a Template.getToolList() method and a 
"TemplateTool" object, it makes the available tools (in a template) 
discoverable by Ignition's fancy auto-documentation thingie.
9) A 3rd party developer doesn't need (unless he wants Context access) 
to implement a WebMacro-specific interface at all
10) I was hoping for a "top 10" list, but could only come up with 9

thoughts?

eric