webmacro-devel Mailing List for WebMacro (Page 22)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> 4) Templet/Eval. This really needs a wiki page and there is none.
> Keats?

No problem.

Keats

On Mon, 28 Jul 2003 12:19:38 -0700, Lane Sharman <la...@op...> 
wrote:

>
>
> Brian Goetz wrote:
>
>>> I really would like to implement this.
>>>
>>>
>>
>> You mean, as suggested in my revision of Marc's proposal?
>>
> Yes. I like the 2 levels of indirection. It was hard to decode at first. 
> But basically, every tool "name" has it owns factory. Right?

Well yes and no. They can share factories - the factory signature is 
getVariable( String name, Context ctx) so you get around the very annoying 
thing with ContextTools that you have to implement a class and a factory, 
or mix the functionality into one class (ugly).

So it's a nice solution because it is very flexible :)

Marc

-- 
Marc Palmer
Contract Java Consultant/Developer

                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

done.

-lane

Brian Goetz wrote:

>
>> Who wants to tackle this?
>
>
> I'll take it.
>
>> 2) Removal of org.opendoors.*
>> This should go into a new cvs module, "wm-optional". I will start 
>> this unless someone is really hungry. Other things need to go there 
>> too. This is part of the pruning effort.
>
>
> You do that one.
>
>> 3) ConcurrentHashmap.
>
>
> I got this one.
>
>
>
> -- 
> Brian Goetz
> Quiotix Corporation
> br...@qu...           Tel: 650-843-1300            Fax: 
> 650-324-8032
>
> http://www.quiotix.com
>
>
>

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga

>Who wants to tackle this?

I'll take it.

>2) Removal of org.opendoors.*
>This should go into a new cvs module, "wm-optional". I will start this 
>unless someone is really hungry. Other things need to go there too. This 
>is part of the pruning effort.

You do that one.

>3) ConcurrentHashmap.

I got this one.

--
Brian Goetz
Quiotix Corporation
br...@qu...           Tel: 650-843-1300            Fax: 650-324-8032

http://www.quiotix.com

Looks fantastic to me. Now we have indirect name resolution working for 
templet names.

Excellent.

And,  a better context tool :)

Lane

Marc Palmer wrote:

>
> Guys,
>
> Following on from the discussion with Keats a few days ago, to solve 
> the problem of calling snippets of WM script without having a huge 
> #if...#elseif chain or using #include, I have added a "get" method to 
> VariableTool.
>
> Usage is trivial, but very useful:
>
> #templet $templateA
>   This is A!
> #end
>
> #templet $templateB
>   This is B!
> #end
>
> #set $items = [ "A", "A", "B", "B", "B", "A"]
> #foreach $i in $items
>   #eval $Variable.get("template$i")
> #end
>
> This outputs:
>
>   This is A!
>   This is A!
>   This is B!
>   This is B!
>   This is B!
>   This is A!
>
> This is very nice indeed for iterating over lists of objects and doing 
> different things based on a value of a property of the objects.
>
> This could also be used as function of course, making it even more 
> convenient.
>
> Can I commit? It's trivial:
>
>    /**
>     * Get the specified object <code>name</code> defined from the active
>     * Context.
>     */
>    public Object get (Object name)
>    {
>        return context.get(name);
>    }
>
>
> Marc

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga

1) http://www.webmacro.org/WebMacroDevelScratchPad
Lays out the spec for implementing better auto context loading. I think 
we are now good to implement. Thanks to all who kept their patience on 
this one. More needs to be done down the road on global includes. We 
have not lost this thread :)

Who wants to tackle this?

2) Removal of org.opendoors.*
This should go into a new cvs module, "wm-optional". I will start this 
unless someone is really hungry. Other things need to go there too. This 
is part of the pruning effort.

3) ConcurrentHashmap.
I am eager to see this. What is the plan here?

4) Templet/Eval. This really needs a wiki page and there is none. Keats?

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga

Brian Goetz wrote:

>>I really would like to implement this. 
>>    
>>
>
>You mean, as suggested in my revision of Marc's proposal?  
>
Yes. I like the 2 levels of indirection. It was hard to decode at first. 
But basically, every tool "name" has it owns factory. Right?

-Lane

>I think
>that it is simple, incremental, and backward compatible.  
>
>What do the rest of the folks say?  Marc?  Eric?  Does it move things
>in the direction you want?  
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>  
>

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga

On Monday, July 28, 2003, at 11:07  AM, Keats wrote:
> Sounds good to me.  Go for it.
>
> A function might be nice.  I'm not sure what a good name for it would 
> be.  $var()?, $getVar()?

$get()

eric

Sounds good to me.  Go for it.

A function might be nice.  I'm not sure what a good name for it would be.  $var()?, $getVar()?

Keats

On Monday, July 28, 2003, at 10:20  AM, Marc Palmer wrote:

> This could also be used as function of course, making it even more  
> convenient.
>
> Can I commit? It's trivial:

please!  I like the idea of being able to do $get("$SomeDynamicName")

eric

>
>    /**
>     * Get the specified object <code>name</code> defined from the  
> active
>     * Context.
>     */
>    public Object get (Object name)
>    {
>        return context.get(name);
>    }
>
>
> Marc
> --  
> Marc Palmer
> Contract Java Consultant/Developer
> 			
>                        w a n g j a m m e r s
>
>                 java and web software design
>              experts with an ethical outlook
>
>                   http://www.wangjammers.org
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/ 
> direct;at.aspnet_072303_01/01
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Guys,

Following on from the discussion with Keats a few days ago, to solve the 
problem of calling snippets of WM script without having a huge 
#if...#elseif chain or using #include, I have added a "get" method to 
VariableTool.

Usage is trivial, but very useful:

#templet $templateA
   This is A!
#end

#templet $templateB
   This is B!
#end

#set $items = [ "A", "A", "B", "B", "B", "A"]
#foreach $i in $items
   #eval $Variable.get("template$i")
#end

This outputs:

   This is A!
   This is A!
   This is B!
   This is B!
   This is B!
   This is A!

This is very nice indeed for iterating over lists of objects and doing 
different things based on a value of a property of the objects.

This could also be used as function of course, making it even more 
convenient.

Can I commit? It's trivial:

    /**
     * Get the specified object <code>name</code> defined from the active
     * Context.
     */
    public Object get (Object name)
    {
        return context.get(name);
    }

Marc
-- 
Marc Palmer
Contract Java Consultant/Developer

                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

On Mon, 28 Jul 2003 00:49:18 -0700, Brian Goetz <br...@qu...> wrote:

> You mean, as suggested in my revision of Marc's proposal?  I think
> that it is simple, incremental, and backward compatible.

Yep.

> What do the rest of the folks say?  Marc?  Eric?  Does it move things
> in the direction you want?

Oh yes indeed :)

[Quickly, gladly, shovelling dirt into the hole in which we have laid to 
rest the ContextTool issue/discussion]

-- 
Marc Palmer
Contract Java Consultant/Developer

                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

On Sun, 27 Jul 2003 17:45:30 -0700, Brian Goetz <br...@qu...> wrote:

>> Please don't yell at me - as far as I can see I think this is what Lane 
>> and I are converging on, if nobody else.
>
> The direction is nice.  It has one quite serious flaw -- there can be
> only one auto-loader.  This seems like a crippling limitation, but
> fortunately there's a relatively easy fix.  See the proposal I put on
> that page.

Of course multiple handlers is nicer, although I was proposing to keep 
things as simple as possible to "get it past the board" :)   An aggregating 
handler would have solved the problem, if a little ugly.

> I estimate that I could implement this in a 100% backward compatible
> way in about an hour, with no additional performance overhead.  So its
> got to be pretty simple :)

The alternative solution is good. ThingieFactory is not defined in your 
example though - but I assume it just has init(Broker) and getVariable( 
String name, Context ctx).

However, I think to be in line with Context.get we might have to have it 
getVariable( Object key, Context ctx) - unless we have Context call 
key.toString() automatically.

Go for it, it has my vote.

Hurrah! I think we are finally there! Eric - what do you think of this 
solution though? I think the stuff you have raised vis a configuration 
template is very interesting, but a separate issue. We can clean up WM a 
bit with this solution, and then look at global init templates.

i.e. we could have a global template with:

#declare directive org.webmacro.directive.SomeDirective
#declare directive org.webmacro.directive.SomeOtherDirective
#declare function org.webmacro.functions.SomeClass.someFunc

...and so on. However if that template is reloadable (very nice...) we 
probably introduce a whole load of synchronisation we currently don't have 
to do.

I think really, an application that needs "reloadability" of config should 
just create a new Broker and throw away the old Broker and WM it was using - 
 much like webapp reloading in servlet containers. It seems the only safe / 
efficient way to do it.

That, however, requires us to abstract Settings a bit more I think, and 
introduce settings change listeners - or allow the application to provide 
its own Settings implementation to the Broker (I don't think we have this 
now) so that you don't even need to rely on Properties (which if passed 
programmatically cannot really be polled for changes), and all config can 
come from the app.

Marc

-- 
Marc Palmer
Contract Java Consultant/Developer

                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

On Wed, 23 Jul 2003, Keats wrote:

| Correction: that should have been:
|
|   #foreach $varName in $varlist() {

I like this very much!

Endre,

> I really would like to implement this. 

You mean, as suggested in my revision of Marc's proposal?  I think
that it is simple, incremental, and backward compatible.  

What do the rest of the folks say?  Marc?  Eric?  Does it move things
in the direction you want?  

Brian Goetz wrote:

>>Please don't yell at me - as far as I can see I think this is what Lane and 
>>I are converging on, if nobody else.
>>    
>>
>
>The direction is nice.  It has one quite serious flaw -- there can be
>only one auto-loader.  This seems like a crippling limitation, but
>fortunately there's a relatively easy fix.  See the proposal I put on
>that page.
>
>I estimate that I could implement this in a 100% backward compatible
>way in about an hour, with no additional performance overhead.  So its
>got to be pretty simple :)
>
I really would like to implement this. The other discussions about #use 
and template-based configuration are vast changes. This change makes for 
the context tool thingie now completely pluggable. That is a step in the 
right direction: if you don't want a context tool loaded from the 
configuration, they go away. If you like it this way (i REALLY  do), 
then you get to have it and plug your own context loader in.

-Lane

>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>  
>

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga

Wow, twice this week that I agreed with Lane!

On Sun, Jul 27, 2003 at 11:37:37PM -0700, Lane Sharman wrote:
> ...
> 
> Eric B. Ridge wrote:
> 
> > 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. 
> 
> I think we are getting off track by using the term magic. It ain't magic 
> that one can ship defaults, override them at deployment 
> (webmacro.properties), and have the resultant environment respected at 
> runtime. That's not magic, it is custom application functionality with 
> little overhead and efficient execution at runtime. I do not want to see 
> templates become the place of intense evaluation and build overhead.
> 
> When I ship a WM application, do I want every template to be forced to 
> build against some mondo include file that specifies every possible 
> template tool and function that i might need!
> 
> In release 2.0, let's focus on making WebMacro.properties the place 
> where application configuration is accomplished and efficiently built 
> into the runtime. This file, using package specs as Brian proposed, 
> keeps template writers from having to become configuration specialists.
> 
> I am not against a convenience global include. However, I really dislike 
> making the template space where WM configuration is established. A 
> template is a template. Better documentation is what we need.
> 
> Reengineering WM for the sake of moving configuration specs into a set 
> of globals includes? Negative.
> 
> Moving some of the defaults out of webmacro.defaults and making them 
> explicit in webmacro.properties. Maybe.
> 
> -Lane

...

Eric B. Ridge wrote:

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

I think we are getting off track by using the term magic. It ain't magic 
that one can ship defaults, override them at deployment 
(webmacro.properties), and have the resultant environment respected at 
runtime. That's not magic, it is custom application functionality with 
little overhead and efficient execution at runtime. I do not want to see 
templates become the place of intense evaluation and build overhead.

When I ship a WM application, do I want every template to be forced to 
build against some mondo include file that specifies every possible 
template tool and function that i might need!

In release 2.0, let's focus on making WebMacro.properties the place 
where application configuration is accomplished and efficiently built 
into the runtime. This file, using package specs as Brian proposed, 
keeps template writers from having to become configuration specialists.

I am not against a convenience global include. However, I really dislike 
making the template space where WM configuration is established. A 
template is a template. Better documentation is what we need.

Reengineering WM for the sake of moving configuration specs into a set 
of globals includes? Negative.

Moving some of the defaults out of webmacro.defaults and making them 
explicit in webmacro.properties. Maybe.

-Lane

> Please don't yell at me - as far as I can see I think this is what Lane and 
> I are converging on, if nobody else.

The direction is nice.  It has one quite serious flaw -- there can be
only one auto-loader.  This seems like a crippling limitation, but
fortunately there's a relatively easy fix.  See the proposal I put on
that page.

I estimate that I could implement this in a 100% backward compatible
way in about an hour, with no additional performance overhead.  So its
got to be pretty simple :)

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

I think that in reality, getting this will be harder than it looks.
There was a lot of special macro-aware crap that had to go into
#include as macro; my guess is that we will have to add additional
tool-aware, bean-aware, and <future> aware code to #include as this
plan moves forward.  That means that the goal of stripping down WM to
a micro-kernel and moving all the other stuff to loadable modules is
harder than it looks.

But the bigger goal is a good one, and I'd like to explore it further,
but I don't think any of the current proposals really move us very far
in that direction.  How about turning ALL directives, tools,
functions, and macros into some sort of WM plugins?  We're close to
that in the core -- the config part is really the only part left.

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

Right, and the footer would do "context unstuffing" and unregister
anything that the header registered (or clean up anything the header
added.)  This gives us the cleanup mechanism some people wanted.  

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

I think we have the first, the second is easy to add but has nothing
to do with the current discussion (but I'd +1 it), and the third we
have.

http://www.webmacro.org/WebMacroDevelScratchPad

Please don't yell at me - as far as I can see I think this is what Lane and 
I are converging on, if nobody else.

I separated the ContextAware issue, right at the bottom. It's entirely 
unrelated to ContextTool.

Cheers

-- 
Marc Palmer
Contract Java Consultant/Developer

                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

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

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

Webmacro.properties lives outside of webmacro.jar now -- it is "application 
space."  You can turn off any default directive or tool now with a line in 
Webmacro.properties:
   ContextTool.List:

You can add your own directives and tools through Webmacro.properties now:
   ContextTool.MyTool: com.me.MyTool

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?

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

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.

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

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.

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

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

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

--
Brian Goetz
Quiotix Corporation
br...@qu...           Tel: 650-843-1300            Fax: 650-324-8032

http://www.quiotix.com

On Thu, 24 Jul 2003 20:12:37 -0700, Lane Sharman <la...@op...> 
wrote:

> I think this meets the majority of the constraints. Not everyone but that 
> would be nigh impossible with this group on this particular subject. :).

This sounds very much like what I have been thinking of.

> btw: if you all agree to this in the next 24 hours, I will roger up to 
> get this done over the weekend.

How about we sketch this out in Wiki just to be 10000% sure everyone is 
with us. Last time I thought you and I were in agreement and it seems we 
weren't, at least in part!

-- 
Marc Palmer
Contract Java Consultant/Developer

                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

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

2002	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (4)	Nov (28)	Dec (47)
2003	Jan (103)	Feb (44)	Mar (65)	Apr (140)	May (72)	Jun (233)	Jul (466)	Aug (51)	Sep (2)	Oct (17)	Nov (1)	Dec (7)
2004	Jan (8)	Feb (5)	Mar (28)	Apr (9)	May (7)	Jun	Jul (7)	Aug	Sep	Oct (1)	Nov	Dec
2005	Jan (1)	Feb	Mar	Apr (3)	May (24)	Jun (7)	Jul (2)	Aug	Sep	Oct (4)	Nov (3)	Dec (12)
2006	Jan	Feb (3)	Mar (8)	Apr (59)	May	Jun	Jul	Aug (24)	Sep	Oct	Nov	Dec (3)
2007	Jan	Feb	Mar	Apr (8)	May	Jun	Jul (1)	Aug	Sep	Oct	Nov (7)	Dec (3)
2008	Jan	Feb (1)	Mar (16)	Apr (2)	May (2)	Jun	Jul (11)	Aug (3)	Sep (9)	Oct (9)	Nov (44)	Dec (34)
2009	Jan (12)	Feb (14)	Mar (11)	Apr (16)	May (41)	Jun (19)	Jul (33)	Aug (8)	Sep (3)	Oct	Nov	Dec (7)
2010	Jan (8)	Feb (50)	Mar (3)	Apr (2)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (16)	Dec
2012	Jan	Feb	Mar	Apr (3)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

webmacro-devel Mailing List for WebMacro (Page 22)

webmacro-devel — Discuss development issues related to the core of WebMacro