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

[Webmacro-devel] Can I change #count ?

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

Guys,

Can I change #count to support counting down as well as up, without 
specifying "step -1" ?

The docs on wm.org do not indicate that it only counts up but, or that a 
step is required to count doen:

#count 2003 to 1900

...produces no iterations unless you do:

#count 2003 to 1900 step -1

Now I can't immediately see any problems in doing this - i.e. when no step 
provided, calculate step +1/-1 based on whether "start" is lower or higher 
than "end".

It would just make #count that little bit easier to use.

Any objections?

-- 
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] Is this a bug? More obscure #macro issues

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

Hi,

I've just spent a long time tracking down an obscure template bug, caused 
by the non-intuitive way #macro works.

Examine the following code:

#macro badNews( $fieldValue )
   #set $value = "modified $fieldValue"
   Now \$fieldValue is: $fieldValue
#end

#set $value = "Hello"

Value before macro: $value
#badNews( $value )
Value after macro: $value


Most viewers of this code would expect it to output:

Value before macro: Hello
Now $fieldValue is: Hello
Value after macro: modified Hello

However this is not the case. Some obscure "pass by reference" effects are 
occurring in #macro such that the result is:

Value before macro: Hello
Now $fieldValue is: modified Hello
Value after macro: modified Hello


...even though there is never an assignment to $fieldValue in the macro. 
This is caused by the usage of the variable $value inside the macro, which 
is inadvertently clashing with the global scope $value - it is of course 
supposed to be a local variable, which is not supported by #macro.

The trouble is these problems are VERY hard to track down in complex 
templates. The only clue you might get is that a macro argument is 
bizarrely changing its type during macro execution (as I did) and as a 
result you get property errors (if you are lucky).

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.

So, is this a bug or a "feature"?

-- 
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] ContextTool replacement - pseudo code to clarify

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

Guys,

Just to make sure we are all reading from the same sheet now - I'm going to 
give some quick pseudo code for all the files involved. This is no doubt 
CONTENTIOUS! This is because the impl I am showing allows ContextAware 
detection for all variables placed into the context as well as "tools" 
loaded by the new factory/provider - something that has not yet been 
decided.

Don't dismiss these changes just on that basis - this is to 
illustrate/confirm the general plan outlined by Lane (and earlier by 
myself). We can easily not do the instanceof ContextAware stuff in 
Context.put, but in that case we should definitely NOT do the same for 
tools returned from the provider.

See comments inline.

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.


--- New file: ContextAware.java

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

--- ContextTool.java

public interface ContextTool extends ContextAware {
}

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

--- New file: DefaultContextToolProvider.java The default impl providing 
existing CT functionality by excised from core of WM

public class DefaultContextToolProvider implements LazyVariableProvider
{
    //... impl Provider methods of course, including loading //existing CT 
definitions ...

    public Object getVariable( String name, Context context)
    {
        if (toolNamesMap.contains( name))
	  {
            return newToolInstance(name);
// Note that without Context doing instance of in put for vars, we should 
then
// have the instanceof ContextTool code in here somewhere and init tools 
ourselves.
// instead of having Context do it.
        }
        else
        {
            return null;
        }
    }
}

--- Context.java Modifications....

public class Context implements Map, Cloneable
{
    //...existing context stuff skipped...

    /**
     * Get the named object/property from the Context. If the Object
     * does not exist and there is a tool of the same name then the
     * Object will be instantiated and managed by the tool.
     * If there's no such variable, it throws.
     */
    protected Object internalGet (Object name)
            throws PropertyException
    {
        Object ret = _variables.get(name);
        if (ret == null && !_variables.containsKey(name))
        {
 // **** some modifications to remove CT dependency here

            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);
            }
            else if (name instanceof FunctionCall)
            {
                FunctionCall fc = (FunctionCall) name;
                String fname = fc.getName();
                MethodWrapper func = null;
                if (_funcs != null) {
                    func = (MethodWrapper) _funcs.get(fname);
                }
                if (func == null)
                {
                    func = _broker.getFunction(fname);
                }
                if (func != null)
                {
                    Object[] args = fc.getArguments(this);
                    ret = func.invoke(args);
                }
                else
                {
                    _log.error("Function " + fname + " was not loaded!");
                }
            }
            else
            {
                // changed by Keats 30-Nov-01
                return UNDEF;
            }
            //throw new
            // PropertyException.NoSuchVariableException(name.toString());
        }
        return ret;
    }


    /**
     * Add an object to the context returning the object that was
     * there previously under the same name, if any.
     */
    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);
    }
}



-- 
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 00:20:41 -0700, Brian Goetz <br...@qu...> wrote:

>> interface ContextAware {
>>
>> init(Context c);
>> }
>> interface ContextTool extends ContextAware {}
>
> interface ContextTools extends ContextAware, LazyLoaderFactory { }

I think this is incorrect. The "s" at the end of ContextTool might mean you 
are trying to describe something else getting lost in a typo here.

If you mean to define ContextTool, it should only be:

interface ContextTool extends ContextAware

Then we also add:

class DefaultContextToolFactory implements LazyLoaderFactory { }

Which is the implementation containing the existing CT logic.


There is no reason for ContextTool itself to implement the factory 
interface - a ContextTool is just a single object placed into the context, 
and is not responsible for loading other objects.

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 Fri, 25 Jul 2003 18:05:00 -0700, Brian Goetz <br...@qu...> wrote:

>
>> In digesting your note, I think we are in violent agreement with my 
>> initial proposal, no more and no less,  which accomodates 
>> configurability of automatic context loading, provides compatibility in 
>> 2.0 with 1.x templates, and provides for pluggability of the auto 
>> context loader.
>
> I think Lane's incremental approach seems sound here.

Me too, although I still think we need to refine a few elements (i.e. the 
redundant config property).

Let me quickly revisit my original proposal (of Thursday last week) as 
people might get it a bit more now, and see the overlap with Lane's 
proposal:

---quoting original message---

Here's what I now propose, hopefully somewhat clearer:
 1. Remove all CT logic from Context/Broker etc
 2. Deprecate CT interface
 3. Make the CT interface empty, instead extending a new core interface 
ContextAware with the same init(context) method currently in CT. This 
retains compatibility with current CTs while deprecating the interface 
itself, and gains us further abstraction in ContextAware.
 4. We add an interface equivalent to LazyVariableFactory, with one method 
getVariable( name, context).
 5. We add simple logic (as shown earlier) to make Context/Broker do the 
work of looking for the single instance of this factory if available, thus 
replacing the current CT instantiation logic
 6. We put most of the excised CT login into an impl of LazyVariableFactory 
called ContextToolFactory and put this in some package like o.w.legacy or 
o.w.util.
 7. We add code to the new Context/Broker logic so that after asking the 
LazyVariableFactory for a variable instance and getting one succesfully we 
do:
 if (newvar instanceof ContextAware)
     ((ContextAware)newvar).init( this);
 8. We remove all context tool settings from WebMacro.defaults and put it 
in the shipped WebMacro.properties
 9. We put "LazyVariableFactory: org.webmacro.legacy.ContextToolFactory" 
into WebMacro.properties.
 10. Add get/setLazyVariableFactory(Class) to Broker/wherever so apps can 
supply custom handling.
 ---end quoting original message---

Now functionally the only difference between Lane's proposal and mine is 
that I:

* Proposed the deprecation of ContextTool, because ContextAware is better 
naming and is type compatible with it.

* I make some proposals about moving settings to WM.properties, which we 
have discussed since and will be irrelevant if the app can override the 
LazyVariableFactory (Lane's AutoToolProvider).

* I propose adding get/setLazyVariableFactory (AutoToolProvider) methods to 
Broker so application can define this factory at runtime (so it cannot be 
suppressed by the end user changing config).


See how we now seem to be agreeing on a re-worded version of my original 
proposal?

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 Fri, 25 Jul 2003 18:03:15 -0700, Brian Goetz <br...@qu...> wrote:

>
>> I don't really get this.  The way it works now is simple:
>
> Simpler than that, actually:
>
>> when resolving a variable reference:
>>
>> - check if the variable is in the context
>> - if yes, return the variable
>> - if not, check if it is a tool.
>> - if not, return undefined
>> - if yes, check if it has been initialized
>> - if no, initialize it
>> - else return the tool
>
> Actually, its "if its a tool, initialize it and put it in the context."  
> Then, subsequent passes through, it gets returned by step 1.

Precisely, which is the problem. This should be moved out into the 
provider's impl, OR left in and also applied to all variables added with 
put().

>> Let's take things one step at a time.  First let's allow tools to be 
>> dynamically deployed and discovered using the new super duper thread- 
>> safe map.  I think everybody likes this idea.  Then we can hash out any 
>> optimizations or simplifications on how they are accessed from the 
>> context.
>
> You speak wisely.

Indeed he does.

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 Fri, 25 Jul 2003 19:14:16 -0400 (GMT), Keats <ke...@su...> wrote:

> Marc,
>
> I don't really get this.  The way it works now is simple:
>
> when resolving a variable reference:
>
> - check if the variable is in the context
> - if yes, return the variable
> - if not, check if it is a tool.
> - if not, return undefined
> - if yes, check if it has been initialized
> - if no, initialize it
> - else return the tool
>
> (We'll there're also functions in there but you get the idea.)
>
> We can probably improve on this a bit, but the basic mechanism is sound.  
> Why would you want to check each variable to see if it is "ContextAware"? 
> Why would we want to load every tool into every request when nothing is 
> referencing it?  This is just extra overhead.

Keats, you've misunderstood. I never proposed that. I agree with the 
existing logic, HOWEVER as far as I am aware "initialize" is only performed 
on CONTEXT TOOLS - i.e. not on context VARIABLES added with context.put.

That's all I'm getting at. We should have consistency.

If the whole context tool instantiation mechanism is abstracted to a 
AutoToolProvider/LazyVariableFactory whatever you want to call it, then 
either:

1. the provider implementation should deal with calling init() on its tools 
if required (remember it may not instantiate ContextTool instances, they 
could be any object with any interface) and context does none of this

-or-

2. Context is modified to do this instanceof work and call init on BOTH 
tools returned from an tool provider/factory AND variables placed into the 
context with context.put()

Consistency is what I'm all about here.

> If you want somethig to be context-aware, make it a tool or a Macro 
> implementation (or a context-aware function if I can get people to agree 
> on that concept).

Are you saying that the current implementation WILL call init(Context) on 
any object placed into the context that implements a known tool/Macro 
interface, where the object is added with put() ?

> Let's take things one step at a time.  First let's allow tools to be 
> dynamically deployed and discovered using the new super duper thread-safe 
> map.  I think everybody likes this idea.  Then we can hash out any 
> optimizations or simplifications on how they are accessed from the 
> context.

OK - but the thread-safe map is not a strong requirement at this time. The 
existing ContextTool loading code can just be refactored out to the 
AutoXXXXProvider implementation.

Ugh, I wish I could just go and implement this all instead of haggling 
about it! I know that I am actually talking about a solution that you are 
all basically going to agree with, seeing as Lane's proposal is effectively 
the same as my 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

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

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

On Fri, 25 Jul 2003 16:23:54 -0700, Lane Sharman <la...@op...> 
wrote:

> In digesting your note, I think we are in violent agreement with my 
> initial proposal, no more and no less,  which accomodates configurability 
> of automatic context loading, provides compatibility in 2.0 with 1.x 
> templates, and provides for pluggability of the auto context loader.
>
> In raising the thread on Context aware methods (Keats proposal) and 
> objects (your proposal),  I think this is different enough from Context 
> Tools to merit a separate topic and discussion.
>
> For now, unless Keats and ebr violently object, I think my proposal for 
> context tools solves the contraints put forward.

Yes it does, and it is almost 100% identical to my original proposal!

However, what about my comment that the EnableAutoXXXXX true/false setting 
is completely redundant?

Why would you define a AutoXXXProvider and then NOT enable it?

We only need one setting, for the auto tool provider.

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

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

> interface ContextAware {
> 
>     init(Context c);
> }
> interface ContextTool extends ContextAware {}

interface ContextTools extends ContextAware, LazyLoaderFactory { }

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

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

As to names/definitions (always difficult to agree upon but at this 
stage if an improvement is made, then we just upgrade).

AutoContextToolLoaderImpl: <implementing class> | null
EnableAutoContextToolLoading: true | false

Interfaces:

interface ContextAware {

    init(Context c);
}
interface ContextTool extends ContextAware {}

I think there is enough consensus to get the work underway.

Lane







Brian Goetz wrote:

>
>> In digesting your note, I think we are in violent agreement with my 
>> initial proposal, no more and no less,  which accomodates 
>> configurability of automatic context loading, provides compatibility 
>> in 2.0 with 1.x templates, and provides for pluggability of the auto 
>> context loader.
>
>
> I think Lane's incremental approach seems sound here.
>
>
>
> -- 
> Brian Goetz
> Quiotix Corporation
> br...@qu...           Tel: 650-843-1300            Fax: 
> 650-324-8032
>
> http://www.quiotix.com
>
>
>
>
> -------------------------------------------------------
> 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] ContextTool replacement and thread-safety

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

>In digesting your note, I think we are in violent agreement with my 
>initial proposal, no more and no less,  which accomodates configurability 
>of automatic context loading, provides compatibility in 2.0 with 1.x 
>templates, and provides for pluggability of the auto context loader.

I think Lane's incremental approach seems sound here.



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

http://www.quiotix.com

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

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

>I don't really get this.  The way it works now is simple:

Simpler than that, actually:

>when resolving a variable reference:
>
>- check if the variable is in the context
>- if yes, return the variable
>- if not, check if it is a tool.
>- if not, return undefined
>- if yes, check if it has been initialized
>- if no, initialize it
>- else return the tool

Actually, its "if its a tool, initialize it and put it in the 
context."  Then, subsequent passes through, it gets returned by step 1.

>Let's take things one step at a time.  First let's allow tools to be 
>dynamically deployed and discovered using the new super duper thread-safe 
>map.  I think everybody likes this idea.  Then we can hash out any 
>optimizations or simplifications on how they are accessed from the context.

You speak wisely.



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

http://www.quiotix.com

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

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

Marc,

I don't really get this.  The way it works now is simple: 

when resolving a variable reference:

- check if the variable is in the context
- if yes, return the variable
- if not, check if it is a tool.
- if not, return undefined
- if yes, check if it has been initialized
- if no, initialize it
- else return the tool

(We'll there're also functions in there but you get the idea.)

We can probably improve on this a bit, but the basic mechanism is sound.  Why would you want to check each variable to see if it is "ContextAware"?  Why would we want to load every tool into every request when nothing is referencing it?  This is just extra overhead.  

If you want somethig to be context-aware, make it a tool or a Macro implementation (or a context-aware function if I can get people to agree on that concept).

Let's take things one step at a time.  First let's allow tools to be dynamically deployed and discovered using the new super duper thread-safe map.  I think everybody likes this idea.  Then we can hash out any optimizations or simplifications on how they are accessed from the context.

Cool?

Keats

-------Original Message-------
From: Marc Palmer <ma...@an...>
Sent: 07/25/03 06:43 PM
To: la...@op...
Subject: Re: [Webmacro-devel] ContextTool replacement and thread-safety

> 
> On Fri, 25 Jul 2003 09:16:20 -0700, Lane Sharman <la...@op...> 
wrote:


> Like I said in my initial proposal, this will not win over everyone on 
> all points but I think it is a workable solution allowing folks like you 

> to roll your own solution if that is what you desire If you implement 
> your own AutoProvider, then you you can look up your own ContextValues 
> from whatever :).
>
> If ContextTool is not a friendly interface name, then sure, I suppose we 

> could rename it ContextAware as you have suggested, refactor all the 
> implementations and tell everyone in 2.0 that the impl signature has 
> changed.
>
> Hopefully, Keats and ebr will sign off on this proposal and we will be 
> good to go.

My proposal (ContextTool is empty, extends ContextAware) means that no 
existing code is broken.

It also means we can add context-awareness to variables put into the 
context by the application (not the AutoContextProvider):

ctx.put( "x", myContextAwareImpl);

...would result in WM automatically calling init(context) on the variable 
if appropriate. However this is "magic" which some people, including 
myself, am not so sure about.

However we should have magic everywhere (vars AND tools from 
AutoContextProvider) -or-we have it nowhere - i.e. the code you quoted
that 
does instanceof ContextTool on the resulting tool obtained from 
AutoContextProvider should not be in Context at all, and the signature of 
AutoContextProvider's method should change to:


  Object getValue( String name, Context ctx)

..as I recommended many emails ago on this thread when I suggested the 
AutoContextProvider idea (AKA LazyVariableFactory).

So - magic everywhere, or nowhere?

If magic (calling tool.init(this)) is only available for tools obtained 
from AutoContextProvider, it seems totally wrong for Context to hold the 
logic that does this, when it does not do the same for normal variables.

Tools may not be context aware at all, depending on the impl of 
AutoContextProvider, and as such the instanceof would be completely 
redundant.

I think I am voting for "no magic at all". i.e. let AutoContextProvider 
call init on its tools, as it will know if they are compatible with 
ContextAware/ContextTool.

Marc

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

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

In digesting your note, I think we are in violent agreement with my 
initial proposal, no more and no less,  which accomodates 
configurability of automatic context loading, provides compatibility in 
2.0 with 1.x templates, and provides for pluggability of the auto 
context loader.

In raising the thread on Context aware methods (Keats proposal) and 
objects (your proposal),  I think this is different enough from Context 
Tools to merit a separate topic and discussion.

For now, unless Keats and ebr violently object, I think my proposal for 
context tools solves the contraints put forward.

I will be sure to have ContextTool extend ContextAware. Thanks.

-Lane

Marc Palmer wrote:

> On Fri, 25 Jul 2003 09:16:20 -0700, Lane Sharman <la...@op...> 
> wrote:
>
>
>> Like I said in my initial proposal, this will not win over everyone 
>> on all points but I think it is a workable solution allowing folks 
>> like you to roll your own solution if that is what you desire If you 
>> implement your own AutoProvider, then you you can look up your own 
>> ContextValues from whatever :).
>>
>> If ContextTool is not a friendly interface name, then sure, I suppose 
>> we could rename it ContextAware as you have suggested, refactor all 
>> the implementations and tell everyone in 2.0 that the impl signature 
>> has changed.
>>
>> Hopefully, Keats and ebr will sign off on this proposal and we will 
>> be good to go.
>
>
> My proposal (ContextTool is empty, extends ContextAware) means that no 
> existing code is broken.
>
> It also means we can add context-awareness to variables put into the 
> context by the application (not the AutoContextProvider):
>
> ctx.put( "x", myContextAwareImpl);
>
> ...would result in WM automatically calling init(context) on the 
> variable if appropriate. However this is "magic" which some people, 
> including myself, am not so sure about.
>
> However we should have magic everywhere (vars AND tools from 
> AutoContextProvider) -or-we have it nowhere - i.e. the code you quoted 
> that does instanceof ContextTool on the resulting tool obtained from 
> AutoContextProvider should not be in Context at all, and the signature 
> of AutoContextProvider's method should change to:
>
>
>  Object getValue( String name, Context ctx)
>
> ..as I recommended many emails ago on this thread when I suggested the 
> AutoContextProvider idea (AKA LazyVariableFactory).
>
> So - magic everywhere, or nowhere?
>
> If magic (calling tool.init(this)) is only available for tools 
> obtained from AutoContextProvider, it seems totally wrong for Context 
> to hold the logic that does this, when it does not do the same for 
> normal variables.
>
> Tools may not be context aware at all, depending on the impl of 
> AutoContextProvider, and as such the instanceof would be completely 
> redundant.
>
> I think I am voting for "no magic at all". i.e. let 
> AutoContextProvider call init on its tools, as it will know if they 
> are compatible with ContextAware/ContextTool.
>
> Marc
>

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

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

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

On Fri, 25 Jul 2003 09:16:20 -0700, Lane Sharman <la...@op...> 
wrote:


> Like I said in my initial proposal, this will not win over everyone on 
> all points but I think it is a workable solution allowing folks like you 
> to roll your own solution if that is what you desire If you implement 
> your own AutoProvider, then you you can look up your own ContextValues 
> from whatever :).
>
> If ContextTool is not a friendly interface name, then sure, I suppose we 
> could rename it ContextAware as you have suggested, refactor all the 
> implementations and tell everyone in 2.0 that the impl signature has 
> changed.
>
> Hopefully, Keats and ebr will sign off on this proposal and we will be 
> good to go.

My proposal (ContextTool is empty, extends ContextAware) means that no 
existing code is broken.

It also means we can add context-awareness to variables put into the 
context by the application (not the AutoContextProvider):

ctx.put( "x", myContextAwareImpl);

...would result in WM automatically calling init(context) on the variable 
if appropriate. However this is "magic" which some people, including 
myself, am not so sure about.

However we should have magic everywhere (vars AND tools from 
AutoContextProvider) -or-we have it nowhere - i.e. the code you quoted that 
does instanceof ContextTool on the resulting tool obtained from 
AutoContextProvider should not be in Context at all, and the signature of 
AutoContextProvider's method should change to:


  Object getValue( String name, Context ctx)

..as I recommended many emails ago on this thread when I suggested the 
AutoContextProvider idea (AKA LazyVariableFactory).

So - magic everywhere, or nowhere?

If magic (calling tool.init(this)) is only available for tools obtained 
from AutoContextProvider, it seems totally wrong for Context to hold the 
logic that does this, when it does not do the same for normal variables.

Tools may not be context aware at all, depending on the impl of 
AutoContextProvider, and as such the instanceof would be completely 
redundant.

I think I am voting for "no magic at all". i.e. let AutoContextProvider 
call init on its tools, as it will know if they are compatible with 
ContextAware/ContextTool.

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

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

Marc,

We have a working interface: ContextTool.

One of the wins of my proposal is that if you do not like the current 
Context.get() mechanic:

            Object tool = _broker.getTool(name);
            if (tool != null)
            {
                try
                {
                    ContextTool ct = (ContextTool) tool;


you will have new altenate logic allowing you to have your own context 
provider

            AutoContextProvider autoProvider = _broker.getAutoProvider()
            if (autoProvider != null) {
                Object contextValue = autoProvider.getValue(name);
                 if (contextValue != null) {
                     if (contextValue instanceof ContextTool) 
((ContextTool)contextValue).init(this);
                     // and so on.


Like I said in my initial proposal, this will not win over everyone on 
all points but I think it is a workable solution allowing folks like you 
to roll your own solution if that is what you desire If you implement 
your own AutoProvider, then you you can look up your own ContextValues 
from whatever :).

If ContextTool is not a friendly interface name, then sure, I suppose we 
could rename it ContextAware as you have suggested, refactor all the 
implementations and tell everyone in 2.0 that the impl signature has 
changed.

Hopefully, Keats and ebr will sign off on this proposal and we will be 
good to go.

-Lane


                 


 pluggable replacement architecture in which you can drop or not drop 
objects into the context. From this loader

Marc Palmer wrote:

> On Thu, 24 Jul 2003 20:20:47 -0700, Brian Goetz <br...@qu...> 
> wrote:
>
>>> 1) Governing principle 1: Existing WM apps which use a context tool 
>>> will not break in the new 2.0 distro. I think we owe that to our 
>>> user base. There are a lot of folks who use $Form, $Request, etc, 
>>> etc. out of the box.
>>
>>
>> +1 -- total agreement.
>
>
> +1 -- Even I uses $Response and $Form and a couple of others, but I 
> don't want people to be able to reconfig them!
>
>>> 2) Governing principle 2: New WM apps and architects can completely 
>>> suppress the Context Tool as magic through one directive in 
>>> WebMacro.properties: EnableContextToolLoading=false. In 
>>> WebMacro.defaults it is true by default.
>>
>>
>> +1 on concept; naming to be hashed out later.  We might want to 
>> support a list of magic thingie loaders, of which context tools will 
>> be one.  Something that loads default macros, functions, or 
>> directives might be another.
>
>
> -1 -- This is redundant IMO, given point (3)
>
>>> 3) Alternative context tool plug-in types can be plugged into the 
>>> context by a tool loader different than the default supplied in the 
>>> 2.0 distro. The default tool loader will be refactored to conform to 
>>> an interface, AutoContextLoader. Any "architect" can replace this 
>>> default tool loader with his own loader to add "magic" objects to 
>>> the context by implementing AutoContextLoader. Per the existing 
>>> logic,  on a ref to a null variable in Context.get(),  if 
>>> (EnableContextToolLoading==TRUE), the loader's interface will be 
>>> invoked with the reference to the broker to locate the supporting 
>>> object. AutoContextLoaderImpl: will be the property name.
>>
>>
>> +1 on concept; naming to be hashed out later.
>
>
> +1 only if AutoContextLoader = 
> o.w.tools.DefaultLegacyContextToolLoader in WM.defaults, so that if we 
> want to suppress auto-stuffing, we can just wipe this attribute in 
> WM.properties. This makes (2) redundant. Less code, less config, less 
> hassle :)
>
>>> 5) The Context Tool can be documented as a) a convenience with some 
>>> standard tools for the entry level WM app, b) easily disabled, or c) 
>>> pluggable by an architect seeking tight integration with default 
>>> tools as an elective feature of WebMacro.
>>
>>
>> +1
>
>
> +1 to the principle. I still think context-aware variables should be 
> part of this plan though - refactor ContextTool.init up to a 
> ContextAwareVariable interface... and do the instanceof...init(this) 
> thing when putting any var into the context. I think this is an 
> integral part because the smart way to do it is to modify the 
> contexttool interface in this way (push up the method to 
> ContextAwareVariable).
>
> Cheers


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

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

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

On Thu, 24 Jul 2003 20:20:47 -0700, Brian Goetz <br...@qu...> wrote:

>> 1) Governing principle 1: Existing WM apps which use a context tool will 
>> not break in the new 2.0 distro. I think we owe that to our user base. 
>> There are a lot of folks who use $Form, $Request, etc, etc. out of the 
>> box.
>
> +1 -- total agreement.

+1 -- Even I uses $Response and $Form and a couple of others, but I don't 
want people to be able to reconfig them!

>> 2) Governing principle 2: New WM apps and architects can completely 
>> suppress the Context Tool as magic through one directive in 
>> WebMacro.properties: EnableContextToolLoading=false. In 
>> WebMacro.defaults it is true by default.
>
> +1 on concept; naming to be hashed out later.  We might want to support a 
> list of magic thingie loaders, of which context tools will be one.  
> Something that loads default macros, functions, or directives might be 
> another.

-1 -- This is redundant IMO, given point (3)

>> 3) Alternative context tool plug-in types can be plugged into the 
>> context by a tool loader different than the default supplied in the 2.0 
>> distro. The default tool loader will be refactored to conform to an 
>> interface, AutoContextLoader. Any "architect" can replace this default 
>> tool loader with his own loader to add "magic" objects to the context by 
>> implementing AutoContextLoader. Per the existing logic,  on a ref to a 
>> null variable in Context.get(),  if (EnableContextToolLoading==TRUE), 
>> the loader's interface will be invoked with the reference to the broker 
>> to locate the supporting object. AutoContextLoaderImpl: will be the 
>> property name.
>
> +1 on concept; naming to be hashed out later.

+1 only if AutoContextLoader = o.w.tools.DefaultLegacyContextToolLoader in 
WM.defaults, so that if we want to suppress auto-stuffing, we can just wipe 
this attribute in WM.properties. This makes (2) redundant. Less code, less 
config, less hassle :)

>> 5) The Context Tool can be documented as a) a convenience with some 
>> standard tools for the entry level WM app, b) easily disabled, or c) 
>> pluggable by an architect seeking tight integration with default tools 
>> as an elective feature of WebMacro.
>
> +1

+1 to the principle. I still think context-aware variables should be part 
of this plan though - refactor ContextTool.init up to a 
ContextAwareVariable interface... and do the instanceof...init(this) thing 
when putting any var into the context. I think this is an integral part 
because the smart way to do it is to modify the contexttool interface in 
this way (push up the method to ContextAwareVariable).

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

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

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

Never thought I'd say it, but I think I agree with everything Lane says here :)

Not 100% sure of the naming, but the concepts make perfect sense to me and 
should make everyone happy (if I understand their concerns.)

>1) Governing principle 1: Existing WM apps which use a context tool will 
>not break in the new 2.0 distro. I think we owe that to our user base. 
>There are a lot of folks who use $Form, $Request, etc, etc. out of the box.

+1 -- total agreement.

>2) Governing principle 2: New WM apps and architects can completely 
>suppress the Context Tool as magic through one directive in 
>WebMacro.properties: EnableContextToolLoading=false. In WebMacro.defaults 
>it is true by default.

+1 on concept; naming to be hashed out later.  We might want to support a 
list of magic thingie loaders, of which context tools will be 
one.  Something that loads default macros, functions, or directives might 
be another.

>3) Alternative context tool plug-in types can be plugged into the context 
>by a tool loader different than the default supplied in the 2.0 distro. 
>The default tool loader will be refactored to conform to an interface, 
>AutoContextLoader. Any "architect" can replace this default tool loader 
>with his own loader to add "magic" objects to the context by implementing 
>AutoContextLoader. Per the existing logic,  on a ref to a null variable in 
>Context.get(),  if (EnableContextToolLoading==TRUE), the loader's 
>interface will be invoked with the reference to the broker to locate the 
>supporting object. AutoContextLoaderImpl: will be the property name.

+1 on concept; naming to be hashed out later.

>5) The Context Tool can be documented as a) a convenience with some 
>standard tools for the entry level WM app, b) easily disabled, or c) 
>pluggable by an architect seeking tight integration with default tools as 
>an elective feature of WebMacro.

+1



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

http://www.quiotix.com

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

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

OK. I would like to propose a solution to this thread. Please follow along.

1) Governing principle 1: Existing WM apps which use a context tool will 
not break in the new 2.0 distro. I think we owe that to our user base. 
There are a lot of folks who use $Form, $Request, etc, etc. out of the box.

2) Governing principle 2: New WM apps and architects can completely 
suppress the Context Tool as magic through one directive in 
WebMacro.properties: EnableContextToolLoading=false. In 
WebMacro.defaults it is true by default.

3) Alternative context tool plug-in types can be plugged into the 
context by a tool loader different than the default supplied in the 2.0 
distro. The default tool loader will be refactored to conform to an 
interface, AutoContextLoader. Any "architect" can replace this default 
tool loader with his own loader to add "magic" objects to the context by 
implementing AutoContextLoader. Per the existing logic,  on a ref to a 
null variable in Context.get(),  if (EnableContextToolLoading==TRUE), 
the loader's interface will be invoked with the reference to the broker 
to locate the supporting object. AutoContextLoaderImpl: will be the 
property name.

4) Therefore, the Context Tool as a feature will be pluggable and may be 
disabled via step (2).

5) The Context Tool can be documented as a) a convenience with some 
standard tools for the entry level WM app, b) easily disabled, or c) 
pluggable by an architect seeking tight integration with default tools 
as an elective feature of WebMacro.

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

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

-Lane


Keats wrote:

>Sounds great.  I'll have to read up on this!
>
>----- Original Message -----
>From: "Brian Goetz" <br...@qu...>
>To: "Keats" <ke...@ea...>
>Cc: <web...@li...>
>Sent: Thursday, July 24, 2003 6:13 PM
>Subject: Re: [Webmacro-devel] ContextTool replacement and thread-safety
>
>
>  
>
>>>The question is, would such an approach reduce the cost of
>>>      
>>>
>synchronization
>  
>
>>>to the point where it is worth giving up the quick, unsynchronized
>>>      
>>>
>lookups?
>  
>
>>>Should we maintain a separate table for preconfigured, thread-safe tools?
>>>Or is hot deploy/undeploy really important?
>>>
>>>Brian, I know you are expert in this area, so please chime in.
>>>      
>>>
>>Short answer: the ConcurrentHashMap class from Doug Lea's util.concurrent
>>gives you the best of both worlds.  It is a thread-safe Map that avoids
>>locking on the common code path.  It is blazingly fast, and a masterpiece
>>of coding.  If I hadn't audited the code myself, I wouldn't believe it.
>>
>>The common case, a lookup for an object already in the map, succeeds
>>without locking.  So in the case where you load up the map once at
>>    
>>
>startup,
>  
>
>>its no slower than HashMap.  (And, unlike other similar attempts at the
>>same result, this one is actually thread-safe, under both the old and new
>>Java Memory Models.)
>>
>>So basically, with CHM, its a non issue.  (I'm going to rip out all the
>>fancy cache-management crap and replace it with a ConcurrentHashMap.)
>>
>>    
>>
>
>
>
>-------------------------------------------------------
>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
Java Software Portal: http://opendoors.com

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

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

Sounds great.  I'll have to read up on this!

----- Original Message -----
From: "Brian Goetz" <br...@qu...>
To: "Keats" <ke...@ea...>
Cc: <web...@li...>
Sent: Thursday, July 24, 2003 6:13 PM
Subject: Re: [Webmacro-devel] ContextTool replacement and thread-safety


>
> >The question is, would such an approach reduce the cost of
synchronization
> >to the point where it is worth giving up the quick, unsynchronized
lookups?
> >Should we maintain a separate table for preconfigured, thread-safe tools?
> >Or is hot deploy/undeploy really important?
> >
> >Brian, I know you are expert in this area, so please chime in.
>
> Short answer: the ConcurrentHashMap class from Doug Lea's util.concurrent
> gives you the best of both worlds.  It is a thread-safe Map that avoids
> locking on the common code path.  It is blazingly fast, and a masterpiece
> of coding.  If I hadn't audited the code myself, I wouldn't believe it.
>
> The common case, a lookup for an object already in the map, succeeds
> without locking.  So in the case where you load up the map once at
startup,
> its no slower than HashMap.  (And, unlike other similar attempts at the
> same result, this one is actually thread-safe, under both the old and new
> Java Memory Models.)
>
> So basically, with CHM, its a non issue.  (I'm going to rip out all the
> fancy cache-management crap and replace it with a ConcurrentHashMap.)
>

Re: [Webmacro-devel] ContextTool issues

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

On Thursday, July 24, 2003, at 06:26  PM, Brian Goetz wrote:

>>> I wasn't clear.  I meant that you want _all_ the magic under the 
>>> "applications" control.
>>
>> No, I want all the magic to go away.
>
> I actually think the magic is pretty important!

Other than to support users that are already under our spell, what 
makes this magic important?  Seriously, I can think of nothing... and 
I'm not even trying to be stubborn.

eric

Re: [Webmacro-devel] ContextTool issues

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

>>I wasn't clear.  I meant that you want _all_ the magic under the 
>>"applications" control.
>
>No, I want all the magic to go away.

I actually think the magic is pretty important!

I guess we're going to have to talk about this.


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

http://www.quiotix.com

Re: [Webmacro-devel] ContextTool issues

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

>There are no use cases worth mentioning for context tools (other than the 
>case of them already being in use by our users).

That's not what I meant by use cases.  I meant the different ways WM might 
be used (servlet application, etc.)



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

http://www.quiotix.com

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

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

>The question is, would such an approach reduce the cost of synchronization
>to the point where it is worth giving up the quick, unsynchronized lookups?
>Should we maintain a separate table for preconfigured, thread-safe tools?
>Or is hot deploy/undeploy really important?
>
>Brian, I know you are expert in this area, so please chime in.

Short answer: the ConcurrentHashMap class from Doug Lea's util.concurrent 
gives you the best of both worlds.  It is a thread-safe Map that avoids 
locking on the common code path.  It is blazingly fast, and a masterpiece 
of coding.  If I hadn't audited the code myself, I wouldn't believe it.

The common case, a lookup for an object already in the map, succeeds 
without locking.  So in the case where you load up the map once at startup, 
its no slower than HashMap.  (And, unlike other similar attempts at the 
same result, this one is actually thread-safe, under both the old and new 
Java Memory Models.)

So basically, with CHM, its a non issue.  (I'm going to rip out all the 
fancy cache-management crap and replace it with a ConcurrentHashMap.)



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

http://www.quiotix.com

Re: [Webmacro-devel] ContextTool issues

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

On Thursday, July 24, 2003, at 05:38  PM, Brian Goetz wrote:

>>> In other words, its OK to have "magic" stuff, but you want the magic 
>>> to be put there by the application architect, not by WM.  So what 
>>> you want is a mechanism for adding your own magic.
>>
>> No, want the ability for *removing* the things that are magically 
>> placed in the context.  If this translates to "a more formal plug-in 
>> concept", that's fine, but the idea is to eliminate magical stuff, 
>> not make it easier to introduce more.
>
> I wasn't clear.  I meant that you want _all_ the magic under the 
> "applications" control.

No, I want all the magic to go away.

> My concern is that this is basically assuming one kind of application 
> model.  I think enumerating the use cases first would shed a lot of 
> light on the issue.

There are no use cases worth mentioning for context tools (other than 
the case of them already being in use by our users).

eric