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

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

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

> What I mean is can I alter the name of the macro to #eval dynamically -
> i.e.:
>
> #set $FieldType = "name"
> #eval "render$FieldType" using $myMap
> #set $FieldType = "date"
> #eval "render$FieldType" using $myMap
> #set $FieldType = "email"
> #eval "render$FieldType" using $myMap
>

I'm not sure exactly what you're trying to do, but let me guess.  You have
Macros defined in variables $renderName, $renderDate, and $renderEmail.
You'd like to invoke the appropriate macro based on $FieldType.

How about using a map:

#set $renders =
{
   "Name": $renderName,
   "Date": $renderDate,
   "Email": $renderEmail
}
#set $renderer = $renderers.Name
#eval $renderer using $myMap
#set $renderer = $renderers.Date
#eval $renderer using $myMap
#set $renderer = $renderers.Email
#eval $renderer using $myMap

You could also do this using some kind of Macro indirection, but that's kind
of tricky and unintuitive.  Something like:

#templet $rendererMacro { \$render$FieldType }
#set $FieldType="Name"
#eval $rendererMacro using $myMap
#set $FieldType="Date"
#eval $rendererMacro using $myMap
#set $FieldType="Email"
#eval $rendererMacro using $myMap

I think something like this could work.  Maybe I'll try it later.

We could add a simple method to the VariableTool (remember that one? Not
much used anymore), like:

   $Variable.get("render$FieldType")

or, of course, a context-aware function:

  $variable("render$FieldType")

Keats

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

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

Keats wrote:

>Please do.  I'll try to commit today.
>
>Keats
>

I added this feature to the NextRelease wiki page.

-Lane

>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>  
>

[Webmacro-devel] Helping with the problems of nulls

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

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

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

-- 
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] Voting on the ContextTool issue?

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

I tend to agree with Marc that our first and foremost objective is to 
make WM transparent and regular. By that, it is easy to see all the 
moving parts and the moving parts all work according to a set of uniform 
operating rules, protocols.

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.

As to static method objects, I think this is a big win and 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.

One of my earliest complaints about WebMacro is the signature, 
getContext() which is really a factory and should be called 
createContext(). I was so confused about this early on in my use of WM. 
Could we deprecate getContext() and use createContext() as the preferred 
method?

Also, I am really keen on the templet/eval going in to release 2 and its 
ability to recurse.

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?

-Lane



Brian Goetz wrote:

>>Guys how about we get a vote going on the ContextTool issue.
>>    
>>
>
>WAY premature.  
>
>  
>
>>Sure we need context-aware template variables, but this should probably be 
>>done another way - i.e. in Context.put we do:
>>
>>if (o instanceof ContextAware)
>>   ((ContextAware)o).init( this);
>>    
>>
>
>No, this is making everyone pay for a feature that only .01% of
>variables will use.
>
>  
>
>>Either way, ContextTools seem unnecessary.
>>    
>>
>
>The primary benefit to context tools is that they are _automatically_
>available.  This seems a good thing.  
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>_______________________________________________
>Webmacro-devel mailing list
>Web...@li...
>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>
>  
>

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

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

On Wed, 23 Jul 2003 17:18:12 +0100, Marc Palmer <ma...@an...> wrote:

>> What I mean is can I alter the name of the macro to #eval dynamically - 
>> i.e.:
>>
>> #set $FieldType = "name"
>> #eval "render$FieldType" using $myMap
>> #set $FieldType = "date"
>> #eval "render$FieldType" using $myMap
>> #set $FieldType = "email"
>> #eval "render$FieldType" using $myMap
>
> Hmm, of course that is not possible at the moment but I wonder how we 
> could make it so we can do something like that. Would we be looking at an 
> alternative syntax for variable resolution (PropertyOperatorCache hell 
> noooooooo!) such as:
>
> The value of your dynamic var is: $"render$SomeVar"
>
> Truly nasty, I grant you. I'm just trying to think of a way to achieve 
> this.

Hmm one way to achieve this that isn't as anywhere as clean as I'd like is:

#template $templetA
 ...
#end

#template $templetB
 ...
#end

#template $templetC
 ...
#end

#set $renderers = {}
#set $renderers.email = $templetA
#set $renderers.name = $templetB
#set $renderers.date = $templetC

#set $FieldType = "name"
#eval $renderers.get($FieldType) using $myMap
#set $FieldType = "date"
#eval $renderers.get($FieldType) using $myMap
#set $FieldType = "email"
#eval $renderers.get($FieldType) using $myMap


It's doable, and arguably nicer than a series of small template include 
files, but it's error-prone in terms of forgetting to add a templet to the 
$renderers map.

It's progress though. Any other bright ideas? How about a context-aware 
function that gets a variable from the current context by name? i.e:

#set $var = $GetVariable("renderer$FieldType")

which would then work as:

#set $FieldType = "name"
#eval $GetVariable("renderer$FieldType") using $myMap
#set $FieldType = "date"
#eval $GetVariable("renderer$FieldType") using $myMap
#set $FieldType = "email"
#eval $GetVariable("renderer$FieldType") using $myMap

This would seem to be a much nicer solution, though I am sure somebody will 
not like it. :-)

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 17:11:03 +0100, Marc Palmer <ma...@an...> wrote:

> What I mean is can I alter the name of the macro to #eval dynamically - 
> i.e.:
>
> #set $FieldType = "name"
> #eval "render$FieldType" using $myMap
> #set $FieldType = "date"
> #eval "render$FieldType" using $myMap
> #set $FieldType = "email"
> #eval "render$FieldType" using $myMap

Hmm, of course that is not possible at the moment but I wonder how we could 
make it so we can do something like that. Would we be looking at an 
alternative syntax for variable resolution (PropertyOperatorCache hell 
noooooooo!) such as:

The value of your dynamic var is: $"render$SomeVar"

Truly nasty, I grant you. I'm just trying to think of a way to achieve 
this.




-- 
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:11:37 -0400, Keats <ke...@ea...> wrote:

>> May I suggest an alternative naming for $OuterVars though? How about:
>>
>> $Outer or $Template
>
> $Outer would probably be OK.

It just seems a little cleaner.

>> Can #eval take a Macro as the templet name? i.e. #eval 
>> "render$FieldType"
>> using $myMap  ?
>
> #eval can work with any Macro, but it must be in a variable.  #templet 
> just
> stores a Block in a variable, just like "#setblock as macro".  You should 
> be
> able to put any Macro implementation into the context and invoke it with
> #eval.  E.g.,
>
> // Java
> Template t = new StringTemplate(broker, "$A $B $C");
> context.put("abc", t);
>
> ## WMScript
> #eval $abc using { "A": "Three", "B": "blind", "C": "mice" }
>
> (Sorry, I was reading nursery rhymes to my daughter this morning.)

Hehe. I'm afraid I think you've misunderstood me though.

What I mean is can I alter the name of the macro to #eval dynamically - 
i.e.:

#set $FieldType = "name"
#eval "render$FieldType" using $myMap
#set $FieldType = "date"
#eval "render$FieldType" using $myMap
#set $FieldType = "email"
#eval "render$FieldType" using $myMap

...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
-- 
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] Context-aware functions

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

On Wed, 23 Jul 2003 10:34:21 -0400, Keats <ke...@ea...> wrote:

>> I would have thought that a cleaner way to do this would be to 
>> explicitly
>> pass the context - i.e. make it available in the template (if we don't
>> already - never tried it):
>>
>> #foreach $varName in $varlist($Context) {
>>
>
> We don't make the context available in the context.  This would be
> dangerous, as the scripter could screw up all sorts of things.

I realise that, but wondered if we might be able to do something 
interesting to stop it appearing as a full context var in the template.

> We could may put something into the context that would allow the function 
> to
> get to the context, maybe a reserved word like "context", but this would 
> add
> clutter to the script language.

Yes, true.

[snip]
>> That is, if we can get WM to expose the list of functions that are setup
>> and their signatures (or Method objects).
>>
>> I have a problem with Ignition right now - because WM does not seem to
>> expose such config'd objects - in that I can't show help info about
>> ContextTools or functions. I could read the properties myself and work 
>> it
>> out but that's a hell of a lot of duplicated work.
>
> We could easily provide methods (like my $varlist() example) that report
> stuff like this.  In the current sources, Broker maintains a map of tools
> and one of functions which we could expose by adding getTools() and
> getFunctions().

Yes! That's exactly what I'm after. Any objections to me doing this?

> 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
-- 
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] Context-aware functions

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

> I would have thought that a cleaner way to do this would be to explicitly
> pass the context - i.e. make it available in the template (if we don't
> already - never tried it):
>
> #foreach $varName in $varlist($Context) {
>

We don't make the context available in the context.  This would be
dangerous, as the scripter could screw up all sorts of things.

We could may put something into the context that would allow the function to
get to the context, maybe a reserved word like "context", but this would add
clutter to the script language.

> This makes it much clearer what is going on, and a self-documenting system
> can show that the functions require a context parameter and it makes
sense -
>  whereas a scheme where it is implicitly passed makes this hard - the doc
> system needs to know about the implicit passing, and suppress the argument
> list. It all seems like a lot of hassle (and maintenance) for not very
much
> gain.

The script writer doesn't need to know that a context is getting passed in.
He/she just needs to know how to call the thing and what to expect back.
The idea is to simplify the scripts -- the Java stuff is simple enough for a
programmer.

I think the new self-documenting requirement is interesting, but a separate
issue.  It should be simple enough to introspect on a method and see if its
first param is a Context -- in fact I'm already doing this.

> That is, if we can get WM to expose the list of functions that are setup
> and their signatures (or Method objects).
>
> I have a problem with Ignition right now - because WM does not seem to
> expose such config'd objects - in that I can't show help info about
> ContextTools or functions. I could read the properties myself and work it
> out but that's a hell of a lot of duplicated work.

We could easily provide methods (like my $varlist() example) that report
stuff like this.  In the current sources, Broker maintains a map of tools
and one of functions which we could expose by adding getTools() and
getFunctions().

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());
    }


Keats

> Marc

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

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

> May I suggest an alternative naming for $OuterVars though? How about:
>
> $Outer or $Template

$Outer would probably be OK.

> This might seem to make more sense - i.e. $Outer.myVar  or
$Template.myVar.
> The latter may be more confusing, but it's "correct" in the sense that it
> takes vars from the template being rendered rather than the templet.
>
> Can #eval take a Macro as the templet name? i.e. #eval "render$FieldType"
> using $myMap  ?

#eval can work with any Macro, but it must be in a variable.  #templet just
stores a Block in a variable, just like "#setblock as macro".  You should be
able to put any Macro implementation into the context and invoke it with
#eval.  E.g.,

// Java
Template t = new StringTemplate(broker, "$A $B $C");
context.put("abc", t);

## WMScript
#eval $abc using { "A": "Three", "B": "blind", "C": "mice" }

(Sorry, I was reading nursery rhymes to my daughter this morning.)

> I look forward to trying this out!

Please do.  I'll try to commit today.

Keats

[Webmacro-devel] Minor updates to NextRelease

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

I have updated: http://www.webmacro.org/NextRelease

...to keep up to date with Keats' and Brian's progress.

Anybody else out there using SmartCVS? I just downloaded it today and it 
ROCKS! Java CVS client with built in SSH and some great features - like the 
Annotate option which shows which users put which lines into the source 
file. That's how I spotted that I'd screwed up and left some test code in 
PropertyOperatorCache :-)

www.smartcvs.com

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] Voting on the ContextTool issue?

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

> >> Guys how about we get a vote going on the ContextTool issue.
> >
> > WAY premature.
> 
> Why? We need to get consensus on what direction the changes should take.

I think a "call for discussion" is more in order at this point.  The
concept was just raised two weeks ago and you're already calling for a
vote to remove a feature people may use?

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

> > The primary benefit to context tools is that they are _automatically_
> > available.  This seems a good thing.
> 
> Not in all respects, and we know already that two of the developers 
> disagree with you on this :-)

Then make your case, compellingly!  

> Well why don't we have a vote on this to see what other developers
> actually think. We set the case out for them and against them and
> let people decide.  Otherwise we may be making code changes that are
> not necessary, wasting everybody's time.

I think you're skipping the most important part of a pseudo-democratic
process -- spirited discussion and free exchange of ideas.  I'm not
against the concept of voting, I just think the proposals at hand are
not remotely ready for a vote.  

> 1) Do we keep ContextTools or get rid of them

So far, no one has made a compelling case against them.  And with the
most recent round of changes, the performance cost of keeping them got
smaller.

And what about backward compatibility?  Lots of people use the existing
context tools.  

> 2) The possibility of providing a "destroy mechanism" for context variables 
> and tools if CTs survive the first vote, or just eliminating this concept 
> and force the application to deal with it.

Totally separate issue. 

> 3) The possibility of providing a reference to the Context to context 
> variables (especially if CTs do not survive vote 1).

Totally separate issue.

> Surely this is a slightly more organised way to go about things, which 
> ensures that everybody has a chance to express their views?

express, yes.  Usually the vote happens after everything that can be said
is said, not the other way around.

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

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

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:

WebMacro Error:

Could not initialize the broker!
*** Check that WebMacro.properties was in your servlet
*** classpath, in a similar place to webmacro.jar *** and that all values 
were set correctly.
IO Error reading WebMacro.defaults
java.io.FileNotFoundException: JAR entry WebMacro.defaults not found in 
E:\Program Files\Apache Group\Tomcat 4.1\webapps\ignition\WEB- 
INF\lib\webmacro.jar
Please contact the server administrator


Do we know why this is happening? It is hard to see how it can be a WM 
thing, as it looks more like a generic classloader issue.

However I think this is a pretty serious problem we need to address, 
because it is really bad news if you have to ask a network admin to restart 
a shared Tomcat instance, thus bringing down everybody else's sites.

It looks like the problem is occurring here in Settings:

    public void load (String fileName) throws InitException, IOException
    {
        ClassLoader cl = this.getClass().getClassLoader();
        URL u = (cl == null) ? null : cl.getResource(fileName);
        if (u == null)
            u = ClassLoader.getSystemResource(fileName);
        if (u == null)
            try
            {
                u = new URL("file:" + fileName);
            }
            catch (MalformedURLException e)
            {
            }
        ;

	....
    }

Now, as the webapp is being reloaded by the container, everything should be 
running on top of a new ClassLoader and therefore this probably should work 
fine.

Perhaps there is some strange issue here with servlet containers (this is 
seen in Tomcat 4.1.18, 4.1.24 and I think Eric said Resin 2.x too) that we 
could work around by using ServletContext.getResource in Settings?

This would mean refactoring Settings to pass in the URL instead of the 
filename, which could be a good thing - putting the responsibility of 
finding the file on the caller (Broker).

Anybody think they might know what's going on here?

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 Mon, 21 Jul 2003 11:25:41 -0400, Keats <ke...@ea...> wrote:

> I'm about ready to commit the #templet and #eval directives.  I added a
> couple of things to #eval.  In the new context of the #eval I add the
> following variables:  $OuterVars, $EvalDepth, and $Self.

This looks really cool Keats.

May I suggest an alternative naming for $OuterVars though? How about:

$Outer

or

$Template

This might seem to make more sense - i.e. $Outer.myVar  or $Template.myVar. 
The latter may be more confusing, but it's "correct" in the sense that it 
takes vars from the template being rendered rather than the templet.

Can #eval take a Macro as the templet name? i.e. #eval "render$FieldType" 
using $myMap  ?

I look forward to trying this out!

-- 
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] Voting on the ContextTool issue?

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

On Wed, 23 Jul 2003 02:11:21 -0700, Brian Goetz <br...@qu...> wrote:

>> Why? We need to get consensus on what direction the changes should take.
>
> I think a "call for discussion" is more in order at this point.  The
> concept was just raised two weeks ago and you're already calling for a
> vote to remove a feature people may use?
>
> 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.

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

1. ContextTools are too much "magic". They are not part of the language 
like directives, yet they are specified in the WM config, which is 
invariably editable by end-users and as such they could break your 
application by changing context tools used.

2. You can't extract info from WM at runtime about what context tools are 
available.

3. Few people actually write their own context tools, instead using 
variables anyway, because it is under application (not WM config) control. 
ContextTools are used by some WM "elite" users but mainly it's just to 
supply WM "default" variables such as Form and List etc.

4. Some of the ContextTools are already being "replaced" by global 
functions.

5. The issue of lazy initialisation of tools would probably be far better 
served by abstracting the mechanism to some kind of LazyToolFactory 
interface which is pluggable in WM config. i.e. people who really want 
ContextTools could still keep them by plugging in a WM-supplied 
ContextToolFactory impl of LazyToolFactory. This mechanism simplifies WM 
(just call into the factory and forget the details) and means that people 
can avoid the spectre of magical tools appearing in the context due to user 
config, if they so wish.

>> Well why don't we have a vote on this to see what other developers
>> actually think. We set the case out for them and against them and
>> let people decide.  Otherwise we may be making code changes that are
>> not necessary, wasting everybody's time.
>
> I think you're skipping the most important part of a pseudo-democratic
> process -- spirited discussion and free exchange of ideas.  I'm not
> against the concept of voting, I just think the proposals at hand are
> not remotely ready for a vote.

My proposal was that we vote on the gist of the direction to take, not the 
specific solutions.

>> 1) Do we keep ContextTools or get rid of them
>
> So far, no one has made a compelling case against them.  And with the
> most recent round of changes, the performance cost of keeping them got
> smaller.
>
> 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.

>> 2) The possibility of providing a "destroy mechanism" for context 
>> variables and tools if CTs survive the first vote, or just eliminating 
>> this concept and force the application to deal with it.
>
> Totally separate issue.
>
>> 3) The possibility of providing a reference to the Context to context 
>> variables (especially if CTs do not survive vote 1).
>
> Totally separate issue.

Yes, but I was illustrating the potential course of the decision making 
process. I'm just trying to move things along Brian.

>> Surely this is a slightly more organised way to go about things, which 
>> ensures that everybody has a chance to express their views?
>
> express, yes.  Usually the vote happens after everything that can be said
> is said, not the other way around.

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.

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] Voting on the ContextTool issue?

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

On Wed, 23 Jul 2003 01:26:56 -0700, Brian Goetz <br...@qu...> wrote:

>> Guys how about we get a vote going on the ContextTool issue.
>
> WAY premature.

Why? We need to get consensus on what direction the changes should take.

>> Sure we need context-aware template variables, but this should probably 
>> be done another way - i.e. in Context.put we do:
>>
>> if (o instanceof ContextAware)
>> ((ContextAware)o).init( this);
>
> No, this is making everyone pay for a feature that only .01% of
> variables will use.
>
>> Either way, ContextTools seem unnecessary.
>
> The primary benefit to context tools is that they are _automatically_
> available.  This seems a good thing.

Not in all respects, and we know already that two of the developers 
disagree with you on this :-)

Well why don't we have a vote on this to see what other developers actually 
think. We set the case out for them and against them and let people decide. 
Otherwise we may be making code changes that are not necessary, wasting 
everybody's time.

As I see it there is one initial issue:

1) Do we keep ContextTools or get rid of them

Then based on that decision we look at:

2) The possibility of providing a "destroy mechanism" for context variables 
and tools if CTs survive the first vote, or just eliminating this concept 
and force the application to deal with it.

3) The possibility of providing a reference to the Context to context 
variables (especially if CTs do not survive vote 1).

Then after 2 and 3 are decided, we can work on the implementation scheme to 
use for each.

Surely this is a slightly more organised way to go about things, which 
ensures that everybody has a chance to express their views?


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] Voting on the ContextTool issue?

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

> Guys how about we get a vote going on the ContextTool issue.

WAY premature.  

> Sure we need context-aware template variables, but this should probably be 
> done another way - i.e. in Context.put we do:
> 
> if (o instanceof ContextAware)
>    ((ContextAware)o).init( this);

No, this is making everyone pay for a feature that only .01% of
variables will use.

> Either way, ContextTools seem unnecessary.

The primary benefit to context tools is that they are _automatically_
available.  This seems a good thing.  

[Webmacro-devel] Voting on the ContextTool issue?

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

	
Guys how about we get a vote going on the ContextTool issue.

I think I'm right in saying that both Eric and I are pretty much in favour 
of removing context tools completely. They have outlived their purpose.

Sure we need context-aware template variables, but this should probably be 
done another way - i.e. in Context.put we do:

if (o instanceof ContextAware)
   ((ContextAware)o).init( this);

Nice, simple, fast, and most importantly, does not require the objects to 
be put into the WM config to be context-aware. Of course this may be 
redundant because the supplier of the variable can always just set the 
context on the variable themselves anyway.

Either way, ContextTools seem unnecessary.

On the context tool destruction thing, I've now come around to the thinking 
that WM should not be doing anything on this front, and Brian is right that 
the application should be controlling this as the app knows when contexts 
are finished with.

WM should not bother itself with anything in this regard.

K.I.S.S.!

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] Context-aware functions

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

On Wed, 23 Jul 2003 00:46:49 -0400, Keats <ke...@su...> wrote:

> Correction: that should have been:
>
> #foreach $varName in $varlist() {

Hmm. I appreciate your efforts on this Keats - but I'm not sure if, 
personally speaking, I like this implicit context scheme.

It makes me feel we are putting too much specialised knowledge into the 
configuration, and it also makes things harder to document for end-users - 
which is the next-generation template scripting problem Ignition is trying 
to address, namely "giving the template writer a clue about what they can 
do".

I would have thought that a cleaner way to do this would be to explicitly 
pass the context - i.e. make it available in the template (if we don't 
already - never tried it):

#foreach $varName in $varlist($Context) {

This makes it much clearer what is going on, and a self-documenting system 
can show that the functions require a context parameter and it makes sense - 
 whereas a scheme where it is implicitly passed makes this hard - the doc 
system needs to know about the implicit passing, and suppress the argument 
list. It all seems like a lot of hassle (and maintenance) for not very much 
gain.

That is, if we can get WM to expose the list of functions that are setup 
and their signatures (or Method objects).

I have a problem with Ignition right now - because WM does not seem to 
expose such config'd objects - in that I can't show help info about 
ContextTools or functions. I could read the properties myself and work it 
out but that's a hell of a lot of duplicated work.

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] Context-aware functions

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

Correction: that should have been:

  #foreach $varName in $varlist() {

Keats

Keats wrote:
> I've implemented the context-aware function idea that I mentioned yesterday.
> Here's a simple example that gives a list of variable names from the current
> context:
> 
> // Java code
> package org.webmacro.util;
> public class VarList
> {
>     static public java.util.List varlist(org.webmacro.Context context){
>         return new java.util.ArrayList(context.keySet());
>     }
> }
> 
> # WebMacro properties
> Functions.varlist: org.webmacro.util.VarList.varlist
> 
> ## Template script
> 
> #set $someVar="Some val"
> #set $anotherVar=1234
> <h3>Variables in the context</h3>
> #foreach $varName in $varlist {
>    $varName<br>
> }
> 
> Cool, eh?
> 
> Of course I need to do some tests ...
> 
> Keats
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel
> 

[Webmacro-devel] Context-aware functions

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

I've implemented the context-aware function idea that I mentioned yesterday.
Here's a simple example that gives a list of variable names from the current
context:

// Java code
package org.webmacro.util;
public class VarList
{
    static public java.util.List varlist(org.webmacro.Context context){
        return new java.util.ArrayList(context.keySet());
    }
}

# WebMacro properties
Functions.varlist: org.webmacro.util.VarList.varlist

## Template script

#set $someVar="Some val"
#set $anotherVar=1234
<h3>Variables in the context</h3>
#foreach $varName in $varlist {
   $varName<br>
}

Cool, eh?

Of course I need to do some tests ...

Keats

Re: [Webmacro-devel] ContextTool improvements

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

I know where you are at about the statelessness and the object creation 
overhead. Based on what I have been reading, I think we should support all.

1) objects in the context on demand w/context (like the tool model).
2) static functions in the context on demand (we have this in global 
functions now)
3) static functions in the context on demand w/ a context argument.(your 
new proposal)

I don't think one size will fit all. I fully recognize the value of 
statelessness, flyweight classes.

Lane

Keats wrote:

>Lane,
>
>This is precisely the way context tools work now.  The problem is that this
>requires a new instance of the tool to be created for each request.  If you
>supply the context with each method call, the class becomes stateless and
>therefore you only need a single instance (or no instance if you use static
>methods).
>
>This is the way functional programming works.  Generally, with object
>oriented programming you store the state in object and this give you a clean
>abstraction.  However, in this case there is a performance hit with so much
>object creation.  By hiding the context argument from the script we can have
>the best of both worlds to some extent -- a shareable stateless class,
>without all the extra parameter passing.
>
>Keats
>
>----- Original Message -----
>From: Lane Sharman
>To: Keats
>Cc: Brian Goetz ; web...@li...
>Sent: Monday, July 21, 2003 6:14 PM
>Subject: Re: [Webmacro-devel] ContextTool improvements
>
>
>Access to the Context is a terrific idea but isn't it better to something
>like this:
>
>
>class StatefulTool implements ContextStateful {
>    Context wc;
>    public void init(Context context) { // the ContextStateful interface
>       wc = context;
>   }
> public String localize(java.util.Date date){
>        return java.text.DateFormat.getDateInstance(
>            java.text.DateFormat.SHORT,
> wc.getRequest().getLocale()).format(date);
> }
>}
>
>
>When the class is references by the web script, its ContextStateful
>interface is handled by the context class itself:
>
>if (tool == null) {
>    String toolClass = loadables.get(name);
>    Object o = Class.forName(toolClass).newInstance();
>    if (o instanceof ContextStateful) {
>        ((ContextStateful) o).init(this)
>    }
>}
>
>It seems to me that every method of a tool and its intance should have a
>reference to the context on an explicit basis by declaring an init() method.
>That, at least, is my take, Keats.
>
>-Lane
>
>
>  
>

-- 
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga
Java Software Portal: http://opendoors.com

Re: [Webmacro-devel] ContextTool improvements

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

Lane,

This is precisely the way context tools work now.  The problem is that this
requires a new instance of the tool to be created for each request.  If you
supply the context with each method call, the class becomes stateless and
therefore you only need a single instance (or no instance if you use static
methods).

This is the way functional programming works.  Generally, with object
oriented programming you store the state in object and this give you a clean
abstraction.  However, in this case there is a performance hit with so much
object creation.  By hiding the context argument from the script we can have
the best of both worlds to some extent -- a shareable stateless class,
without all the extra parameter passing.

Keats

----- Original Message -----
From: Lane Sharman
To: Keats
Cc: Brian Goetz ; web...@li...
Sent: Monday, July 21, 2003 6:14 PM
Subject: Re: [Webmacro-devel] ContextTool improvements


Access to the Context is a terrific idea but isn't it better to something
like this:


class StatefulTool implements ContextStateful {
    Context wc;
    public void init(Context context) { // the ContextStateful interface
       wc = context;
   }
 public String localize(java.util.Date date){
        return java.text.DateFormat.getDateInstance(
            java.text.DateFormat.SHORT,
 wc.getRequest().getLocale()).format(date);
 }
}


When the class is references by the web script, its ContextStateful
interface is handled by the context class itself:

if (tool == null) {
    String toolClass = loadables.get(name);
    Object o = Class.forName(toolClass).newInstance();
    if (o instanceof ContextStateful) {
        ((ContextStateful) o).init(this)
    }
}

It seems to me that every method of a tool and its intance should have a
reference to the context on an explicit basis by declaring an init() method.
That, at least, is my take, Keats.

-Lane

Re: [Webmacro-devel] ContextTool improvements

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

Access to the Context is a terrific idea but isn't it better to=20
something like this:

class StatefulTool implements ContextStateful {
    Context wc;
    public void init(Context context) { // the ContextStateful interface
       wc =3D context;
   }

 public String localize(java.util.Date date){
        return java.text.DateFormat.getDateInstance(
            java.text.DateFormat.SHORT,
	wc.getRequest().getLocale()).format(date);
 }
}


When the class is references by the web script, its ContextStateful=20
interface is handled by the context class itself:

if (tool =3D=3D null) {
    String toolClass =3D loadables.get(name);
    Object o =3D Class.forName(toolClass).newInstance();
    if (o instanceof ContextStateful) {
        ((ContextStateful) o).init(this)
    }
}

It seems to me that every method of a tool and its intance should have a=20
reference to the context on an explicit basis by declaring an init()=20
method. That, at least, is my take, Keats.

-Lane





Keats wrote:

>I agree with Brian that the lazy instantiation is critical.   (I don't
>understand the bit about the previous implementations not exploiting thi=
s --
>I'm pretty sure they did.)
>
>In addition, we need to continue to support "stateful" context tools (to=
ols
>that have access to the current context).
>
>There is still room for improvement here.  Stateless tools shouldn't be
>required to conform to a ContextTool interface, and static tools should =
be
>supported.
>
>Functions can actually handle the stateless stuff pretty nicely, so we m=
ay
>not really need the stateless tools at all.   However it might be nice t=
o
>keep them for backwards compatibility.
>
>I've been thinking about creating stateful functions.  The idea is that =
if
>the first argument to a function is a Context (or subclass) then have th=
e
>introspection engine supply it automagically.  E.g.,
>
>public class Localizer {
>    public String localize(org.webmacro.servlet.WebContext wc,
>java.util.Date date){
>        return java.text.DateFormat.getDateInstance(
>            java.text.DateFormat.SHORT,
>wc.getRequest().getLocale()).format(date);
>    }
>}
>
>    Put this into the template, like:
>
>    context.putContextFunction("localize", Localizer.class, "localize");
>
>    or
>
>    # WebMacro.properties
>    ContextFunctions.localize=3Dorg.webmacro.util.Localizer.localize
>
>   And then use it in a template:
>
>   $localize($date)
>
>This should be quite lightweight, and could allow us to replace all of o=
ur
>tools with functions.
>
>Thoughts?
>
>Keats
>
>----- Original Message -----
>From: "Brian Goetz" <br...@qu...>
>To: "Lane Sharman" <la...@op...>
>Cc: "Endre St=F8lsvik" <web...@st...>; "Eric B. Ridge"
><eb...@tc...>; <web...@li...>
>Sent: Monday, July 21, 2003 2:52 PM
>Subject: Re: [Webmacro-devel] Fwd: [WebMacro-cvs]
>webmacro/src/org/webmacro/util IntMap.java,1.4,NONE
>QueueWriter.java,1.8,NONE SimpleStack.java,1.5,NONE
>SparseArrayIterator.java,1.4,NONE SparseProperties.java
>
>
> =20
>
>>>First, a context tool goes away in release 2. It is just a context
>>>object like any other.
>>>
>>>Second, the only way to automatically get an object in the context is =
to
>>>make a declaration in WebMacro.properties not WebMacro.defaults:
>>>     =20
>>>
>>The support we now have for lazy loading of tools makes Context
>>construction much lighter weight.  The thing that differentiates
>>context tools from ordinary objects is that they "know" that their
>>instantiation can be deferred until they're needed.  The previous
>>implemntation didn't exploit this, but the current one does.  This is
>>a useful thing to keep.
>>
>>In other words, the runtime cost to users of having context tools
>>declared which they're not going to use under the current
>>implemementation is zero.  Any replacement should have the same
>>charcteristic.
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: VM Ware
>>With VMware you can run multiple operating systems on a single machine.
>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>>_______________________________________________
>>Webmacro-devel mailing list
>>Web...@li...
>>https://lists.sourceforge.net/lists/listinfo/webmacro-devel
>>   =20
>>
>
>N=18=ACHY=DE=B5=E9s(S(X=AC=B2s('=B2S(=DEu=BC.1f=AByh=AD...S0j=B7=B2=A2=E7=
=1Az(=BB=A7s(=E9mS(^(TM)^=A2--=ABj=D8=A7,=CC=AC=B5=E9=AC=A2v=ACS(x%zfoe+)=
=DEX"=C79D=D1=10=13Z(LfF2,KS({=B1=FDh=A7vOE,=FC=DA/zYoS(=BBnjYs(r=18=A7z=C6=
=AD=B6=17=ACjg=ADS(g...=AD=E7=AD=AE&=A5rXoe'=17=ABz=1Bm=A7=FF=F0=C3=0B=E6=
=C1=AA=DEr0/00=BF=C2_=E8}=F7=AB=FF~9=FF=FFEz(nfoe=AE++^=BD=E9fj)bz(	b=B2=D5=
z(nfoe=AE++^=BD=E9eS(=CBl=B2<=ABq=E7=E8=AE=07=A7z=D8m=B6>?=FEX=AC=B6=CB(=BA=
=B7=1E~S(=E0zw=AD=FEX=AC=B6=CF=E5S(=CBb?=FA?=C1=E6=E6i=CA=E8u=EB=DEl=3D=3D=
=3D
>

--=20
Lane Sharman
Learn About Conga, All Java GUI Builder: http://opendoors.com/conga
Java Software Portal: http://opendoors.com

Re: [Webmacro-devel] More pruning: Filter

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

I've done the deed. Let me know if I hosed anything.

Keats

----- Original Message -----
From: "Brian Goetz" <br...@qu...>
To: "Keats" <ke...@ea...>
Cc: <web...@li...>
Sent: Monday, July 21, 2003 4:47 PM
Subject: Re: [Webmacro-devel] More pruning: Filter


>
> >I've removed all the Filter crap from my working copy of the sources.
This
> >has been broken for a very long time.  Any objections to me committing
these
> >changes?
>
> THat was on my list to prune too.  I can do it or you can; just sync first
> to make sure you've got a consistent copy of the recent pruning.  Let me
> know if you want me to do it.
>
>
>
> --
> Brian Goetz
> Quiotix Corporation
> br...@qu...           Tel: 650-843-1300            Fax: 650-324-8032
>
> http://www.quiotix.com
>