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

Re: [Webmacro-devel] Here's why I don't like the Map constructor stuff

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

Not sure this is a good idea because of the cost to implement such a 
beast. It may be better to allow both and keep the overhead a bit lower 
than this idea proposes, which, btw, is very intriguing.

-lane

Brian Goetz wrote:

>
>> Ah, but I think you have fallen into the trap of making a Java Map a 
>> first- class WebMacro object, which I don't think it is. Lists 
>> (arrays etc.) are ubiquitous in languages, but Maps are rarely 
>> "native" types of the language.
>
>
> Except in Perl.  Associative arrays are WAY cool.
>
> Perhaps instead of emulating Map, we should emulate associative 
> arrays, and only have one type of list, which can be indexed either by 
> integer or by object key?
>
>
>
> -- 
> 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
>

Re: [Webmacro-devel] Voting on the ContextTool issue?

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

+1 on this plan for 2.0.

Keats wrote:

>>The real question is, does anybody use 'em enough to justify us keeping
>>them around and supporting them?
>>    
>>
>
>We'll it's hard to know who's using them.  I do, but I could replace them
>fairly easily.  However, I can't remember the last time we had to support
>anybody on these things.
>
>It feels strange for me to be defending the CTs -- I'm probably the main
>person who's been pushing for change (#bean, functions, context-aware
>functions, etc.) but I don't see the need to get rid of them entirely.  Like
>Brian says, let's deprecate them, make something better, give folks a chance
>to migrate, and then schedule a date to pull the switch.
>
>Keats
>
>
>
>-------------------------------------------------------
>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
>
>  
>

Re: [Webmacro-devel] ContextTool issues

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

On Wednesday, July 23, 2003, at 08:10  PM, Brian Goetz wrote:

> But why do you need to suppress individual CTs at all?  They don't  
> have any per-request overhead.  And they don't have variable name  
> capture problems.  So what's the problem?  If you don't use them, they  
> don't cost you anything.  No problem.

Until a template designer decides to start using it... w/o your  
knowledge or permission.  I don't think Marc is arguing performance  
here.  He's arguing against WM doing magical things that you have  
little control over.

eric

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

Re: [Webmacro-devel] ContextTool issues

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

>Well I wouldn't mind if we had a way to nicely "mute" settings in 
>WM.defaults. Actually I think we do don't we?
>
>LazyVariableFactory:

I did something like that to let you remove directives and tools from the 
list, but I'm not sure if it works for arbitrary tags -- but it certainly 
could.

>See the problem? Taking a shrink-wrapped WM jar how can my app reliably 
>suppress all CTs except $Form, for example? I don't think it's possibly 
>without me tracking what CTs are in any one WM release and explicitly 
>suppressing them in WM.properties.

But why do you need to suppress individual CTs at all?  They don't have any 
per-request overhead.  And they don't have variable name capture 
problems.  So what's the problem?  If you don't use them, they don't cost 
you anything.  No problem.



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

http://www.quiotix.com

Re: [Webmacro-devel] ContextTool issues

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

On Wed, 23 Jul 2003 16:52:14 -0700, Brian Goetz <br...@qu...> wrote:

>
>> a) Removes CT from core WM concepts = cleaner WM focussing on template 
>> rendering not "data management"
>
> You've STILL not made a compelling argument as to why context tools are a 
> problem for WM.  Why do they bother you so much, that you are willing to 
> condemn existing WM users to change their templates and/or configuration, 
> just to get rid of them?

There have been so many issues raised relating to them - many of which I 
think can be pushed to the sidelines if we we do this refactor.

>> b) Retains CT compatibility for you old-fashioned types
>
> Not quite.  That would only be true of you put the line
>
> LazyVariableFactory: org.webmacro.legacy.ContextToolFactory
>
> in WM.defaults.  But I suspect this suggestion runs counter to the real 
> point of your proposal.

Well I wouldn't mind if we had a way to nicely "mute" settings in 
WM.defaults. Actually I think we do don't we?

LazyVariableFactory:

Would do it wouldn't it, or worst case we could force it to use a null impl 
if we want to ditch ContextTools.

That solves the issue of the position of the factory (in WM.defaults 
instead, thus not breaking anything) but it still leaves us with the 
problem of not being able to reliably suppress certain CTs by wiping them 
out in WebMacro.properties to override their definition in 
WebMacro.defaults.

This is because we can't rely on knowing all the CTs that are defined in 
WM.defaults for any version X.Y of WM. That's one reason why I don't like 
it - overriding stuff in properties objects is an inexact science.

See the problem? Taking a shrink-wrapped WM jar how can my app reliably 
suppress all CTs except $Form, for example? I don't think it's possibly 
without me tracking what CTs are in any one WM release and explicitly 
suppressing them in WM.properties.

In this case however, my best option is to use LazyVariableFactory to wipe 
out the CT factory and it all goes.

I'm just mentioning this to highlight some of the problems with having CTs 
in WM.defaults.

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] Here's why I don't like the Map constructor stuff

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

>Hehe, I recall a very different response to previous proposals for major 
>work on POC.

No, not really.

My response to anyone's suggestion of "we should change X about WM" is 
filtered through the following process:

  - Will it make life easier, or harder, for the WM users?  If harder, veto.
  - Will it have risk of unintentionally changing the WM semantics, making 
life harder for the users?  If so, veto.
  - If we've reached this stage, now make a capital budgeting assessment of 
the changes worth, based on competing claims on developer resources.

Your POC work is a total wash at step 1, fell out of consideration at step 
2, and even if it hadn't, would probably have been culled at step 3.

The current issue (map and list) has the potential to be a win in step 1, 
making us more interested in taking the risks implied in step 2.



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

>a) Removes CT from core WM concepts = cleaner WM focussing on template 
>rendering not "data management"

You've STILL not made a compelling argument as to why context tools are a 
problem for WM.  Why do they bother you so much, that you are willing to 
condemn existing WM users to change their templates and/or configuration, 
just to get rid of them?

>b) Retains CT compatibility for you old-fashioned types

Not quite.  That would only be true of you put the line

   LazyVariableFactory: org.webmacro.legacy.ContextToolFactory

in WM.defaults.  But I suspect this suggestion runs counter to the real 
point of your proposal.



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

>...and there is no other CT logic in WM core code (Context or Broker). 
>That's it. We just abstract the whole mechanism, and Eric and I will have 
>no "LazyVariableFactory:" entry in WebMacro.properties :)
>
>See what I'm getting at?

It sounds like what you're getting at is: you don't like having context 
tools in the WM defaults.  Why?  At this point, it adds no performance 
overhead, nor does it have variable capture problems, nor does it 
complicate WM development or maintenance.  So is the objection entirely 
aesthetic?  If so, that is not remotely grounds for removing a facility 
that people use.

Still, the lazy thing sounds useful -- keep talking about its merits and 
stop talking about ripping out context tool support and you might convince 
me.


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

http://www.quiotix.com

Re: [Webmacro-devel] Here's why I don't like the Map constructor stuff

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

On Wed, 23 Jul 2003 16:17:30 -0700, Brian Goetz <br...@qu...> wrote:

>
>>> Perhaps instead of emulating Map, we should emulate associative arrays, 
>>> and only have one type of list, which can be indexed either by integer 
>>> or by object key?
>>
>> Well that IS an interesting thought, but it will definitely incur some 
>> serious PropertyOperatorCache nightmares surely?
>
> We gladly suffer such nightmares to make life easier for our users.

Hehe, I recall a very different response to previous proposals for major 
work on POC.

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

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

On Wed, 23 Jul 2003 19:08:08 -0400 (GMT), Keats <ke...@su...> wrote:

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

That's not what I proposed it for.

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

That's what I mean for LazyVariableFactory. It is the impl in WM that knows 
that it has to look up tools and create them.

i.e. we remove all the CT config stuff from WM "core" code, and stuff it 
into a LazyVariableFactory impl. Then in WebMacro.properties (for example):

LazyVariableFactory: org.webmacro.legacy.ContextToolFactory

This would reproduce the current behaviour of WM - reading the settings 
from Broker to find all the ContextToolXXXX properties and caching the 
info, and then when (if) asked it can create any of them on demand to be 
put into a context. Thus the code in Context becomes (pseudo):

  if (context.get(varname) == null)
  {
     if (broker.getLazyVariableFactory() != null)
        return broker.getLazyVariableFactory().getVariable( varname, this);
  }


...and there is no other CT logic in WM core code (Context or Broker). 
That's it. We just abstract the whole mechanism, and Eric and I will have 
no "LazyVariableFactory:" entry in WebMacro.properties :)

See what I'm getting at?

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

This is only necessary if the context-aware initialization thing is 
retained as is.

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.

What this gets us:

a) Removes CT from core WM concepts = cleaner WM focussing on template 
rendering not "data management"
b) Retains CT compatibility for you old-fashioned types
c) Brings us new context-aware vars - which context.put() could also check 
for, even though Brian says this is a waste of CPU - despite also pointing 
out that instanceof is pretty damn cheap these days, and we are typically 
talking maybe 5-10 puts per template.
d) Gives applications the ability to completely control template variables. 
i.e. I may want to ship WM without modification but not allow templates 
access to $Request or $Response and instead have my own special vars for 
doing something similar.

I expect this to be greeted with the usual disagreement :)

-- 
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] Here's why I don't like the Map constructor stuff

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

>>Perhaps instead of emulating Map, we should emulate associative arrays, 
>>and only have one type of list, which can be indexed either by integer or 
>>by object key?
>
>Well that IS an interesting thought, but it will definitely incur some 
>serious PropertyOperatorCache nightmares surely?

We gladly suffer such nightmares to make life easier for our users.

>I think this could really make the parser nasty though couldn't it, using 
>the same delimiter for arrays and assoc arrays, unless we have an 
>association delimiter also - i.e:

We gladly suffer such nightmares to make life easier for our users.

>#set $normalArray = [ 0, 1, 2, 3]
>#set $assocArray = [ ( "a" = "b" ), ( "c" = "d" ) ]
>
>... and then #foreach becomes muddled. What are the semantics of #foreach 
>when passed an assoc array - or is this forbidden? Each element would have 
>to have a Name and Value property if it was to work, and this might seem 
>like too much voodoo for some.

How about:

#foreach $a in $list -> returns values for either map or list

#foreach $a in $list.keys -> returns keys for map, integer indices for lists





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

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

I was going to say that, but I'm glad someone else did.

It does seem like it has potential as a reasonable abstraction of the 
existing tool stuff.



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

http://www.quiotix.com

Re: [Webmacro-devel] Here's why I don't like the Map constructor stuff

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

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

>
>> Ah, but I think you have fallen into the trap of making a Java Map a 
>> first-class WebMacro object, which I don't think it is. Lists (arrays 
>> etc.) are ubiquitous in languages, but Maps are rarely "native" types of 
>> the language.
>
> Except in Perl.  Associative arrays are WAY cool.
>
> Perhaps instead of emulating Map, we should emulate associative arrays, 
> and only have one type of list, which can be indexed either by integer or 
> by object key?

Well that IS an interesting thought, but it will definitely incur some 
serious PropertyOperatorCache nightmares surely?

i.e. when working out what prop/method to call it'll involve some really 
nasty stuff to see if the methods accept a Map or List etc. and making sure 
the current obj was constructed as a assoc array or list.

I think this could really make the parser nasty though couldn't it, using 
the same delimiter for arrays and assoc arrays, unless we have an 
association delimiter also - i.e:

#set $normalArray = [ 0, 1, 2, 3]
#set $assocArray = [ ( "a" = "b" ), ( "c" = "d" ) ]

... and then #foreach becomes muddled. What are the semantics of #foreach 
when passed an assoc array - or is this forbidden? Each element would have 
to have a Name and Value property if it was to work, and this might seem 
like too much voodoo for some.

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] ContextTool issues

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

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
> 

Re: [Webmacro-devel] Voting on the ContextTool issue?

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

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

Re: [Webmacro-devel] Here's why I don't like the Map constructor stuff

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

On Wed, 23 Jul 2003 14:33:47 -0400, Eric B. Ridge <eb...@tc...> wrote:

> we can.  or we can add a public void set(Object key, Object value)  
> method.
>
> #set $map = {}
> $map.set("Foo", "Bar")
> $map.set("Tree", "Flower")
>
> it kinda fits along with:
> #set $map.Foo = "Bar"
> #set $map.Tree = "Flower"

Hehe, and incidentally is only possible since my fix to 
PropertyOperatorCache ;-)

Yes this is definitely a possible solution. It still leaves all the Java 
Map method pollution in there though, IMO.

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] Here's why I don't like the Map constructor stuff

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

>Ah, but I think you have fallen into the trap of making a Java Map a 
>first- class WebMacro object, which I don't think it is. Lists (arrays 
>etc.) are ubiquitous in languages, but Maps are rarely "native" types of 
>the language.

Except in Perl.  Associative arrays are WAY cool.

Perhaps instead of emulating Map, we should emulate associative arrays, and 
only have one type of list, which can be indexed either by integer or by 
object key?



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

http://www.quiotix.com

Re: [Webmacro-devel] Voting on the ContextTool issue?

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

> The real question is, does anybody use 'em enough to justify us keeping
> them around and supporting them?

We'll it's hard to know who's using them.  I do, but I could replace them
fairly easily.  However, I can't remember the last time we had to support
anybody on these things.

It feels strange for me to be defending the CTs -- I'm probably the main
person who's been pushing for change (#bean, functions, context-aware
functions, etc.) but I don't see the need to get rid of them entirely.  Like
Brian says, let's deprecate them, make something better, give folks a chance
to migrate, and then schedule a date to pull the switch.

Keats

Re: [Webmacro-devel] Here's why I don't like the Map constructor stuff

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

On Wed, 23 Jul 2003 13:55:57 -0400, Eric B. Ridge <eb...@tc...> wrote:

>> ...and guess what? I get all the values in the output because put()  
>> returns an Object!
>
> So we make {} return a special object too.  It doesn't necessarily need  
> to be a java.util.Map implementation.

Ta-da! That's what I was suggesting. I even volunteered a nice object for 
it.

As for Keats' concern about #eval requiring a Map - if we went with a 
WebMacroObject we could adapt #eval to require one of those - or better 
still make it accept either.

That's what WebMacroObject does when assign an ancestor ("#newobject $z 
inherits from $x") - it detects Maps or WebMacroObjects.

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] Here's why I don't like the Map constructor stuff

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

On Wed, 23 Jul 2003 16:12:17 -0400, Eric B. Ridge <eb...@tc...> wrote:

> On Wednesday, July 23, 2003, at 04:05  PM, Marc Palmer wrote:
>
>> Hehe... or #newobject $x
>
> I don't like this because it doesn't correspond to how we currently  
> handle arrays.  The two are similar enough that they warrant a similar  
> syntax.

Ah, but I think you have fallen into the trap of making a Java Map a first- 
class WebMacro object, which I don't think it is. Lists (arrays etc.) are 
ubiquitous in languages, but Maps are rarely "native" types of the 
language.

As such #newobject represents a nicer abstraction of the ability to setup a 
mapping, but in reality, from the WMScript point of view it is an "object" 
not a "Map". You get the same functionality, but without the Java baggage 
:)

As for the {} block delimiters, I don't care because I never use {} for 
directive blocks! #begin .. #end and you have no clash :)

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] Here's why I don't like the Map constructor stuff

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

On Wednesday, July 23, 2003, at 04:05  PM, Marc Palmer wrote:

> Hehe... or #newobject $x

I don't like this because it doesn't correspond to how we currently  
handle arrays.  The two are similar enough that they warrant a similar  
syntax.

eric

>
> It's the way I tell you!!! Think - Maps are a Java thing. To people  
> with zero java knowledge writing scripts this just seems a bit odd,  
> compared with natural object semantics in langs such as JavaScript.
>
> #newobject or death!
>
> :)
>
>
> --  
> 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

Re: [Webmacro-devel] Here's why I don't like the Map constructor stuff

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

On Wednesday, July 23, 2003, at 03:29  PM, Brian Goetz wrote:

>>> I _hate_ this syntax.  Too easy to conflict with blocks.
>>
>> The only other option is:
>> #set $x = []
>
> (that's not the only option.)
>
> or some other syntax ( [ (a, b) (c, d) ] )

that's not too bad, actually.

#set $map = [()]

for an empty map.  hmm.

> As for empty maps, how about
>   #set $x = $Map.newEmptyMap()

but this sucks.  I think I'm being baited here...

> or the like?  Does everything have to have a magic punctuation-based 
> syntax?

making a new, empty map does.

eric

Re: [Webmacro-devel] Here's why I don't like the Map constructor stuff

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

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

>> > I _hate_ this syntax.  Too easy to conflict with blocks.
>>
>> The only other option is:
>> #set $x = []
>
> (that's not the only option.)
>
> I think the [] notation works for everything but empty maps:
>
> #set $x = [ a => b, c => d ]
>
> or some other syntax ( [ (a, b) (c, d) ] )
>
> As for empty maps, how about #set $x = $Map.newEmptyMap()
>
> or the like?  Does everything have to have a magic punctuation-based 
> syntax?

Hehe... or #newobject $x

It's the way I tell you!!! Think - Maps are a Java thing. To people with 
zero java knowledge writing scripts this just seems a bit odd, compared 
with natural object semantics in langs such as JavaScript.

#newobject or death!

:)


-- 
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] Here's why I don't like the Map constructor stuff

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

On Wed, 23 Jul 2003 15:23:27 -0400, Eric B. Ridge <eb...@tc...> wrote:

> On Wednesday, July 23, 2003, at 03:19  PM, Brian Goetz wrote:
>
>>> #set $x = {}
>>
>> I _hate_ this syntax.  Too easy to conflict with blocks.
>
> The only other option is:
> #set $x = []
>
> and that conflicts with empty lists.  unless you want something goofy  
> like [{}] or [[]] or [!!] or ...

Or, how about the unusual:

#set $x = ][

:)

Actually [[ ... ]] seems quite good to me.

-- 
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] Here's why I don't like the Map constructor stuff

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

> Actually empty maps are more useful than empty lists, so I'd make [] be an
> empty map.  I don't think there are many use cases for declaring a new
> Object[0] in a template.

OK, we've already got a List tool, so $List.emptyList() could give you
an empty list. 

> I kinda like the colons, but I'm not a stickler on this either.  I actually
> prefer "=".  Eric complains that it's not an assignment, but it is like an
> assignment.  I.e.,

Either is fine with me.