Thread: [Webmacro-devel] ContextTool issues

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

It seems to me that a LazyVariableFactory is just another name for a ContextTool.  

Yes there are more improvements that can be made to the ContextTool mechanism.  Decoupling it from the config is a good idea.  

Making it work with generic classes is also a step forward.  In fact I've implemented something like this, but noone seemed interested at the time.  Basically I built some adapters that take various kinds of classes (static, singleton, factory, normal) and load them as context tools on demand.  I can probably dredge up this old code if anyone is interested.

Keats

-------Original Message-------
From: Marc Palmer <ma...@an...>
Sent: 07/23/03 06:37 PM
To: web...@li...
Subject: Re: [Webmacro-devel] Voting on the ContextTool issue?

> 
> On Wed, 23 Jul 2003 12:07:00 -0700, Brian Goetz <br...@qu...> wrote:

> There's not a single thing in Marc's e-mail that I agree with.  Where
> to start?

You surprise me Brian!

Actually I can't remember a time when you ever agreed with me :)

>> > I'm all for more discussion, or concrete proposals.  I think most of
>> > the suggestions made so far need to be thought through and fleshed
out
>> > more before "voting".
>>
>> I mean vote on the idea of the changes, not the details.
>
> That's not a vote.

Er, ok. I thought we had to be aligned in our decisions about what will 
happen, as well as how those things will happen.

>> > Then make your case, compellingly!
>
> (arguments elided)
>
> What you've done here is made several arguments why, if you were
> redesigning WM from scratch, why you would not have context tools.  I
> don't dispute this conclusion.  However, that's not the same thing.
> You don't like them.  People don't use them exactly the way Justin had
> in mind.  They're aesthetically displeasing.  These may all be true,
> but none of these are arguments for getting rid of them.
>
> Is there something so fundamentally broken about them that they
> prevent other valuable improvements from being made?  That is the kind
> of case you'd have to make to make it worthwhile screwing all the
> users who use them now.
>
> If you want to make an argument for deprecating the mechanism and
> providing new, better mechanisms for doing the same thing, fine.  Make
> that argument, but that's not what you've suggested.

OK.

We rewrite it.

Add a LazyVariableFactory mechanism, with a default impl that looks and 
smells like ContextTools but is completely optional. The factory has a 
method:

   Object getVariable(String name, Context c)

Then we expose a get/setLazyVariableFactory method in Broker so that 
applications can set this at app init time, independent of WM config.

This way applications can completely control their environment and keep 
things clean.

>> That is not an issue IMO, as we have agreed that WM 2.0 will hose 
>> backward compatibility anyway with all the package refactoring.
>
> So many fallacies here I can't count.  I'll address the major ones:
>
> 1.  A package refactor should have minimal effect on WM users.

It most likely will stop most of their code compiling.

Existing changes already break most WM code - i.e. the hiding of 
FastWriter.

Anybody who does not rely on WMServlet will have broken code with WM 2.0 - 

and rightly so of course.

> 2.  If it does have an effect on some users, they will be the most 
> advanced users of WM (those that write their own directives and tools), 
> which minimizes the pain.

As above, I disagree with this. Only those who use WMServlet exclusively 
will escape pain free.

I'm not saying the pain is significant, it isn't. I've done it. Ignition
is 
running against the bleeding-edge build of WM.

> 3.  Just because you're going to break something is not an argument
> for breaking everything!  That's kind of like saying "I already spilled
> wine on the carpet, so I'm sure you won't mind me burning down the 
> house."

Well it depends on whether your house insurance policy covers accidental 
damage to carpets and how expensive the carpet was ;-)

That's not what I was saying though, and you know that. I was just saying 
that other stuff is broken too, so we shouldn't worry unnecessarily about
a 
few other bits, as long as it is not too painless.

For example, we could remove CTs completely and provide a
ContextToolLoader 
utility class in WM 2.0 that provides the old functionality but without 
lazy instantiation - if you don't like my LazyVariableFactory idea (and 
something tells me you won't):

  Template t = getTemplate(templatename);
  Context c = wm.getContext();
  ContextToolLoader ctl = new ContextToolLoader(wm.getBroker()); // reads 
from WM settings
  ctl.stuff(c);

There, 2 lines of code and those poor people in broken code land will be
on 
a one way ticket to nirvana.

Incidentally this is just an example. I prefer the LazyVariableFactory 
concept myself.

>> Again, I think you have misunderstood. Vote on direction, not
>> details.  Unless we declare a vote on the subject we are unlikely to
>> get the full discussion we so desire.
>
> I think that's a side-effect of rushing the process.  I don't feel
> like this subject is remotely ripe enough for a vote.  These things
> are supposed to take a long time.

OK, but if I hadn't asked for a vote we wouldn't have had all these ideas 
coming out now :)

> I think that while Context tools may have outlive their usefulness,
> they are also (at this point) pretty unobtrusive in WM.  I think there
> are more useful things we could do to make WM easier to use / maintain
> than removing features which are widely used but which we find
> aesthetically displeasing.  I know we removed a lot of things
> recently, but all of those are things that we are confident few users
> use.  This is different.

Solution: LazyVariableFactory! Get the best of both worlds :)

With this solution, apps like Ignition could handle lazy instantiation of 
their sometimes expensive helpers with ease.

Marc

-- 
Marc Palmer
Contract Java Consultant/Developer

                        w a n g j a m m e r s

                 java and web software design
              experts with an ethical outlook

                   http://www.wangjammers.org

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