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