[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