[Webmacro-devel] Re: ContextTool: A different approach

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

On Sunday, July 27, 2003, at 07:01  PM, Brian Goetz wrote:

>> In addition, having a "globals.wm" template would make it real easy 
>> for one to define their #use statements in a central place... that 
>> isn't buried inside of webmacro.jar
>
> Lets say we had a "globals.wm" that would include #use and #macro 
> definitions and get #included as macro in every template.

Okay.

> This file would have to live somewhere.

Yes, it would.  In my application's "template space", not in 
webmacro.jar

> And something would either have to point to it from the 
> Webmacro.properties, or it would have to have a "magic" name (e.g., 
> globals.wm) which WM would look for through the template loader.  
> Knowing how much you like the magic name idea, lets assume that 
> WebMacro.properties for the app will have something like
>
>   IncludeInEveryTemplate: globals.wm

Exactly.  A configuration option.

> (and there's no reason there can't be more than one of these 
> directives.)

We wouldn't necessarily need to allow for more than one b/c 
"globals.wm" could always #include other templates.

> How is this all that different, in terms of configuration effort, 
> readability, or degree of magic, from WebMacro.properties having this 
> (which works now):
>
>   ContextTools.Foo: com.me.my.FooTool
>   ContextTools.EricIsADoofus: com.me.my.DoofusTool

You missed this one:

     ContextTools.BrianIsBeingAnAss: com.goetz.brian.AssTool

How is it different?  1 configuration that you'd probably be able to 
intelligently configure while you're are initially configuring 
WebMacro.  I don't know about you, but I would not be capable of 
trimming (or expanding) the list of ContextTools during my initial 
configuration of WM... esp. if I'm a new user.  I wouldn't know the 
difference between VaraiableTool and TypeTool, and I wouldn't even know 
why I would (or wouldn't) need them.

But I think I could initially see the benefit of a "global template" 
and be able to configure it appropriately for my application.

>> I can see this.  However, one of the things I hear from the few 
>> template designers I work with is "What is available for me to use in 
>> this template?".  Having a list of #use definitions at the top would 
>> make their lives easier.
>
> Or harder.  But having a way of generating a list of "what can I do 
> within this WM app" might be a better approach -- something which 
> dumps out the syntax of all known macros, tools, and directives.

Like I said, I wasn't suggesting #use would also become the end-all 
auto-documentation mechanism.  Only that it would help to answer a very 
specific (and very common) question while also making tools less 
magical.

And don't forget that #use could also (probably) be expanded to support 
"as function"... removing its magic from the innards of WebMacro.

>> #use, which is a pluggable directive that can be easily turned off... 
>> and doesn't pollute Context.java and Broker.java.  The 
>> Template.write() thing is probably unavoidable.
>
> Given how little "magic" there is in Context and Broker now, I think 
> that the amount of magic that would have to be infused into 
> Template.write is probably greater.  So under this approach, we might 
> even be adding "magic"!

Maybe it is possible to eliminate most magic from Template.write().  
Haven't thought this through yet, but maybe with some kind of 
ToolWrapper that implements Macro (or ContextTool simply becomes a 
Macro whose .evaluate() method returns the actual tool object instance) 
that is dumped inline in the template during build time... all handled 
via UseDirective.

Perhaps filtering the magic in Template.write to something as simple as:

	foreach tool in list_of_referenced_tools_that_need_initialization {
		tool.init(context)
	}

eric