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

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

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

> > There's a difference between deprecating them and getting rid of the
> > ones we have, breaking everyone's templates in the process.
> 
> Those templates will break at some point anyway (if tools do go away).  
> Does it really make a difference if it happens now or later?  It sounds 
> like we're deciding if it will happen or not, regardless of when.

Of course it matters!

If we say "Context tools are going away in two years", people have
ample opportunity to gradually work the CTs out of their templates.
This is why facilities get deprecated instead of removed -- as a
warning that they may eventually go away.  It takes a long time for
deprecated facilities to go away, and for good reason -- it takes a
long time to wean people off them.

If we rip things out and people's WM apps stop working, peoeple will
eventually stop using WM because its not stable.  That doesn't help
us.

But in any case, its putting the cart before the horse -- there has to
be something that does the same thing before we can deprecate the
functionality we have now.

> How about exploring a way to expand this capability to regular 
> $Variables too.  

Sure, lets talk about that -- that might be cool.

> > Just like directives.  Lets get rid of them too then!
> 
> Come on man, gimme a break.  :)

Me too!

> > Then do so, deprecate the context tools we have, and then, in a
> > version or two, we can talk about getting rid of CTs.
> 
> So you're saying, w/o any further discussion, that we should deprecate 
> all our existing tools?  Hmm.

No, what I'm saying is that without any further discussion, we should
do nothing, but that if you want to do something, getting rid of them
is not a candidate, although deprecating them might be.

> Spending the time talking about a better mechanism is a waste if you 
> can't be convinced what we currently have needs to be changed (or even 
> dropped completely).

That's backwards.  I'll be more inclined to deprecate them if a better
mechanism exists!  

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

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

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

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.

I don't really mind the curly braces, but I'm open.

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

#set $map = ["A"=1, "B"=2]

is the same as

#set $map = []
#set $map.A=1
#set $map.B=2

It also connotes equality, as in:

#if ($Map.A=1) ...

Keats

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

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

On Wednesday, July 23, 2003, at 03:30  PM, Keats wrote:

> You're forgetting about:
>
> $Request
> $Response
> $Cookie
> $Session
> $Form
> $FormList
> $CGI

all of which exist for WebContext users only.  WebContext could 
(probably) go away too if we nuked tools.

> $Variable
> $Template

I've never used these, so I'm not sure what they actually do.  If I 
remember tho, $Variable does some poking into the current context... 
which can be done with your latest changes the the $function() stuff.

> and probably some more.
>
> These guys work and have almost zero overhead if you don't use them, 
> so why
> not keep it around, at least for a while?

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

eric

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

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

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

>> I do think ContextTools should go away.
>
> There's a difference between deprecating them and getting rid of the
> ones we have, breaking everyone's templates in the process.

Those templates will break at some point anyway (if tools do go away).  
Does it really make a difference if it happens now or later?  It sounds 
like we're deciding if it will happen or not, regardless of when.

> They provide a very special capability -- the ability to define global
> facilities which are available to every template.  That is a very
> special capability.  Having to import every tool you use in a template
> is error prone and ugly.

How about exploring a way to expand this capability to regular 
$Variables too.  Why does it have to happen

> Just like directives.  Lets get rid of them too then!

Come on man, gimme a break.  :)

> Then do so, deprecate the context tools we have, and then, in a
> version or two, we can talk about getting rid of CTs.

So you're saying, w/o any further discussion, that we should deprecate 
all our existing tools?  Hmm.

> Agreed.  But saying "lets get rid of CTs" before a better mechanism
> is in place and in use is putting the cart before the horse.

Spending the time talking about a better mechanism is a waste if you 
can't be convinced what we currently have needs to be changed (or even 
dropped completely).

eric

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

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

> 1) They provide no extra-special capabilities, other than having access
> to the Context itself.  Access to the Context is really unnecessary for
> tools (none of our stock tools make use of this) and complicates the
> finalization of the context.  In fact, most of our CTs are simple
> wrappers for static classes.

You're forgetting about:

$Request
$Response
$Cookie
$Session
$Form
$FormList
$CGI
$Variable
$Template

and probably some more.

These guys work and have almost zero overhead if you don't use them, so why
not keep it around, at least for a while?

Keats

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

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

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

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

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

> I do think ContextTools should go away.

There's a difference between deprecating them and getting rid of the
ones we have, breaking everyone's templates in the process.

> 1) They provide no extra-special capabilities, other than having access 
> to the Context itself.  Access to the Context is really unnecessary for 
> tools (none of our stock tools make use of this) and complicates the 
> finalization of the context.  In fact, most of our CTs are simple 
> wrappers for static classes.

They provide a very special capability -- the ability to define global
facilities which are available to every template.  That is a very
special capability.  Having to import every tool you use in a template
is error prone and ugly.

> 2) CTs require configuration changes to use.  One of the key benefits 
> of WM is it's "zero-configuration" (in common-use cases).   The 
> requirement to configure new tools via wm.properties breaks this 
> benefit.

Just like directives.  Lets get rid of them too then!  

> 5) User-variables can cause name conflicts with CTs.  The user variable 
> would be picked up first, hiding the fact that the tool is even 
> available.  Then, the only way to access it would be to change its name 
> in wm.props.

That sounds lke the right behavior.  If the user doesn't know about
the tool, it doesn't get in his way.  If he does, then he won't name a
variable to conflict with it.

> 5) CTs do introduce a bit of overhead when accessing a variable that is 
> not in the Context.  Looking for $foo causes a lookup in the context, 
> then the map of possible CTs (via the Broker) before Context.java can 
> say $foo is really undefined.

Accessing a variable not in the context is already an error case. But
the cost is trivial -- two map lookups rather than one.  Dwarfed by
other stuff that's going on.

> 6) The core CTs which are useful can be turned into $functions().  Some 
> already have.  

Then do so, deprecate the context tools we have, and then, in a
version or two, we can talk about getting rid of CTs.  

> If the #1 advantage of ContextTools is the auto-stuffing into the 
> context, we can handle it another way...

Agreed.  But saying "lets get rid of CTs" before a better mechanism
is in place and in use is putting the cart before the horse.

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

eric


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

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

> #set $x = {}

I _hate_ this syntax.  Too easy to conflict with blocks.  

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

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

> To be honest, I am having a harsh internal debate about context tools. 
> On the one hand, they can really simplify stuffing the context. There is 
> not a lot of overhead. And, we can ship WebMacro.defaults with none 
> defined and tell the user how to configure the ones they want in 
> WebMacro.properties. In this manner, it is a convenience feature that 
> perhaps we should not eject prematurely.

I don't often agree with Lane 100%, but in this case, what he said.  :)

Re: [Webmacro-devel] Why can't webmacro.jar be replaced without restart?

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

> Guys, I imagine a few of use are familiar with this message after trying to 
> replace webmacro.jar and restarting/reloading the web application without 
> restarting the servlet container:

Great question.  I think this is worth spending some effort on -- much
more worthwhile than debating about whether or not to kill Context
tools :)

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

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

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

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

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

> > And what about backward compatibility?  Lots of people use the existing
> > context tools.
> 
> 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.  

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.

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

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

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.

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 02:30  PM, Keats wrote:

> I like having it be a Map.  For example, #eval needs a Map for the  
> "using"
> clause.  Can't we just implement a map that overrides put to allways  
> return
> an empty String?

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"

but is useful in the cases where your keyname is $dynamic

eric

>
> Keats
> ----- Original Message -----
> From: "Eric B. Ridge" <eb...@tc...>
> To: <ma...@an...>
> Cc: <web...@li...>
> Sent: Wednesday, July 23, 2003 1:55 PM
> Subject: Re: [Webmacro-devel] Here's why I don't like the Map  
> constructor
> stuff
>
>
>> On Wednesday, July 23, 2003, at 01:47  PM, Marc Palmer wrote:
>>
>>>
>>> Hi,
>>>
>>> I thought I'd try using the #set $xxx = { } mechanism today.
>>>
>>> If you remember there was a real hoo-haa about this versus my
>>> #newobject directive (which is fine and working well in Ignition I
>>> might add!).
>>>
>>> Now I tried this:
>>>
>>> #set $x = {}
>>> #foreach $item in $myNameList
>>>   $x.put( $item, $values.get($item) )
>>> #end
>>>
>>> ...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.
>>
>> eric
>>
>>>
>>> This is really bad news. #newobject does not suffer this because I
>>> return a custom object not a Hashtable/Map that is de-Java-lized:
>>>
>>> public class WebMacroObject
>>> {
>>>    public int getCount()
>>>    public Iterator getPropertyNames()
>>>    public Iterator getPropertyValues()
>>>    public void put( String key, Object value )
>>>    public Object get( String key )
>>>    public void reset()
>>>    public void copyFrom( WebMacroObject src )
>>>    public void copyFrom( Map src )
>>> }
>>>
>>> This is much cleaner and does not suffer from the Map contract
>>> problems. This object can of course be used without #newobject, it is
>>> completely standalone. Java heads may shriek at the altered syntax,
>>> but I think it stands well in the non-Java world.
>>>
>>> Shall I commit this object to CVS and edit the { } map constructor
>>> mechanism to create an instance of this instead of the Map
>>> implementation it does now?
>>>
>>> ...or is there another solution?
>>>
>>> I feel that, like my suggestion for a list wrapper object, we should
>>> consider providing some special WM types for this kind of stuff to
>>> de-Java- lize things further and start building a small "WebMacro
>>> Object Model" in this regard, so we can document it clearly for
>>> template writers instead of referring them to API Javadocs for Map,
>>> for example.
>>>
>>> Just say the word and WebMacroObject is in CVS and { } updated to use
>>> it... and if you really feel friendly you could let me add #newobject
>>> to WM to back up the "WebMacro Object Model" :)
>>>
>>> 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
>>
>>
>>
>> -------------------------------------------------------
>> 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?

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

On Wednesday, July 23, 2003, at 05:11  AM, Brian Goetz wrote:

>> Not in all respects, and we know already that two of the developers
>> disagree with you on this :-)
>
> Then make your case, compellingly!

Okay, so do we need to vote on if we should vote?

I do think ContextTools should go away.

1) They provide no extra-special capabilities, other than having access 
to the Context itself.  Access to the Context is really unnecessary for 
tools (none of our stock tools make use of this) and complicates the 
finalization of the context.  In fact, most of our CTs are simple 
wrappers for static classes.

2) CTs require configuration changes to use.  One of the key benefits 
of WM is it's "zero-configuration" (in common-use cases).   The 
requirement to configure new tools via wm.properties breaks this 
benefit.

3) CTs are "automagic" to the Java programmer.  Some probably think 
this is the benefit of tools, but I disagree.  The full contents of the 
Context are unknown to the programmer unless he opens up 
WebMacro.defaults... which if he's using a .jar distro of WM, is 
difficult to do.  In addition, CTs are not discoverable by walking the 
.keySet() of the Context.

5) User-variables can cause name conflicts with CTs.  The user variable 
would be picked up first, hiding the fact that the tool is even 
available.  Then, the only way to access it would be to change its name 
in wm.props.

4) We have Context.java *and* WebContext.java, which both do the same 
thing, except WebContext.java provides the $Request and $Response tools 
(along with $Form and <something else>).  Both of these classes 
(RequestTool and ResponseTool) could simply be .put() into the context 
via WMServlet, and WebContext.java could go away:
	context = getContext();
	context.put ("Request", new RequestTool(servletRequest));
	context.put ("Response", new ResponseTool(servletResponse));

What do we need WebContext for now?  Nothing.  All of it's other 
"web"-specific stuff is (or should be) handled via its _broker instance.

FWIW, I have many templates that use $Form, $Request, $Response, but I 
have no issues adding this to my servlet:
	context.put ("Form", request.getParameterMap());
	context.put ("Request", request);
	context.put ("Response", response);
I would welcome this change to my code actually, only so that it 
becomes more clear what is available in my context.

5) CTs do introduce a bit of overhead when accessing a variable that is 
not in the Context.  Looking for $foo causes a lookup in the context, 
then the map of possible CTs (via the Broker) before Context.java can 
say $foo is really undefined.

6) The core CTs which are useful can be turned into $functions().  Some 
already have.  From a page designer's point of view, the name-spacing 
that tools provide for these functions is meaningless... in other 
words, (I think) $toInt('100') is easier to remember and more 
meaningful than $Type.toInt('100').   One might even think 
$Type.toInt('100') means "Convert the object $Type to an integer".

7) The tools represent more code we need to maintain.  Not only the 
tools themselves, but the additional code in WebMacro to configure, 
create, find, use, and destroy them.

If the #1 advantage of ContextTools is the auto-stuffing into the 
context, we can handle it another way...

We've often talked about having the ability to define "global #macro's" 
via some kind of template file (plus configuration key).  Maybe this 
would be the place, using #bean, for users to configure in their 
required tools too... giving 'static' tools a scope of "application".

-- globals.wmt --
#bean $Type = "org.webmacro.util.CastUtil" scope="application"  ## or 
whatever the syntax is
#bean $List = "org.webmacro.util.ListUtil" scope="application"
#const $MY_NAME = "Eric"

it's just an idea, but it's one that would give us the same automatic 
loading, combined with more flexible configuration (you're more likely 
to keep your globals.wmt template in your project than a 
WebMacro.properties file... esp. if you don't need wm.props).  It will 
also provide a single place where the programmer (or designer) can go 
to find all the tools that are being loaded.  The tools will be 
discoverable by walking the contents of the Context, *and* if you use 
#bean's 'application' scope, you only pay the overhead of creating the 
tool once.

eric

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

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

I like having it be a Map.  For example, #eval needs a Map for the "using"
clause.  Can't we just implement a map that overrides put to allways return
an empty String?

Keats
----- Original Message -----
From: "Eric B. Ridge" <eb...@tc...>
To: <ma...@an...>
Cc: <web...@li...>
Sent: Wednesday, July 23, 2003 1:55 PM
Subject: Re: [Webmacro-devel] Here's why I don't like the Map constructor
stuff


> On Wednesday, July 23, 2003, at 01:47  PM, Marc Palmer wrote:
>
> >
> > Hi,
> >
> > I thought I'd try using the #set $xxx = { } mechanism today.
> >
> > If you remember there was a real hoo-haa about this versus my
> > #newobject directive (which is fine and working well in Ignition I
> > might add!).
> >
> > Now I tried this:
> >
> > #set $x = {}
> > #foreach $item in $myNameList
> >   $x.put( $item, $values.get($item) )
> > #end
> >
> > ...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.
>
> eric
>
> >
> > This is really bad news. #newobject does not suffer this because I
> > return a custom object not a Hashtable/Map that is de-Java-lized:
> >
> > public class WebMacroObject
> > {
> >    public int getCount()
> >    public Iterator getPropertyNames()
> >    public Iterator getPropertyValues()
> >    public void put( String key, Object value )
> >    public Object get( String key )
> >    public void reset()
> >    public void copyFrom( WebMacroObject src )
> >    public void copyFrom( Map src )
> > }
> >
> > This is much cleaner and does not suffer from the Map contract
> > problems. This object can of course be used without #newobject, it is
> > completely standalone. Java heads may shriek at the altered syntax,
> > but I think it stands well in the non-Java world.
> >
> > Shall I commit this object to CVS and edit the { } map constructor
> > mechanism to create an instance of this instead of the Map
> > implementation it does now?
> >
> > ...or is there another solution?
> >
> > I feel that, like my suggestion for a list wrapper object, we should
> > consider providing some special WM types for this kind of stuff to
> > de-Java- lize things further and start building a small "WebMacro
> > Object Model" in this regard, so we can document it clearly for
> > template writers instead of referring them to API Javadocs for Map,
> > for example.
> >
> > Just say the word and WebMacroObject is in CVS and { } updated to use
> > it... and if you really feel friendly you could let me add #newobject
> > to WM to back up the "WebMacro Object Model" :)
> >
> > 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
>
>
>
> -------------------------------------------------------
> 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 01:47  PM, Marc Palmer wrote:

>
> Hi,
>
> I thought I'd try using the #set $xxx = { } mechanism today.
>
> If you remember there was a real hoo-haa about this versus my  
> #newobject directive (which is fine and working well in Ignition I  
> might add!).
>
> Now I tried this:
>
> #set $x = {}
> #foreach $item in $myNameList
>   $x.put( $item, $values.get($item) )
> #end
>
> ...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.

eric

>
> This is really bad news. #newobject does not suffer this because I  
> return a custom object not a Hashtable/Map that is de-Java-lized:
>
> public class WebMacroObject
> {
>    public int getCount()
>    public Iterator getPropertyNames()
>    public Iterator getPropertyValues()
>    public void put( String key, Object value )
>    public Object get( String key )
>    public void reset()
>    public void copyFrom( WebMacroObject src )
>    public void copyFrom( Map src )
> }
>
> This is much cleaner and does not suffer from the Map contract  
> problems. This object can of course be used without #newobject, it is  
> completely standalone. Java heads may shriek at the altered syntax,  
> but I think it stands well in the non-Java world.
>
> Shall I commit this object to CVS and edit the { } map constructor  
> mechanism to create an instance of this instead of the Map  
> implementation it does now?
>
> ...or is there another solution?
>
> I feel that, like my suggestion for a list wrapper object, we should  
> consider providing some special WM types for this kind of stuff to  
> de-Java- lize things further and start building a small "WebMacro  
> Object Model" in this regard, so we can document it clearly for  
> template writers instead of referring them to API Javadocs for Map,  
> for example.
>
> Just say the word and WebMacroObject is in CVS and { } updated to use  
> it... and if you really feel friendly you could let me add #newobject  
> to WM to back up the "WebMacro Object Model" :)
>
> 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

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

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

Hi,

I thought I'd try using the #set $xxx = { } mechanism today.

If you remember there was a real hoo-haa about this versus my #newobject 
directive (which is fine and working well in Ignition I might add!).

Now I tried this:

#set $x = {}
#foreach $item in $myNameList
   $x.put( $item, $values.get($item) )
#end

...and guess what? I get all the values in the output because put() returns 
an Object!

This is really bad news. #newobject does not suffer this because I return a 
custom object not a Hashtable/Map that is de-Java-lized:

public class WebMacroObject
{
    public int getCount()
    public Iterator getPropertyNames()
    public Iterator getPropertyValues()
    public void put( String key, Object value )
    public Object get( String key )
    public void reset()
    public void copyFrom( WebMacroObject src )
    public void copyFrom( Map src )
}

This is much cleaner and does not suffer from the Map contract problems. 
This object can of course be used without #newobject, it is completely 
standalone. Java heads may shriek at the altered syntax, but I think it 
stands well in the non-Java world.

Shall I commit this object to CVS and edit the { } map constructor 
mechanism to create an instance of this instead of the Map implementation 
it does now?

...or is there another solution?

I feel that, like my suggestion for a list wrapper object, we should 
consider providing some special WM types for this kind of stuff to de-Java- 
lize things further and start building a small "WebMacro Object Model" in 
this regard, so we can document it clearly for template writers instead of 
referring them to API Javadocs for Map, for example.

Just say the word and WebMacroObject is in CVS and { } updated to use it... 
and if you really feel friendly you could let me add #newobject to WM to 
back up the "WebMacro Object Model" :)

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] #templet/#eval directives

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

On Wed, 23 Jul 2003 10:06:00 -0700, Lane Sharman <la...@op...> 
wrote:

>> On Wed, 23 Jul 2003 10:11:37 -0400, Keats <ke...@ea...> wrote:
>> #set $FieldType = "name"
>> #eval "render$FieldType" using $myMap
>> #set $FieldType = "date"
>> #eval "render$FieldType" using $myMap
>> #set $FieldType = "email"
>> #eval "render$FieldType" using $myMap
>
> how about using a macro today, Marc. The above indirection buys you a can 
> of worms. Do this today:
>
> #rendername $myMap
> #renderdate $myMap
> #renderemail $myMap

No, that is exactly what I want to avoid! I am doing that at the moment and 
it's really bad news I'm afraid. It's very boring and results in huge 
#if...#elseif statements if you have lots of types.

What I'm trying to do is exactly like:

 #include as template "snippets/$(fieldType).wmt"

...but for calling macros/templets. I will not know at template-writing 
time what types will be available, so I cannot do this unless I force my 
end-user (web guy) to maintain this file, which is not desirable. i.e. 
given a list of field objects with a type name associate with them, I want 
to be doing this:

#include as macro "includes/fieldRenderers.wmt"

#set $vars = { "values" : $valuesMap }
#foreach $field in $fieldList
   #eval $GetVariable("render$field.TypeName") using $vars
#end

This way the template is clean and free of schema dependencies. Anybody 
introducing new types simply has to edit fieldRenderers.wmt to add a 
templet for the type they need. It's simple and completely hassle-free.

As Keats has backed up my thoughts on this (using a Map) and pointed out 
the indirection approach, I think we're getting somewhere.

I think the context-aware function is the best bet, used to obtain the 
variable containing the templet.

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] Helping with the problems of nulls

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

Marc Palmer wrote:

>
> If you're wondering why I'm bombarding the list so much at the moment 
> (apologies) it's because I'm working on a real-life web site now that 
> uses Ignition.
>
> Wading through the complexitis of metadata/schema based data capture, 
> with most of the problems solved by Ignition, in some places I'm 
> encountering / getting bored with the same old "is it null or not 
> before I evaluate it" problem.

This problem has been solved. Use SparseProperties as a wrapper around 
fields which may or may not be null and for which you do not want to 
test for nullness. Use it all the time in my WM processing and it 
elegantly solves the problems:

Optional Values:<br>
$Render($Schema.FirstName)<br>
$Render($Schema.LastName)<br>

If FirstName and LastName are not found in the map, you can have the 
instance of SparseProperties return "", null, "Not Defined" or whatever 
you like.



>
>
> This has probably been mentioned before, but what about something like:
>
> #safe $myVar
>
> Whatever you want to call #safe... but the idea is it will only 
> evaluate the variable if it is not null. If it is null, it will do 
> nothing. Diddly squat. You could - and this is probably stupid - 
> extend it with an #else sub-directive, so it is mereley an abbreviated 
> form of #if:
>
> #safe $myVar
> #else You have not set the variable!
> #end
>
> The advantage here over #if is that you don't need to specify a block 
> for the "not null" case because the variable is your output.
>
> The other alternative is a trivial function:
>
> $safe($myVar, "You have not set the variable!")
>
> Which is functionally identical. This second form is a bit nicer in 
> usage because you don't have the whitespace "nuances" we've discussed 
> with directives. However I like the directive syntax better if there 
> wasn't the whitespace hassle:
>
> <input name="x" value="#safe $valueOfX #else Enter a Value #end"> 

Using sparse properties:

<input name="x" value="$Values.x">

will return the value of x if it is not null or "Enter a Value" if that 
is the default for a null value.

Check out this helper, Marc.

-Lane

>
>
> If something like this isn't already in the distro we should 
> definitely add it. It doesn't solve all of the problems, but it would 
> sure make some templates more readable and less boring to maintain!
>
> I'm happy to write this (yes of course it's trivial) and commit it if 
> people think this is worthy of WM core/options status.
>
> Marc
>

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

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

> ... I think the signature to the scripter should be the same as the
signature to the author so that the method description and use is uniform.
So, I tend to agree with Marc's critique of Keat's hidden Context parameter.

I disagree strongly here.  The whole point of the script language is to
simplify the syntax for the scripter.  We tend to see things through the
eyes of a Java coder, rather than a Web page designer.  The designer
shouldn't have to know anything about the Context object, just what
functions are available in for scripting.

As an analogy, Java implicitly includes the instance variable "this" in
non-static method calls as a convenience to the programmer.  Other
languages, such as Python, make you supply it as an argument, which I find a
pain.

Keats

Re: [Webmacro-devel] Helping with the problems of nulls

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

The #default directive does something like this, although it doesn't deal
with null, just undefined:

#default $myVar="Not specified"
$myVar

We've talked about this over the years.  It's kind of like the NVL function
in Oracle.  A simple function for this might be nice:

$nvl($myVar, "*NO VALUE*")

as an abbreviated form of

#if ($myVar){$myVar} else {*NO VALUE*}

I'd endorse something like this.

Keats

Re: [Webmacro-devel] #templet/#eval directives

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

Marc Palmer wrote:

> On Wed, 23 Jul 2003 17:11:03 +0100, Marc Palmer <ma...@an...> 
> wrote:
>
>
> Truly nasty, I grant you. I'm just trying to think of a way to achieve 
> this. 

I think it is too much English briar bush or one of those monster sand 
traps from hell you brits like to play in. :)

-L

>
>
>
>
>

Re: [Webmacro-devel] #templet/#eval directives

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

Marc Palmer wrote:

> On Wed, 23 Jul 2003 10:11:37 -0400, Keats <ke...@ea...> wrote:
> #set $FieldType = "name"
> #eval "render$FieldType" using $myMap
> #set $FieldType = "date"
> #eval "render$FieldType" using $myMap
> #set $FieldType = "email"
> #eval "render$FieldType" using $myMap 

how about using a macro today, Marc. The above indirection buys you a 
can of worms. Do this today:

#rendername $myMap
#renderdate $myMap
#renderemail $myMap

-Lane

>
>
> ...from what you say I don't think this is possible, but could we make 
> it possible somehow? It would really make rendering things from a 
> flexible schema (based on type) so much easier.
>
> Otherwise we have to use #include with lots of little script files.
>
>>> I look forward to trying this out!
>>
>>
>> Please do.  I'll try to commit today.
>
>
> Great!
>
> FWIW I've been using the head revision today (Brian's profiling 
> removals etc) and its working fine here as far as I can tell. That 
> webmacro.jar just keeps on shrinking!
>
> Marc

Re: [Webmacro-devel] Context-aware functions

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

Marc Palmer wrote:

> On Wed, 23 Jul 2003 10:34:21 -0400, Keats <ke...@ea...> wrote:
>
> Yes! That's exactly what I'm after. Any objections to me doing this? 

Go ahead. You can expose the new functionality as a context tool wrapper :).

-Lane


>
>
>> Then you could write a context-aware function, like:
>>
>> static public java.util.List listTools(org.webmacro.Context context){
>> return new
>> java.util.ArrayList(context.getBroker().getFunctions().keySet());
>> }
>
>
> Well actually I just think we need access to this from Java code. If 
> we want to wrap it in tools we can - but there is so much more to 
> providing help (like introspecting beans etc) that I do it all in Java 
> and expose wrappers.
>
> Marc

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

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

On Wed, 23 Jul 2003 09:39:36 -0700, Lane Sharman <la...@op...> 
wrote:

> Finally, do we want to create a module, Optional, which has non-core 
> classes where we can locate web, tools, and other things not essential to 
> running the WebMacro engine?

Yes yes yes! It's on the NextRelease page :-)

I have some code from Ignition to contribute to this - XML DOM helper with 
DOM caching, nice Date helpers, File system helpers and RSS feed rendering 
templates.

I'd really like to get these general purpose helpers out of Ignition and 
into some WM distributable that isn't core, and doesn't require a CVS 
checkout and build! i.e. WebMacroOptional.zip containing a templates/ tree 
and a webmacro-opt.jar containing the pre-built tools.

Ignition would bundle both so that the existing tools I have will be drawn 
instead from WM, and everybody who doesn't use Ignition (yep, that's 
everybody right now!) can make use of these tools too.

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