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

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

[Marc P. <ma...@an...>]

On Sun, 27 Jul 2003 16:01:23 -0700, Brian Goetz <br...@qu...> wrote:

[snip]
> 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.

I think this point is very good - please see Ignition's online help! It 
doesn't handle directives etc because currently there is no metadata to 
provide nice descriptions of directives etc. This might be a nice addition.

However, dumping of this info is beyond WM's remit in my opinion.

What WM needs to do is provide a way for any application to ask WM (rather 
the Broker) what tools, directives etc are available - so that the 
application can decide how to show the "documentation".

That is a separate thread :)

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

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

[Brian G. <br...@qu...>]

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

This file would have to live somewhere.  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

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

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

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

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



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

http://www.quiotix.com

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

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

On Sunday, July 27, 2003, at 06:38  AM, Brian Goetz wrote:

>> 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
>
> In actual practice, what applications are likely to do is take the
> union of all tools that _might_ be used in any template, put the above
> definitions into an include file, and then #include it in every
> template.  Which means that all the tools are going to show up in
> every context.

If we did it right, they'd only show up in the contexts that actually 
referenced them.

(Forget about #use for a minute.  Consider the possibility of simply 
making ContextTools template properties, and resolving them at build 
time.  We could keep all the configuration options that we currently 
have, and still get rid of the magical stuff in Context.java and 
Broker.java.)

The idea of #use was to move all the magical stuff into a single 
directive that could be easily turned off... rather than having it 
spread across various other source files.  Plus, we already support the 
concept of templates having #param-aters, so adding tools like this 
isn't far fetched.

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

> If the tool needs access to the context (such as for the HTTP
> Request/Response), then #use would have to add some run-time foo
> to initialize the tool, no?

yes, that's true.  I mentioned that already.

>> 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 they are stuffed into the context at the beginning of template
> evaluation, care must be taken with #include or #templet directives
> to deal with the case where template A includes tempalte B and both
> #use the same tool (or different tools but using the same name.)

Well sure.  But I don't see your point.  We'd have the ability to check 
for, and WARN about "unreferenced tools", and we'd have the ability to 
toss "Tool already defined" exceptions... two things we don't have now.

>> 1) #use definitions could be #included globally across an entire site
>
> I kind of like plug-ins as a way to get that effect

We don't have plug-in support, but we do have pluggable directives.... 
which #use would be.

>> 3) Definition of the tools is *explicit* per template... in the place
>> one would like to know what is available
>
> I think there'll be some disagreement on whether this is a step forward
> or backwards

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.

I'm not suggesting this can't be solved other ways (comments, the 
already existing #type directive, actual documentation, whatever), but 
it would solve lots of issues at once.

>> 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)
>
> It moves the magic into #use (and maybe also Template.write.)

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

>> 6) It gives us the ability to do build-time optimizations based on if
>> these things are actually referenced
>
> In reality, the current lazy-loading is likely to be moe efficient

How so?  If instances of Tools are created at template *build time*, 
then it's only happening once.  The majority of useful tools we 
currently have are essentially singletons.  Of course there's $Form, 
$Request and $Response, but that's where the Template.write() thing 
comes into play.

Also, we can catch tool-related exceptions (or throw our own) before 
the template begins to render.

>> 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.
>
> Of course, this is easily added to the existing tools mechanism too

of course.  :)

eric

Re: [Webmacro-devel] AHA! The source of confusion?!

[Lane S. <la...@op...>]

Marc,

My original proposal addresses this.

You can sublcass, for example, the default AutoContextLoader. With a 
sublcass, you can load your own helpers from whereever you please. You 
can use the superclass method to load standard tools without writing any 
of the code.

-Lane

Marc Palmer wrote:

>
> I think I see what has been a major confusing factor!
>
> I have always been suggesting a scheme were LazyVariableFactory (or 
> whatever) is represented as a single-instance that can create an 
> instance of any Object as defined by its implementation.
>
> For example:
>
> DefaultContextToolVarFactory would load ContextTools from settings as 
> WM does now, and would call into each ContextTool to get instances of 
> objects to return to the context.
>
> This is in effect using two "factory" mechanims - 
> LazyVariableFactory.getVariable(String name, Context) and 
> ContextTool.init(Context).
>
> However, the design I have been putting forward is also meant to 
> operate in a far simpler manner with only one factory level.
>
> MyContextAwareVarFactory would load a list of classes that implement 
> ContextAware, and call ContextAware.init(Context) on them before 
> returning them to Context.
>
> The key difference here is:
>
> public interface ContextTool
> {
>    public Object init (Context c) throws PropertyException;
> }
>
> Whereas:
>
> public interface ContextAware
> {
>    public void init (Context c) throws PropertyException;
> }
>
> i.e. ContextAware.init is a method for initialising an EXISTING 
> object, not returning a new one, not a FACTORY.
>
> Note "VOID". I missed this fine distinction in my examples, despite 
> knowing that ContextTool does this! I think this simple fact has been 
> a major confusing issue in all this.
>
> That's why I was calling LazyVariableFactory a factory!
>
> This is a more generalised approach, and is what I intended all along 
> - but due to forgetting the signature of ContextTool I neglected to 
> mention it! I feel a degree of relief here, 'cos even if you guys 
> still don't like my plan, I know that much of the confusion has been 
> down to a simple mistake, not generic cluelessness (on my part).
>
> Maybe with this in mind my ramblings make more sense? Of course we 
> can't push init() from ContextTool up into ContextAware - that won't 
> work so scratch that.
>
> * ContextAware and ContextTool would co-exist. ContextAware so that 
> Context can init any variables passed in by the app (overloaded put()).
>
> * Context.internalGet would not do any init(this) calls to get tools - 
> it would just call LazyVariableFactory.getVariable( name, this) which, 
> if required, would init any tools.
>
> * Context would not longer need to reference ContextTool at all, only 
> ContextAware (for the overloaded put) and LazyVariableFactory
>
> The great thing about this generalised approach is:
>
> 1. It can handle our existing ContextTool mechanism, via a 
> LazyVariableFactory impl that implements the current CT scheme.
>
> 2. It can handle a factory that creates any kind of object - 
> ContextAware or not - the implementation is up to the programmer. You 
> get lazy tools without implementing any specific interface.
>
> This latter point is -really- good. It means, for example, that 
> framework apps can provide lazy loading of all their helper classes, 
> whether they need to know about the Context or not - and with no 
> config in WM properties and no special interfaces for the helper objects.
>
> Let's hope this strikes a better note with you guys. It is exactly the 
> same thing I've been going on about, but now with this 
> ContextTool/ContextAware confusion sorted out, hopefully it makes more 
> sense.
>
> If you're still fuzzy on this, I can do another (correct) pseudocode 
> thing tomorrow.
>
> Marc


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

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

[Lane S. <la...@op...>]

...

Eric B. Ridge wrote:

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

My proposal eliminates this magic if you do not like it.

EnableAutoContextLoading: False
in WebMacro.properties will eliminate the magic. So, for new 
applications that do not want CT as a factor in their WM Systems, my 
prop gives you this.

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

I think this is a nice 2.1 or 2.2 idea as the next migration path away 
from "magic" context tools. Once you disable them, clearly we need to 
design a scheme like the above. The only concern I have immediately with 
this and the remainder of the proposal is the performance hit you will 
incrementally incur as you move configuration directives into a 
per-template basis.

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

When writing a concrete template you have to fish through your include 
list. It will not be in your current editor window. You have to organize 
your includes to avoid multiple references to the same included file. 
Includes result in a new kind of configuration maintenance.

Personally, I would rather declare a tool/function in a configuration 
file once and have it there when/if I needed it. It is one less thing I 
have to explain to the template writer about what he has to do or not do

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

Don't you feel it is important to the user base to allow most templates 
pre-release 2 to run as-is in release 2?


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

Again, these optimizations come at an expense.

>
> 7) It puts the power of tool use into the hands of the template 
> designer (this could be a disadvantage too) 

I do not want to explain javaesque stuff to the user where it is 
unneeded. As the system architect, I want to encapsulate out as much of 
the Java syntax (creation, destruction) as possible.

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

This is a management feature. Nice to have.

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

I still believe my incremental proposal is a better 2.0 solution than 
this compatibility breaking motor.

-Lane

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

Re: [Webmacro-devel] Re: ContextTool replacement - pseudo code to clarify

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 19:38:53 -0700, Lane Sharman <la...@op...> 
wrote:

>> Agreed. As stated elsewhere, I just did this to try to keep inline with 
>> existing WM design. Everything I says pisses everyone off, so I thought 
>> I'd try to throw myself a bone!
>
> Nobody is pissed off, Marc. We are just all trying to get to some 
> closure. Sometimes you get some English wind in your posts and they take 
> us where we have a hard time following. You may be a bit sleep deprived 
> :).

:) Nah I'm not thanks. My mails perhaps seem overly serious, but it's just 
because you don't know me in person. I'm very light-hearted and I meant the 
above in a lightheared way :)

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

Re: [Webmacro-devel] ContextTool replacement and thread-safety

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 22:34:34 -0400, Keats <ke...@su...> wrote:

> Marc Palmer wrote:
>
>>
>> public interface MyAppContextAwareObject
>> {
>> void init( o.w.Context ctx, MyApplication myapp);
>> }
>>
>
> We need to be a bit careful here; I think this construction could 
> encourage some concurrency problems.  It seems to imply that you can 
> reuse the same instance across multiple requests/contexts, which you 
> cannot safely do.

That example is just a trival interface to show that the approach I was 
suggesting confers us compatiblity and greater flexibility. If application 
X wants to use and interface like that shown above for their lazy variables 
they can, it's up to them.

Of course sane people would not use and interface, and would instead do:

public abstract class MyAppContextAwareObject
{
	public MyAppContextAwareObject( o.w.Context ctx, MyApplication myapp) { 
... }
}

Which solves your problem. The MyAppLazyVarFactory impl would just create 
objects of this type.

> The factory (non-void) version implies that you are creating a new object 
> on each request that is initialized with the context, which is the way it 
> must be done to ensure thread-safety.

Yes, but it's up to the app-writer what interface they use, and an approach 
like this - if they want to use it - means they don't need "two levels of 
factory", if you catch my drift.

> This necessary object creation is precisely why I suggested the context- 
> aware function as more efficient alternative.

I think context-aware functions are a completely separate idea, definitely 
with merit.

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

Re: [Webmacro-devel] Re: ContextTool replacement - pseudo code to clarify

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 19:29:35 -0700, Lane Sharman <la...@op...> 
wrote:

>> On Sat, 26 Jul 2003 13:46:36 -0700, Lane Sharman <la...@op...> 
>> wrote:
>>
>>
>> Context doesn't need to know about ContextTools however.
>
> This above statement is so confusing as to border on the curious. 
> Context.get(Object, Object) directly checks for a tool not in the context 
> and, if one is specified by the key, the tool value is placed in the 
> context. That is the way it works and this cannot be changed unless you 
> want to break backward compatibility. Could some other use for context 
> loading on a "fault" be dreamed up. Cannot think of one off hand.

Yes - any kind of application-supplied object that needs to be created, 
without following the ContextTool model - for example. And moving it all 
out of Context means you can completely avoid it all too.

i.e. Context.internalGet would, if no var is found, see if it has a 
LazyVariableFactory, and if so ask that for an new instance for that 
variable name (AKA tool).

Nothing else is required in my mind.

That's why I say that Context doesn't need to know about ContextTool at 
all, only about LazyVariableFactory.

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

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

[Brian G. <br...@qu...>]

> 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

In actual practice, what applications are likely to do is take the
union of all tools that _might_ be used in any template, put the above
definitions into an include file, and then #include it in every
template.  Which means that all the tools are going to show up in
every context.

> #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 the tool needs access to the context (such as for the HTTP
Request/Response), then #use would have to add some run-time foo
to initialize the tool, no?

> 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 they are stuffed into the context at the beginning of template
evaluation, care must be taken with #include or #templet directives
to deal with the case where template A includes tempalte B and both
#use the same tool (or different tools but using the same name.)

> 1) #use definitions could be #included globally across an entire site

I kind of like plug-ins as a way to get that effect

> 3) Definition of the tools is *explicit* per template... in the place 
> one would like to know what is available

I think there'll be some disagreement on whether this is a step forward
or backwards

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

It moves the magic into #use (and maybe also Template.write.)

> 6) It gives us the ability to do build-time optimizations based on if 
> these things are actually referenced

In reality, the current lazy-loading is likely to be moe efficient

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

Of course, this is easily added to the existing tools mechanism too

[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

Re: [Webmacro-devel] ContextTool replacement and thread-safety

[Keats <ke...@su...>]

Marc Palmer wrote:

> 
> public interface MyAppContextAwareObject
> {
>    void init( o.w.Context ctx, MyApplication myapp);
> }
> 

We need to be a bit careful here; I think this construction could 
encourage some concurrency problems.  It seems to imply that you can 
reuse the same instance across multiple requests/contexts, which you 
cannot safely do.

The factory (non-void) version implies that you are creating a new 
object on each request that is initialized with the context, which is 
the way it must be done to ensure thread-safety.

This necessary object creation is precisely why I suggested the 
context-aware function as more efficient alternative.

Keats

Re: [Webmacro-devel] Re: ContextTool replacement - pseudo code to clarify

[Keats <ke...@su...>]

I think you are zeroing in on a critical distinction here.  The context 
tool "load on fault" mechanism allows you to avoid the overhead of 
creating new instances of context-aware objects.  Putting context aware 
factories into each request would accomplish the same thing, but with 
higher overhead.  (Actually this is virtually equivalent to the way it 
worked prior to Brian's latest changes, since the factories, CTs, were 
kept in a map within each context.)  It's really a "pull" verses "push" 
provisioning model.

Keats

Lane Sharman wrote:

> 
> 
> Marc Palmer wrote:
> 
>> On Sat, 26 Jul 2003 13:46:36 -0700, Lane Sharman <la...@op...> 
>> wrote:
>>
>>
>> Context doesn't need to know about ContextTools however.
> 
> 
> This above statement is so confusing as to border on the curious. 
> Context.get(Object, Object) directly checks for a tool not in the 
> context and, if one is specified by the key, the tool value is placed in 
> the context. That is the way it works and this cannot be changed unless 
> you want to break backward compatibility. Could some other use for 
> context loading on a "fault" be dreamed up. Cannot think of one off hand.
> 
> -Lane
> 
> 

Re: [Webmacro-devel] Re: ContextTool replacement - pseudo code to clarify

[Lane S. <la...@op...>]

Marc Palmer wrote:

> On Sat, 26 Jul 2003 12:54:57 -0700, Brian Goetz <br...@qu...> 
> wrote:
>
> Agreed. As stated elsewhere, I just did this to try to keep inline 
> with existing WM design. Everything I says pisses everyone off, so I 
> thought I'd try to throw myself a bone! 

Nobody is pissed off, Marc. We are just all trying to get to some 
closure. Sometimes you get some English wind in your posts and they take 
us where we have a hard time following. You may be a bit sleep deprived :).

-Lane

Re: [Webmacro-devel] ContextTool replacement and thread-safety

[Lane S. <la...@op...>]

Marc Palmer wrote:

> On Sat, 26 Jul 2003 13:48:56 -0700, Lane Sharman <la...@op...> 
> wrote:
>
>
>>> We only need one setting, for the auto tool provider.
>>
>>
>> Negative. You need an explicit boolean property and then a dependent 
>> value. The null value means in many settings "no class defined, use 
>> the default.".
>
>
> I'm pretty sure Brian has addressed this with some settings already. 
> It seems silly to require both if we can avoid it. 

Like I said, the null value for a property does not disable 
functionality. For folks to disable ContextTool processing, an explicit 
Boolean Property set to false in WebMacro.properties is far more legible.

EnableAutoContextToolProcessing: false

Let's leave this one as proposed.

-Lane

>
>
> Marc
>

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

Re: [Webmacro-devel] Re: ContextTool replacement - pseudo code to clarify

[Lane S. <la...@op...>]

Marc Palmer wrote:

> On Sat, 26 Jul 2003 13:46:36 -0700, Lane Sharman <la...@op...> 
> wrote:
>
>
> Context doesn't need to know about ContextTools however.

This above statement is so confusing as to border on the curious. 
Context.get(Object, Object) directly checks for a tool not in the 
context and, if one is specified by the key, the tool value is placed in 
the context. That is the way it works and this cannot be changed unless 
you want to break backward compatibility. Could some other use for 
context loading on a "fault" be dreamed up. Cannot think of one off hand.

-Lane

Re: [Webmacro-devel] Re: ContextTool replacement - pseudo code to clarify

[Lane S. <la...@op...>]

Marc Palmer wrote:

> On Sat, 26 Jul 2003 13:46:36 -0700, Lane Sharman <la...@op...> 
> wrote:
>
> I'm really not sure. I was using Provider terminology because I 
> thought you guys would prefer that - in keeping with existing WM 
> paradigms.
>
> Will this, in your mind, be a 100% replaceable mechanism for returning 
> new instances of objects only when required, with only one instance of 
> this "factory" per Broker? 

Yes. There will be one instance per broker. This is in my original proposal.

-Lane

Re: [Webmacro-devel] ContextTool replacement and thread-safety

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 13:55:14 -0700, Brian Goetz <br...@qu...> wrote:

>> Why do we need any of this magical stuff in WebMacro?
>>
>> > So - magic everywhere, or nowhere?
>>
>> Come on Marc, who's side are you on here?  :)  Magic *nowhere*
>>
>
> This seems like a conversation worth having.  I think that while you
> and Marc agree on the idea of ditching (or at least demoting) CT, your
> motivations are different.
>
> Lets talk about this magic thing.  I have always thought that the
> magic "architect selects tools { X, Y, Z } and makes them available
> transparently in all contexts" to be a powerful feature.  Velocity has
> a similar mechanism for loading global macros (which we should have
> too.)

Yes it is, but it should be optional - i.e. replace the LazyVariableFactory 
with your own mechanism for this - app specific class interfaces perhaps... 
i.e.

public interface MyAppContextAwareObject
{
    void init( o.w.Context ctx, MyApplication myapp);
}

> You seem to think its bad, and not in the user's best interest.
> Explain.

As above, and other posts. Crank up the flexilibility, and clean up the 
model at the same time.

:)

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

Re: [Webmacro-devel] ContextTool replacement and thread-safety

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 13:49:18 -0700, Brian Goetz <br...@qu...> wrote:

>> I give up. We're chasing in circles.
>
> After all this effort, I am really wondering what concrete gain the
> user community gets out of this.  No one has (yet) put forward
> compelling use cases for why we would want lazy-loading for anything
> other than tools, or why the tools interface is inadequate, or what
> other context-aware thingies besides tools there are.  That's not to
> say there aren't any -- but I think the thing we're all struggling
> with is that we don't know why we're talking about this.  At least I
> don't.

Please see my latest "AHA! ..." post on this. It might solve some confusion 
:)

> I know that there are things about ContextTool which are aesthetically
> displeasing.  But I'm struggling to see how the WM user community will
> be better off in a year if we do this now.  (Making the code
> incrementally cleaner is not a strong enough motivator.)

I think my new post shows this - applications can add lazy variables of any 
kind they like, not having to implement ContextTool factories, and 
optionally implementing ContextAware on those objects if they do need the 
Context.

> I think this is the problem -- I guess I need to see how the users
> will benefit, but I don't yet.
>
> And therein is the problem.  I think it is just premature to talk
> about code changes without a clear, shared idea of how the users will
> benefit.  Anything else is putting the code before the horse.

Yes, completely correct. Lane might have been implementing something by now 
if we hadn't continued the discussion :)

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

[Webmacro-devel] AHA! The source of confusion?!

[Marc P. <ma...@an...>]

I think I see what has been a major confusing factor!

I have always been suggesting a scheme were LazyVariableFactory (or 
whatever) is represented as a single-instance that can create an instance 
of any Object as defined by its implementation.

For example:

DefaultContextToolVarFactory would load ContextTools from settings as WM 
does now, and would call into each ContextTool to get instances of objects 
to return to the context.

This is in effect using two "factory" mechanims - 
LazyVariableFactory.getVariable(String name, Context) and 
ContextTool.init(Context).

However, the design I have been putting forward is also meant to operate in 
a far simpler manner with only one factory level.

MyContextAwareVarFactory would load a list of classes that implement 
ContextAware, and call ContextAware.init(Context) on them before returning 
them to Context.

The key difference here is:

public interface ContextTool
{
    public Object init (Context c) throws PropertyException;
}

Whereas:

public interface ContextAware
{
    public void init (Context c) throws PropertyException;
}

i.e. ContextAware.init is a method for initialising an EXISTING object, not 
returning a new one, not a FACTORY.

Note "VOID". I missed this fine distinction in my examples, despite knowing 
that ContextTool does this! I think this simple fact has been a major 
confusing issue in all this.

That's why I was calling LazyVariableFactory a factory!

This is a more generalised approach, and is what I intended all along - but 
due to forgetting the signature of ContextTool I neglected to mention it! I 
feel a degree of relief here, 'cos even if you guys still don't like my 
plan, I know that much of the confusion has been down to a simple mistake, 
not generic cluelessness (on my part).

Maybe with this in mind my ramblings make more sense? Of course we can't 
push init() from ContextTool up into ContextAware - that won't work so 
scratch that.

* ContextAware and ContextTool would co-exist. ContextAware so that Context 
can init any variables passed in by the app (overloaded put()).

* Context.internalGet would not do any init(this) calls to get tools - it 
would just call LazyVariableFactory.getVariable( name, this) which, if 
required, would init any tools.

* Context would not longer need to reference ContextTool at all, only 
ContextAware (for the overloaded put) and LazyVariableFactory

The great thing about this generalised approach is:

1. It can handle our existing ContextTool mechanism, via a 
LazyVariableFactory impl that implements the current CT scheme.

2. It can handle a factory that creates any kind of object - ContextAware 
or not - the implementation is up to the programmer. You get lazy tools 
without implementing any specific interface.

This latter point is -really- good. It means, for example, that framework 
apps can provide lazy loading of all their helper classes, whether they 
need to know about the Context or not - and with no config in WM properties 
and no special interfaces for the helper objects.

Let's hope this strikes a better note with you guys. It is exactly the same 
thing I've been going on about, but now with this ContextTool/ContextAware 
confusion sorted out, hopefully it makes more sense.

If you're still fuzzy on this, I can do another (correct) pseudocode thing 
tomorrow.

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

Re: Re: [Webmacro-devel] ContextTool replacement and thread-safety

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 21:10:00 +0100, Marc Palmer <ma...@an...> wrote:

>> As far as the latter, you are so far from convincing me (and I think
>> everyone else) that we need to inspect and potentially call methods on
>> everything that gets put() into the context that you should probably
>> consider that concept vetoed.
>
> I know - my point is that this should be EITHER/OR. I firmly believe, if 
> everyone thinks that Context should now do the instanceof ContextAware 
> thing - alternative overriden put() is a better solution - that Context 
> should not do a check for ContextTool(s) and init them - the abstracted 
> factory logic should do this.

Sorry - that should read:

I know - my point is that this should be EITHER/OR. I firmly believe, if 
everyone thinks that Context should NOT do the instanceof ContextAware 
thing in put() - alternative overriden put() is a better solution - that 
Context should not do a check for ContextTool(s) and init them - the 
abstracted factory logic should do this.

...but that is the last I will say on this. We're arguing about 2 lines of 
code, the net effect of which will be identical, it just affects the 
modularity of the LazyVariableProvider.

Adios, I'm off to bed. I can't wait for my recurring ContextTool 
nightmare... oh no, that's the waking hours!

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

Re: [Webmacro-devel] Re: ContextTool replacement - pseudo code to clarify

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 12:54:57 -0700, Brian Goetz <br...@qu...> wrote:

>> However all these changes really are relatively trivial - moving 
>> loadTools from Broker is the "biggest" job. I'm happy to do all this if 
>> you guys agree on the plan, if Lane isn't fussed about doing it. It 
>> would seem fitting that I have to do is, since I was the main 
>> protagonist in all this rucus.
>
> This seems mostly reasonable, see comments inline.  However, this
> seems nothing like your original proposal.  What you've done is
> renamed ContextTool, not gotten rid of it.  Now, perhaps that's what
> you meant all along, but that's certainly not what it sounded like you
> were proposing.

Well this is certainly what I had in mind all along, and believe I put it 
into words in that mail of Thursday which I quoted earlier today.

>> --- New file: ContextAware.java
>
> What does "context aware" mean?  Can any provide three examples of
> something that is context aware that is not context tools?  I still
> don't get the need for this concept beyond the existing tool
> mechanism.

As Lane is now saying, along with your suggestion, Context.put( String 
name, ContextAware obj) is a nice thing to have. It's less work for the 
caller - they can take off the shelf objects that impl ContextAware and put 
them into the context without having to init them themselves.

>> --- New file: LazyVariableProvider.java I think this is the name that 
>> fits the functionality best, getting away from the ContextTool 
>> terminology, using WM provider terminology
>>
>> public interface LazyVariableProvider extends Provider
>> {
>> Object getVariable( String name, Context context);
>> }
>
> Good concept, but took a wrong turn somewhere.  If you are going to be
> a Provider, be a Provider.  Implement the Provider interface and
> that's it.  Me, I personally think that the Provider framework is a
> terrible abstraction (I think you think this too) because it forces
> everyone who uses it to make all sort of hidden casting assumptions.
> This one is even worse -- its not really even a provider, since the meat 
> of it is in an extra method that is outside Provider.

Agreed. As stated elsewhere, I just did this to try to keep inline with 
existing WM design. Everything I says pisses everyone off, so I thought I'd 
try to throw myself a bone!

> In other words, either use Provider the way the rest of WM does
> (personally, I'd like to see the rest of WM use it less, until it gets
> to the point where it withers and dies on its own) or just define
> the factory you need.

OK, factory we need. Same as above then, but without "extends Provider".

> In any case, I don't think Context belongs in this interface.

Why? My whole idea is that this loader can act on information in the 
context to create new instances of objects (for instance access the Locale 
via a WebContext perhaps), and can automatically init any objects they 
create so they know about the context.

Through this mechanism Context.java no longer needs to know about 
ContextTool, only LazyVariableProvider (sic).

>> --- New file: DefaultContextToolProvider.java The default impl providing 
>> existing CT functionality by excised from core of WM
>
> Why?  Why can't you just LEAVE IT THERE?  If its so worthless, it will
> die of its own.

I have said this so many times now. By moving it out into an impl of 
LazyVariableProvider (sic) we give the application complete control over 
this mechanism.

For example my web framework my have some special lazy tool mechanism that 
creates tools with a reference to a framework object, PLUS the Context 
instance.

I may never want users to be able to specify ContextTools in the config due 
to an alternative mechanism in my framework, and as such would want to 
suppress completely the LazyVariableProvider (sic) mechanism by wiping the 
property.

This is the most flexible way to achieve this, I think.

>> --- Context.java Modifications....
>
>> Object tool = null;
>> if (lazyVariableProvider != null)
>> tool = lazyVariableProvider.getVariable( name, this);
>>
>> if (tool != null) {
>> // Remove this code if we decide Context will not handle this kind of 
>> thing
>> if (tool instanceof ContextAware)
>> ((ContextAware)tool).init(this);
>> }
>
> I think this is OK here, but not in the put() call.  Putting it in the
> put() call is totally magic!  (If the object implements this
> interface, then this magic thing happens.)

Yes, agreed about put() - but I think the above code shold be in the 
"existing ContextTool emulation" impl of LazyVariableProvider. But hey, you 
knew that already.

>> public final Object put (Object name, Object value)
>> {
>> // Remove this code if we decide Context will not handle this kind of 
>> thing
>> if (value instanceof ContextAware)
>> ((ContextAware)value).init( this);
>> return _variables.put(name, value);
>
> You can't put this here.
>
> However, you could add this:
> public Object put(Object name, ContextAware value) { }
>
> like the auto-wrapping we have for int and other primitives.

100% Agreed.


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

Re: [Webmacro-devel] ContextTool replacement and thread-safety

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 17:55:07 -0400, Keats <ke...@su...> wrote:

> There are so many points to respond to here it's a bit daunting but let 
> me mention a couple things.
>
> Marc, I think you have missed a crucial part of the ContextTool 
> mechanism.  ContextTool *is* a lazy loading factory mechanism.  The 
> init() method is not void; it returns an object.  Many tools just return 
> themselves, but this is just a convenience.  A context tool provides 
> arbitrary objects to the context, which may or may not have "context 
> awareness".

No, I get all that! You've definitely misunderstood my posts.

> I see three major shortcomings to the ContextTool mechanism:
>
> 1) Tools can only be configured through properties and can't be 
> dynamically deployed.  This can be easily fixed using a the 
> ConcurrentMap.

This isn't a concern I have. Nothing in WM apart from templates can be 
dynamically deployed, so I don't think this is a major issue.

However, an abstracted factory for instantiating tools lets the application 
decide if it wants to support changes to the tools available at runtime.

I don't think it's something WM needs to worry about - let the application 
control it.

> 2) A ContextTool implementation (factory) class gets instantiated on each 
> request in which it is referenced.  Although they are generally 
> lightweight classes, this is still unnecessary overhead.  Factories 
> should generally be static.  This should be easy to fix as well.

Well the idea is to abstract this to a single instance per Broker, of 
something like AutoContextLoader/LazyVariableFactory which is resposible 
for creating instances of any of the configured "lazy" tools (read 
ContextTools).

I believe this is what Lane and I have both proposed.

> 3) ContextTools are too magical, i.e, it's not clear to a 
> developer/scripter what's available and how to use them.  This was a 
> primary motivation for developing the #beam mechanism.
>
> But the bean mechanism is flawed as well.  A #bean basically does two 
> things that should be separate: Configuring an object and pulling the 
> object into the context.   Most people seem to agree that configuring the 
> object should not happen in the template.  On the other hand creating the 
> reference to the object probably *should* happen in the template.  This 
> makes it clear to the template developer that these things are there and 
> will be used in the template.
>
> So maybe the answer to problem 3) is to require tools to be declared in 
> the template before they are used.  Maybe a directive like #tool, or 
> #import, or #use.  E.g.,
>
> #use $Math
>
> or
>
> #use "MathTool" as $Math
>
> or something and then, $Math would get put into the context (assuming 
> that MathTool had been deployed to the app previously somehow).
>
> This would simplify the context logic: get() wouldn't need to know about 
> tools at all.  And templates would become more readable.

Hmm, interesting. It would enable apps to determine at template load time 
if any tools are not available, and hence not even try to render the 
template.

> On the downside, lot's of old templates would break and some people might 
> be annoyed at having to declare commonly used tools in every template.  
> The latter problem could be mitigated by #including "header" templates 
> that declare common tools (like $Request, $Response, $Session, $Form, 
> etc.).

True. Still, we have pretty much decided we mustn't break anything in 2.0 
with CTs...

> To deal with the backwards-compatability issue we could allow users to 
> define "AutoLoadingTools" which get put into every context.  This would 
> be less efficient than the current mechanism, but it wouldn't be too bad 
> and it would ease the transition to the new paradigm.
>
> What do y'all think?

Certainly interesting. I'm gonna hang back and watch because I'm tired of 
arguing about this stuff right now - and I seem to be at a tangent to most 
people on this :(

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

Re: [Webmacro-devel] ContextTool replacement and thread-safety

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 13:48:56 -0700, Lane Sharman <la...@op...> 
wrote:


>> We only need one setting, for the auto tool provider.
>
> Negative. You need an explicit boolean property and then a dependent 
> value. The null value means in many settings "no class defined, use the 
> default.".

I'm pretty sure Brian has addressed this with some settings already. It 
seems silly to require both if we can avoid it.

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

Re: [Webmacro-devel] Re: ContextTool replacement - pseudo code to clarify

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 13:46:36 -0700, Lane Sharman <la...@op...> 
wrote:

> First: We WILL have Context Tools operational in Release 2. Period.

I never said we shouldn't. My whole proposal was to keep all you CT 
advocates happy and keep it in 2.0! I can't believe I am still failing to 
get this across, despite source code examples showing this.

Context doesn't need to know about ContextTools however.

> Second: I will only defer to Marc's implementation if he keeps to the 
> originally laid out spec. For example, I want an explicit boolean 
> property as well as the class name because this makes things more clear 
> to the property editor and allows for some optimizations.

I'm not asking anyone to defer anything. I'm just trying to see that we've 
all got the same thing in mind, and strangely it looks like we hadn't.

I just don't see the need for this extra property. I currently fail to see 
how having an "enabled" property offers us any optimizations over "factory 
== null". Maybe I'm missing something?

If factory name is blank in the config, we can set a boolean internally to 
true to indicate disabled, if you are concerned about avoiding a thread 
sync.

Please, if there is a genuine need for this property please show me!

> Third, Marc is seeking to slip a new feature into the put operation which 
> is a replacement for Keats function proposal of MethodObject(Context, 
> PrimaryObject). We need to keep things separate. I know that Keats 
> proposal has merit: it allows static, stateless use of the context. I am 
> not sure we are ready to bail on this proposal without some further 
> debate. So, do not add Context.put(Object, ContextAware) quite yet unless 
> Keats is ready to accept the possibility for both stateless and statul 
> use of the Context.

I'm not seeking to slip anything new in! That was part of my original 
proposal and I put it in the example source to show you what I mean - and I 
clearly showed that it could be removed with the caveat, that makes sense 
to me, that Context does not do any init() calls either, that the tool 
loader implementation does this.

> Brian is right-on about the put operation. Do NOT change the signature 
> Context.put(Object, Object). Rather, add Context.put(Object, 
> ContextAware) allowing method dispatching to eliminate unneeded 
> conditional processing. This provides a nice wrapper around objects which 
> need the context as a part of their state.

Absolutely. That approach hadn't occurred to me and I completely agree with 
it, it makes perfect sense.

> Lastly, this item is not about some general LazyVariableProvider. It is 
> about AutoContextLoading or AutoContextHandling. So, use a name like 
> that. Why use a name that harkens to some other Provider abstraction in 
> WM? With this implementation, meet the requirements, no more, no less.
>
> Are we there yet???

I'm really not sure. I was using Provider terminology because I thought you 
guys would prefer that - in keeping with existing WM paradigms.

Will this, in your mind, be a 100% replaceable mechanism for returning new 
instances of objects only when required, with only one instance of this 
"factory" per Broker?

If so, then we are definitely there! I don't really care what it's called.

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

Re: [Webmacro-devel] Is this a bug? More obscure #macro issues

[Marc P. <ma...@an...>]

On Sat, 26 Jul 2003 13:24:39 -0700, Brian Goetz <br...@qu...> wrote:

>> I'm not sure what we can do about this. I mistakenly thought #macro 
>> would have a separate context for its arguments, and as such changes to 
>> an outer variable would not suddently change the value of a differently 
>> named parameter to the macro.
>
> Nope, not how it works, nor how it was intended to work -- otherwise
> you couldn't have macros that modified their arguments.

That's why I said "mistakenly" in the above, and why I asked "Is this a 
bug".

>> So, is this a bug or a "feature"?
>
> Feature.  Just like C macros.  If you intend to have local variables,
> name them in such a way as to never conflict, just like in C.

Fine, and that's exactly what I suggested as the workaround. The point is, 
as much laboured before, that template writers will not get this. They are 
not C programmers.

Roll on #templet/#eval :)

> Macro-local variables would be nice -- want to add them?

Perhaps, although I'm more concerned with not having the values of 
arguments change because a global variable used as the value of that 
argument changed - i.e. snapshot the context somehow.

While macros have an optimisation advantage, I think this work would not be 
worthwhile when #templet is ready for prime time.

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