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

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

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

>
>> Yes, it would.  In my application's "template space", not in 
>> webmacro.jar
>
> Is that all this is about?  Then this whole discussion is (almost) 
> moot!

No, I fully recognize that I need to have my own custom 
"webmacro.properties".

> WM.defaults is just that -- defaults.  I don't think there is anything 
> in WM.defaults that you can't easily "turn off" in WM.properties.  So 
> what's the issue?

It's not just configuration.  It's also trying to get the magical stuff 
out of the core of WM.  And it's about getting some kind of 
"globals.wm" template support.

> The only think you _can't_ do now easily is turn off ALL the default 
> tools.  But if that's really what you want, that's easily added:
>   SuppressDefaultContextTools: true
>   SuppressDefaultFunctions: true

This is important, but if it is all I wanted, I would have suggested it 
earlier.  :)

> That's a trivial enhancement and doesn't change the structure of 
> Context or context tools at all.
>
> Or here's another idea which might also make you happy: a "package" 
> concept.  A "package" is a bundle of WM add-ins (directives, tools, 
> macros, functions), most of which are currently defined in 
> WM.defaults/properties.  Take the current default functions and tools, 
> and put them in a package called "Default".  WM.defaults would load 
> this package, but WM.properties could override the loading with one 
> line.
>
> We could even break the current default tools/functions/etc into 
> relevant packages, like a servlet package (Request, Response, Form), a 
> utility package (List, etc), blah blah.
>
> Is that what you want?  That's easy too.

it seems pointless

>>>   IncludeInEveryTemplate: globals.wm
>>
>> Exactly.  A configuration option.
>
> I have no objection to this mechanism (it seems quite useful), but it 
> seems entirely orthogonal to the current discussion.

Only when you discount the fact that tools and probably functions, 
along with #macros, #beans, and <future thing here> could all be 
configured through this template.

You seem focused on context tools alone, but I'm suggesting something 
that will give us greater flexibility with lots of other things... in a 
consistent manner.

> Actually, having two -- one which is include at the top and one at the 
> bottom could be very helpful as a primitive style sheet mechanism.

Then somebody will want a "left" and a "right".  Ehh.  WM isn't used 
just for HTML generation.

And really, what I have in my head isn't for header/footer text, but 
for "context stuffing".  I can almost see header/footer templates being 
useful configuration options, but that's not what I'm suggesting.

>> You missed this one:
>>     ContextTools.BrianIsBeingAnAss: com.goetz.brian.AssTool
>
> Maybe Brian is stoopid, but I guess I just don't see how this is any 
> better than the current setup -- and I can see ways in which it is 
> worse.

template build-time (one-time only) creation of most tools
addition of a "global.wm" template
consistent configuration of tools, macros, functions

>> 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.
>
> It sounds like you'd be entirely satisfied with a config option that 
> just turns off loading of all tools that come from WM.defaults, then?

No, I'll be entirely satisfied when the magic is removed from the 
innards of WM.

> Is this really a debate about configuration visibility?  That sounds 
> like a sensible debate -- and I think the current mechanism is 
> probably "almost there."

No, it's not.  But my suggestion does require that configuration 
options be changed...

eric