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

Re: [Webmacro-devel] ACK! Bad new parser bug

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

I think the test case has been modified errantly.

I have examined and worked a lot of the test cases. I have some 
recollection.

I have never seen
 
    ButtingIn#if ($foo) {....}

The # is always preceded by white space or starts a new line.

Relaxed directive processing takes care of:

<table color=#ccddee>

Lane

Brian Goetz wrote:

>>I'm just asking for some help with the parser bug because that is a very 
>>complex area, and if it's in the parser .jj file then there's a hell of a 
>>lot of a learning curve for me to fix it. I already spent days learning 
>>about and fixing an old  PropertyOperatorCache bug.
>>    
>>
>
>OK, but like I said, I haven't touched the parser in probably a year.
>
>Also, I'm not convinced that the test case is even right!  Did it ever
>work?  When?  When did it stop?  
>
>
>
>-------------------------------------------------------
>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] 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,1.2,NONE

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

SparseProperties is a very useful property class file which is 
referenced in the macros/ tree.

It is a small class but is very useful in processing templates in which 
you do not know if a property is present or not:

Hello $Profile.Name,

would return a "" or whatever you specify as the default if  get("Name") 
returned a null.

I use it a lot in my webmacro applications.

Lane

Eric B. Ridge wrote:

> Begin forwarded message:
>
>> From: bri...@us...
>> Date: Thu Jul 17, 2003  1:34:02  AM America/New_York
>> To: web...@li...
>> Subject: [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,1.2,NONE
>>
>> Update of /cvsroot/webmacro/webmacro/src/org/webmacro/util
>> In directory sc8-pr-cvs1:/tmp/cvs-serv29972/src/org/webmacro/util
>>
>> Removed Files:
>>     IntMap.java QueueWriter.java SimpleStack.java
>>     SparseArrayIterator.java SparseProperties.java
>> Log Message:
>> Eliminate misc unused classes
>
>
> Brian, I'm not sure, but I seem to remember Lane mentioning a while 
> back something about using SparseProperties.  I don't know if he was 
> talking about this one, or something of his own, or whatever, but I'm 
> mentioning it here so Lane can chime in if he still needs this class.
>
> eric
>
>>
>> --- IntMap.java DELETED ---
>>
>> --- QueueWriter.java DELETED ---
>>
>> --- SimpleStack.java DELETED ---
>>
>> --- SparseArrayIterator.java DELETED ---
>>
>> --- SparseProperties.java DELETED ---
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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-cvs mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/webmacro-cvs
>
>
>
>
> -------------------------------------------------------
> 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] Any mileage in my "WebMacroList" idea?

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

On Fri, 18 Jul 2003 22:45:47 +0100, Marc Palmer <ma...@an...> wrote:

> On Fri, 18 Jul 2003 17:37:38 -0400, Keats <ke...@ea...> wrote:
>
>> OK, that puts a different perspective on things.
>>
>> I don't know much about BeanInfo stuff, but can't you just create a
>> ParameterDescriptor that describes the contract for the method's 
>> parameters?
>
> I do all that. However that's a bit laying saying you should make all 
> your java methods take just Object params, because the javadocs will tell 
> you what they are.

"However that's a bit LIKE saying..."

Obviously too much laughing gas today for me.

Re: [Webmacro-devel] Any mileage in my "WebMacroList" idea?

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

On Fri, 18 Jul 2003 18:05:25 -0400, Keats <ke...@ea...> wrote:

> I don't see how you get any added type checking -- a user can still put
> whatever into a method call and it won't get caught until runtime.  You 
> can improve that somewhat by using the #type directive.

What I mean is you get different categories of failure. A failure to 
resolve a method based on type is different to a classcastexception in your 
helper method.

I can't recall in WM whether both of these will result in a 
PropertyException however.

> If you are creating some kind of a wizard for generating WMScript then 
> you could have a bit of a problem I suppose.  I'd still say you're better 
> off
> using overloaded methods.  Most of the time it's just arrays and lists 
> that you care about anyway, so it's just two versions.

...and twice the docs in BeanInfo etc. even if you are ignoring 
Iterator/Enumeration, which I don't think we should.

For example, Ignition supports regular Java beans - you know those much- 
vaunted Java "components" that few people actually seem to have 
delivered/used ;-)

You can take any Java bean (not just a class that supports introspection - 
with BeanInfo etc) and use it as a helper in Ignition. This gives you 
runtime documentation for nothing - it's great. Take any off-the-shelf bean 
that isn't GUI oriented and you can use it straight away. In future we 
might even support BeanContext.

Anyway, with this in mind, we could be using anything in the template, with 
Iterators and Enumerations flying all over the place.

I don't see the point of restrictions here.

I know - the introspection code in WM is a pain. Does that mean we should 
shy away from possibly useful features?

I don't think "it's too much hassle" is a good argument against an idea.

"It's fundamentally flawed and I can prove it" is :-)

If anything, if something is too much hassle but might be nice to have we 
should put it on the "wish list" and/or find a way to do it with minimal 
work.

I'm just trying to see if we can take the language forward.

For example, the new functions stuff is really good. I never looked at it 
in detail until now, and I like it.

Stopping people worring about what kind of List they might be passed in a 
helper function -has-to be a good thing.

-- 
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] Any mileage in my "WebMacroList" idea?

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

I don't see how you get any added type checking -- a user can still put
whatever into a method call and it won't get caught until runtime.  You can
improve that somewhat by using the #type directive.

If you are creating some kind of a wizard for generating WMScript then you
could have a bit of a problem I suppose.  I'd still say you're better off
using overloaded methods.  Most of the time it's just arrays and lists that
you care about anyway, so it's just two versions.

Keats

----- Original Message -----
From: "Marc Palmer" <ma...@an...>
To: "Keats" <ke...@ea...>; <web...@li...>
Sent: Friday, July 18, 2003 5:45 PM
Subject: Re: [Webmacro-devel] Any mileage in my "WebMacroList" idea?


> On Fri, 18 Jul 2003 17:37:38 -0400, Keats <ke...@ea...> wrote:
>
> > OK, that puts a different perspective on things.
> >
> > I don't know much about BeanInfo stuff, but can't you just create a
> > ParameterDescriptor that describes the contract for the method's
> > parameters?
>
> I do all that. However that's a bit laying saying you should make all your
> java methods take just Object params, because the javadocs will tell you
> what they are.
>
> We basically get a form of type checking when executing the template if we
> make sure it matches a specific type - using Object params you always risk
> a cast exception.
>
> > A bit of a pain I know, but probably better than messing with the guts
of
> > the introspection engine.
>
> Yes, maybe, but I am pretty sure something like this idea is part of the
> JSR 168 (I think) relating to making java objects more amenable to access
> from non-Java scripting languages. At least, that's what I think they're
> doing.
>
> Of course WebMacroList as a parameter is not a great solution - because it
> means people have to specifically write their classes for WebMacro. That's
> what I think that JSR is attempting to address.
>
> It would arguably be much better to implement a lighweight List
> implementation that does what I have described, and make WebMacro attemp
to
> coerce Object[], Iterator and Enumeration to List.
>
> 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] Any mileage in my "WebMacroList" idea?

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

On Fri, 18 Jul 2003 17:37:38 -0400, Keats <ke...@ea...> wrote:

> OK, that puts a different perspective on things.
>
> I don't know much about BeanInfo stuff, but can't you just create a
> ParameterDescriptor that describes the contract for the method's 
> parameters?

I do all that. However that's a bit laying saying you should make all your 
java methods take just Object params, because the javadocs will tell you 
what they are.

We basically get a form of type checking when executing the template if we 
make sure it matches a specific type - using Object params you always risk 
a cast exception.

> A bit of a pain I know, but probably better than messing with the guts of
> the introspection engine.

Yes, maybe, but I am pretty sure something like this idea is part of the 
JSR 168 (I think) relating to making java objects more amenable to access 
from non-Java scripting languages. At least, that's what I think they're 
doing.

Of course WebMacroList as a parameter is not a great solution - because it 
means people have to specifically write their classes for WebMacro. That's 
what I think that JSR is attempting to address.

It would arguably be much better to implement a lighweight List 
implementation that does what I have described, and make WebMacro attemp to 
coerce Object[], Iterator and Enumeration to List.

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] Any mileage in my "WebMacroList" idea?

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

OK, that puts a different perspective on things.

I don't know much about BeanInfo stuff, but can't you just create a
ParameterDescriptor that describes the contract for the method's parameters?
A bit of a pain I know, but probably better than messing with the guts of
the introspection engine.

Keats

----- Original Message -----
From: "Marc Palmer" <ma...@an...>
To: "Keats" <ke...@ea...>; <web...@li...>
Sent: Friday, July 18, 2003 12:41 PM
Subject: Re: [Webmacro-devel] Any mileage in my "WebMacroList" idea?


> On Fri, 18 Jul 2003 12:27:15 -0400, Keats <ke...@ea...> wrote:
>
> >
> > ----- Original Message -----
> >> ...but that doesn't help with Iterator(s) and Enumeration(s). The only
> >> solution is really to use Object in your methods and
auto-detect/convert
> >> using the ListTool - otherwise you have to overload with 4 versions of
> > your
> >> method.
> >
> > If you want your method to support all these types of collections, then
> > using Object and the ListUtil probably makes good sense:
> >
> > public Object myMethod(Object o){
> > List list = ListUtil.toList(o);
> > // do something with list
> > ...
> >
> > Since we do argument type matching at runtime anyway, I don't see a
> > problem
> > with this.
>
> That's why we're still talking about it. Let me try to explain a little
> better. The above is perfectly OK on the surface of it, and this is what I
> do everywhere.
>
> BUT if you want to provide advanced applications and higher-level tools
for
> template writers, this is no good because if you want to show them the
> methods they can call on a helper, all you can say is:
>
>
> Help for: YourTool
>
> Methods:
>
>     myMethod - Parameters: Object
>
>
> This is not helpful at all and hides the fact that a list is required!
>
> Get it?
>
> Ignition provides excellent introspection+BeanInfo based help information
> for the objects people can access in the template. Where you read
> "Ignition" though, just think "High level tools" - I'm not just on an
> Ignition mission here. I'm trying to improve productivity and usability of
> WM templating, by advocating features that will support provision of
typing
> information to end-user tools.
>
> It would be much nicer if, as Ignition already does for parameters type
> that are identifiable as lists (array, List, Ixxx, Exxx etc), it was shown
> like this:
>
>
> Help for: YourTool
>
> Methods:
>
>     myMethod - Parameters: list
>
> This instantly tells the user more information, and also prevents runtime
> error messages if they accidentally pass the wrong object type in - which
> would not be possible if the method took WebMacroList as a parameter - WM
> would trap it as a property exception because it would not resolve to a
> method.
>
> See now?
>
>
> --
> 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 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] Any mileage in my "WebMacroList" idea?

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

On Fri, 18 Jul 2003 12:27:15 -0400, Keats <ke...@ea...> wrote:

>
> ----- Original Message -----
>> ...but that doesn't help with Iterator(s) and Enumeration(s). The only
>> solution is really to use Object in your methods and auto-detect/convert
>> using the ListTool - otherwise you have to overload with 4 versions of
> your
>> method.
>
> If you want your method to support all these types of collections, then
> using Object and the ListUtil probably makes good sense:
>
> public Object myMethod(Object o){
> List list = ListUtil.toList(o);
> // do something with list
> ...
>
> Since we do argument type matching at runtime anyway, I don't see a 
> problem
> with this.

That's why we're still talking about it. Let me try to explain a little 
better. The above is perfectly OK on the surface of it, and this is what I 
do everywhere.

BUT if you want to provide advanced applications and higher-level tools for 
template writers, this is no good because if you want to show them the 
methods they can call on a helper, all you can say is:


Help for: YourTool

Methods:

    myMethod - Parameters: Object


This is not helpful at all and hides the fact that a list is required!

Get it?

Ignition provides excellent introspection+BeanInfo based help information 
for the objects people can access in the template. Where you read 
"Ignition" though, just think "High level tools" - I'm not just on an 
Ignition mission here. I'm trying to improve productivity and usability of 
WM templating, by advocating features that will support provision of typing 
information to end-user tools.

It would be much nicer if, as Ignition already does for parameters type 
that are identifiable as lists (array, List, Ixxx, Exxx etc), it was shown 
like this:


Help for: YourTool

Methods:

    myMethod - Parameters: list

This instantly tells the user more information, and also prevents runtime 
error messages if they accidentally pass the wrong object type in - which 
would not be possible if the method took WebMacroList as a parameter - WM 
would trap it as a property exception because it would not resolve to a 
method.

See now?


-- 
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] Any mileage in my "WebMacroList" idea?

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

----- Original Message -----
> ...but that doesn't help with Iterator(s) and Enumeration(s). The only
> solution is really to use Object in your methods and auto-detect/convert
> using the ListTool - otherwise you have to overload with 4 versions of
your
> method.

If you want your method to support all these types of collections, then
using Object and the ListUtil probably makes good sense:

   public Object myMethod(Object o){
      List list = ListUtil.toList(o);
      // do something with list
     ...

Since we do argument type matching at runtime anyway, I don't see a problem
with this.

Keats

Re: [Webmacro-devel] More pruning

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

On Fri, 18 Jul 2003 12:04:01 -0400, Eric B. Ridge <eb...@tc...> wrote:

> On Friday, July 18, 2003, at 11:50  AM, Lane Sharman wrote:
>
>> I really like the interface signature Destroyable and use this pattern 
>> all the time.
>>
>> The implementation signals it needs to be destroyed and the shutdown 
>> sequence tests and invokes the method defined in the Destroyable 
>> Interface.
>
> isn't the issue here that we (read: Brian) doesn't want a "shutdown 
> sequence" other than standard java finalization?

That's what I thought too - but then Brian proposed this 
Destructor/Destroyable approach.

I think a Destroyable approach would make sense - we make the context do 
"if (tool instanceof Destroyable)" when the tool is created, and if so add 
it to a List.

Then, we still need some "context is finished with" concept and then the 
context calls all the Destroyables in the list.

I think really the "when is the context finished with" point is the 
contentious issue here.

> Although, Brian's suggestion of the .beginEval() and .endEval() does make 
> a lot of sense.

Yes. I think this is probably a good solution, but in a more generic 
terminology - .enter() .leave() might be nicer, or acquire() / release(). 
That way it looks sensible if you want to share a context between evals:


  ctx.acquire();
  try
  {
    template.write( output, ctx);
    template.write( output2, ctx);
    template.write( output3, ctx);
  }
  finally
  {
    ctx.release();
  }

This is then only a concern for people who want to share contexts like 
this. For everybody else (99% of people) the implicit acquire/release will 
be perfect.

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] Any mileage in my "WebMacroList" idea?

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

On Fri, 18 Jul 2003 11:53:15 -0400, Keats <ke...@ea...> wrote:

> I think what you are proposing is possible, but I don't think it's really
> worth the trouble.  It would be a pretty serious change with potential
> performance impact, for minimal benefit.

I think it would be very beneficial - if you think of non-java programmers 
using helpers from all different people, who use different conventions for 
list representation.

"Potential performance impact" is not definite. It could be very small in 
deed. Small or equal to forcing the helper writers to manually call into 
ListTool to convert every value.

> The introspection engine of course supports overloading methods (using
> o.w.e.IntrospectionUtils.matches() for parameter matching).  This seems 
> to
> me a more straightforward approach: just define a List and an Object[]
> version of your method.

...but that doesn't help with Iterator(s) and Enumeration(s). The only 
solution is really to use Object in your methods and auto-detect/convert 
using the ListTool - otherwise you have to overload with 4 versions of your 
method.

> One longstanding issue is that the WMScript "list" syntax uses an array,
> i.e.,
>
> ["a", "b", "c"] ==> new Object[]{ "a", "b", "c" }
>
> We've talked about wrapping this as a list, e.g.,
>
> Arrays.asList(new Object[]{"a","b","c"}
>
> which would make it easier to avoid using arrays in WMScript.  Maybe the 
> 2.0
> release would be a good time to revisit this.

As above, I don't think arrays the only problem. Arrays are nice and 
lightweight, good for performance - I don't think we should force people 
out of using them.

> Another nice-to-have would be to add a subscript notation that works for
> lists and arrays.

...which could be achieved easily in the template using the very 
WebMacroList scheme I am talking about!

i.e. if we added a subscript notation - which I personally think introduces 
a whole range of new problems to template writers - we would just need to 
make WM implicitly wrap any list type with WebMacroList and have the 
notation code interface with that single interface.

Come on, you know it makes sense!

:)

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] More pruning

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

On Friday, July 18, 2003, at 11:50  AM, Lane Sharman wrote:

> I really like the interface signature Destroyable and use this pattern 
> all the time.
>
> The implementation signals it needs to be destroyed and the shutdown 
> sequence tests and invokes the method defined in the Destroyable 
> Interface.

isn't the issue here that we (read: Brian) doesn't want a "shutdown 
sequence" other than standard java finalization?

Although, Brian's suggestion of the .beginEval() and .endEval() does 
make a lot of sense.

eric

>
> +1 for this approach which requires none of the registration junk.
>
> -Lane
>
> ke...@su... wrote:
>
> I like this callback approach -- similar to a listener, but simpler.
>
> We could probably make things even simpler by automating the 
> destructor registration.  Two approaches leap to mind, at tool load 
> time check if it implements Destroyable.  Alternatively this could be 
> based on a configuration, e.g.,
>
> ContextToolsWithDestructors: DbTool, SocketTool
>
> Keats
>
> -------Original Message-------
> From: Brian Goetz <br...@qu...>
> Sent: 07/15/03 06:59 PM
> To: ke...@su...
> Subject: Re: Re: [Webmacro-devel] More pruning
>
>
>
>
> So what's the best design for doing this sort of thing?  The listener
> approach is appealing because then only tools that need this
>
>
> functionality
>
>
> would register themselves, so very few listeners would actually be
> managed.  Plus this is analogous to the model used by HttpSessions and
> ServletContexts.
>
> Is the overhead really that great?
>
>
>
> The performance overhead is negligible.
>
> However, the issue you raise below, requiring the WM user to explicitly
> free the Context is not really negligible, as the lifecycle methods at 
> all
>
> levels bubble up to the the level of the user's consciousness.
>
> So what if we add these:
>
> class Context {
>    ...
>    public void registerDestructor(Destructor dtor) {
> destructors.add(dtor); }
>    public void destroy() { /* iterate through destructors */ }
> }
>
> which don't affect anyone who's not going to use them.  To be polite, 
> we
> can teach WMServlet about it.  And tools that hold things like 
> connections
>
> should still probably use finalizers, just in case none of the explicit
> mechanisms do their job.  That seems OK to me.
>
>
>
> I suppose an alternative is to put the onus on the Servlet developer to
> handle the cleanup if they want to use these kinds of tools.  WMServlet
> makes a call to a stub method called destroyContext() after each
> request.  A developer could use a method like this to go into the 
> context
>
>
>
>
>
> and find resources that need to be released.  This is more work for the
> developer, but since this isn't used much, it might make sense to do it
> this way.
>
>
>
>
>
> --
> Brian Goetz
> Quiotix Corporation
> br...@qu...           Tel: 650-843-1300            Fax: 
> 650-324-8032
>
> http://www.quiotix.com
>
>
>
>
> -------------------------------------------------------
> 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
>
>
>
>
> -------------------------------------------------------
> 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] More pruning

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

I really like the interface signature Destroyable and use this pattern 
all the time.

The implementation signals it needs to be destroyed and the shutdown 
sequence tests and invokes the method defined in the Destroyable Interface.

+1 for this approach which requires none of the registration junk.

-Lane

ke...@su... wrote:

>I like this callback approach -- similar to a listener, but simpler.  
>
>We could probably make things even simpler by automating the destructor registration.  Two approaches leap to mind, at tool load time check if it implements Destroyable.  Alternatively this could be based on a configuration, e.g.,
>
>ContextToolsWithDestructors: DbTool, SocketTool
>
>Keats
>
>-------Original Message-------
>From: Brian Goetz <br...@qu...>
>Sent: 07/15/03 06:59 PM
>To: ke...@su...
>Subject: Re: Re: [Webmacro-devel] More pruning
>
>  
>
>>So what's the best design for doing this sort of thing?  The listener 
>>approach is appealing because then only tools that need this
>>    
>>
>functionality 
>  
>
>>would register themselves, so very few listeners would actually be 
>>managed.  Plus this is analogous to the model used by HttpSessions and 
>>ServletContexts.
>>
>>Is the overhead really that great?
>>    
>>
>
>The performance overhead is negligible.
>
>However, the issue you raise below, requiring the WM user to explicitly 
>free the Context is not really negligible, as the lifecycle methods at all 
>
>levels bubble up to the the level of the user's consciousness.
>
>So what if we add these:
>
>class Context {
>   ...
>   public void registerDestructor(Destructor dtor) {
>destructors.add(dtor); }
>   public void destroy() { /* iterate through destructors */ }
>}
>
>which don't affect anyone who's not going to use them.  To be polite, we 
>can teach WMServlet about it.  And tools that hold things like connections 
>
>should still probably use finalizers, just in case none of the explicit 
>mechanisms do their job.  That seems OK to me.
>
>  
>
>>I suppose an alternative is to put the onus on the Servlet developer to 
>>handle the cleanup if they want to use these kinds of tools.  WMServlet 
>>makes a call to a stub method called destroyContext() after each 
>>request.  A developer could use a method like this to go into the context 
>>    
>>
>
>  
>
>>and find resources that need to be released.  This is more work for the 
>>developer, but since this isn't used much, it might make sense to do it 
>>this way.
>>    
>>
>
>
>
>--
>Brian Goetz
>Quiotix Corporation
>br...@qu...           Tel: 650-843-1300            Fax: 650-324-8032
>
>http://www.quiotix.com
>
>
>
>
>-------------------------------------------------------
>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
>  
>
>
>
>-------------------------------------------------------
>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] Any mileage in my "WebMacroList" idea?

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

I think what you are proposing is possible, but I don't think it's really
worth the trouble.  It would be a pretty serious change with potential
performance impact, for minimal benefit.

The introspection engine of course supports overloading methods (using
o.w.e.IntrospectionUtils.matches() for parameter matching).  This seems to
me a more straightforward approach: just define a List and an Object[]
version of your method.

One longstanding issue is that the WMScript "list" syntax uses an array,
i.e.,

["a", "b", "c"] ==> new Object[]{ "a", "b", "c" }

We've talked about wrapping this as a list, e.g.,

Arrays.asList(new Object[]{"a","b","c"}

which would make it easier to avoid using arrays in WMScript.  Maybe the 2.0
release would be a good time to revisit this.

Another nice-to-have would be to add a subscript notation that works for
lists and arrays.

Keats

----- Original Message -----
From: "Marc Palmer" <ma...@an...>
To: <web...@li...>
Sent: Friday, July 18, 2003 9:51 AM
Subject: [Webmacro-devel] Any mileage in my "WebMacroList" idea?


>
> I don't recall anybody providing any feedback on this.
>
> The basic idea is to solve the problem of having to accept Object
> parameters for helper methods when you want to be able to accept an
> Object[] of any type, a List, Iterator or Enumeration.
>
> Sure, we have the List function/context tool to do this (and write methods
> expecting List) but it's still more work for the template user.
>
> In Ignition I have introduced the concept of "WM Script types" which
> reduces the Java-ness of native scripting types where possible. As such,
to
> my users I say that any function that takes or returns an Object[], List,
> Iterator or Enumeration is in fact just taking/returning "a list".
>
> What I'm trying to do with Ignition is take template authoring to a higher
> level - where auto-generated documentation and useful information about
> types expected and returned is available to template writers.
>
> So, I think that WM should be able to handle this inside templates in a
> similar way - stop the writer worrying about list types and conversion,
and
> make life easier for the helper writer.
>
> My proposal is therefore:
>
> 1. That we introduce a type such as WebMacroList which is immutable
> (another benefit) and has only the following methods:
>
>    public Object get(int i);
>    public int size();
>    public int indexOf(Object o);
>    public Iterator iterator();
>    public Object[] toArray();
>    public Object[] toArray(Object[] dest);
>
> 2. We add to the introspection engine (ugh is this PropertyOperatorCache
> land?!) rules that will first look for method signatures that have
> WebMacroList in any places where Iterator, Enumeration or List occur in
the
> parameter list of the method call in the template. If a match is found,
the
> lists will be wrapped up in instances of WebMacroList and that method
> called. Otherwise, fallback to existing introspection.
>
> 3. That we recommend helper/tool writers use WebMacroList parameters
> instead of "Object" or "Object[]" or any other list-variants.
>
> This way template writers will never need to worry about lists, helper
> writers can produce clearer code instead of accepting "Object" or just
> "List", and in some cases we might even get a slight performance win by
> doing lazy conversion of Iterator/Enumeration etc. only if they are
> required.
>
> Thoughts welcome. I'm more than happy to write the WebMacroList code,
> wrappers, and update all existing tools to do this - but I'm not sure I
> have what it takes to make the changes to PropertyOperatorCache on my own.
> From a quick look at the source it appears method calls are handled using
> PropertyMethod and there doesn't appear to be support for method
> overloading which seems odd - I must be wrong. However in POC it just gets
> the method accessor by property name, so unless that includes the method
> param signature too I don't see how WM supports overloaded methods.
>
> Enlightenment anyone?
>
> --
> 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 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] ACK! Bug not a bug

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

On Fri, 18 Jul 2003 16:30:25 +0200 (MEST), Endre Stølsvik 
<web...@st...> wrote:

> Leave it!
>
> It works now!
>
> Don't fix it if it ain't broken!

Well... that's kind of the point - to WM newbies (and dunces like me) it 
doesn't make sense any more to have this restriction when relaxed directive 
processing is supported.

The disadvantage is that we'd have to enable relaxed processing by default 
(if we don't already) otherwise we would break existing WM apps.

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] ACK! Bug not a bug

[<web...@st...>]

On Thu, 17 Jul 2003, Marc Palmer wrote:

|
| OK I see from the WM site:
|
| Directives all begin with a '#' character at the beginning of a line or
| after one or more whitespace characters.
|
|
| Which is as clear as you can get. However, I have never come across this
| problem before. I tested with an old WM build and the behaviour is the
| same, so no bug here. The rules do look suspiciously like a hack to support
| colours and anchor tags to HTML bookmark links:
|
| #if (true) It works#end   ---> OK
| "#if (true) It works#end  ---> Dumps out script
| " #if (true) It works#end ---> OK
| a#if (true) It works#end  ---> Dumps out script
| '#if (true) It works#end  ---> Dumps out script
|
| I'll retract my overly hasty unit test - or rather correct it to assert
| this behaviour (see it's not all wasted!) but is this something we can re-
| examine now we have relaxed directive parsing?

Leave it!

It works now!

Don't fix it if it ain't broken!

Whatever!

Endre.

[Webmacro-devel] Any mileage in my "WebMacroList" idea?

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

I don't recall anybody providing any feedback on this.

The basic idea is to solve the problem of having to accept Object 
parameters for helper methods when you want to be able to accept an 
Object[] of any type, a List, Iterator or Enumeration.

Sure, we have the List function/context tool to do this (and write methods 
expecting List) but it's still more work for the template user.

In Ignition I have introduced the concept of "WM Script types" which 
reduces the Java-ness of native scripting types where possible. As such, to 
my users I say that any function that takes or returns an Object[], List, 
Iterator or Enumeration is in fact just taking/returning "a list".

What I'm trying to do with Ignition is take template authoring to a higher 
level - where auto-generated documentation and useful information about 
types expected and returned is available to template writers.

So, I think that WM should be able to handle this inside templates in a 
similar way - stop the writer worrying about list types and conversion, and 
make life easier for the helper writer.

My proposal is therefore:

1. That we introduce a type such as WebMacroList which is immutable 
(another benefit) and has only the following methods:

   public Object get(int i);
   public int size();
   public int indexOf(Object o);
   public Iterator iterator();
   public Object[] toArray();
   public Object[] toArray(Object[] dest);

2. We add to the introspection engine (ugh is this PropertyOperatorCache 
land?!) rules that will first look for method signatures that have 
WebMacroList in any places where Iterator, Enumeration or List occur in the 
parameter list of the method call in the template. If a match is found, the 
lists will be wrapped up in instances of WebMacroList and that method 
called. Otherwise, fallback to existing introspection.

3. That we recommend helper/tool writers use WebMacroList parameters 
instead of "Object" or "Object[]" or any other list-variants.

This way template writers will never need to worry about lists, helper 
writers can produce clearer code instead of accepting "Object" or just 
"List", and in some cases we might even get a slight performance win by 
doing lazy conversion of Iterator/Enumeration etc. only if they are 
required.

Thoughts welcome. I'm more than happy to write the WebMacroList code, 
wrappers, and update all existing tools to do this - but I'm not sure I 
have what it takes to make the changes to PropertyOperatorCache on my own. 
From a quick look at the source it appears method calls are handled using 
PropertyMethod and there doesn't appear to be support for method 
overloading which seems odd - I must be wrong. However in POC it just gets 
the method accessor by property name, so unless that includes the method 
param signature too I don't see how WM supports overloaded methods.

Enlightenment anyone?

-- 
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] ACK! Bad new parser bug

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

On Thu, 17 Jul 2003 22:10:08 +0100, Marc Palmer <ma...@an...> wrote:

> However, can any of us see how not -requiring-whitespace before a 
> directive will break anything that exists already?

I've thought of a niche possibility where this change could screw people up 
-

A output template where #if (or other directive) is part of their output, 
with unescaped \#.

I can't see this being a problem in HTML, but maybe in some other output 
formats. It seems very marginal, as you'd have to be sailing pretty close 
to the wind to do this anyway - better to escape your # anyway.


-- 
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] ACK! Bad new parser bug

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

On Thu, 17 Jul 2003 15:17:00 -0400, Eric B. Ridge <eb...@tc...> wrote:

> On Thursday, July 17, 2003, at 03:06  PM, Brian Goetz wrote:
>
>>> I think that if this is something that has always existed, we should 
>>> look
>>> at removing it for 2.0 if the parser can handle it and it doesn't break
>>> anything else.
>>
>> Hee hee hee.  Not ever touching that whitespace stuff again.  Nope,
>> never.  Set in stone.  Ask Eric why.
>
> I'll volunteer to "fix" this, if we can all agree that it'll be okay.  I 
> think Marc is right, it works this way because of "#ffee00" stuff... and 
> with Lane's "relaxed directive matching" config option, it ain't an issue 
> anymore.

Exactly. The less we have for the template writer to worry about, the less 
chance you have of a numbnuts like me declaring false bugs / assuming WM 
sucks / toiling over broken templates for ages!

-- 
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] ACK! Bad new parser bug

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

On Thu, 17 Jul 2003 13:47:13 -0700, Brian Goetz <br...@qu...> wrote:

>
>> I am sure it is a total nightmare. However this particular one can't be 
>> too hard to fix. We have lots of test cases too.
>
> Its not so much that its hard, is that everyone has templates which 
> assume certain behavior, and different constituencies have vastly 
> differing ideas of how it _should_ work.

I hear you. I remember the whitespace debacle well :)

However, can any of us see how not -requiring-whitespace before a directive 
will break anything that exists already?

I can't. If we make a change, it should only affect that one part of the 
handling.

The only thing I can see this affecting is performance perhaps. There may 
be a performance overhead in the relaxed directive trapping, which wouldn't 
currently occur as all such ambiguous cases must be prefixed with 
whitespace for them to work with existing WM versions, but even if this is 
true it must only be at template build time surely?

I think in this regard, lady luck is smiling upon us :)

By the way I've fixed a tiny snafu in HTMLEscaper (spewed when passed null 
strings) and added unit tests for HTMLEscaping.

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] ACK! Bad new parser bug

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

>I am sure it is a total nightmare. However this particular one can't be 
>too hard to fix. We have lots of test cases too.

Its not so much that its hard, is that everyone has templates which assume 
certain behavior, and different constituencies have vastly differing ideas 
of how it _should_ work.


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

http://www.quiotix.com

Re: [Webmacro-devel] ACK! Bad new parser bug

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

On Thu, 17 Jul 2003 12:06:14 -0700, Brian Goetz <br...@qu...> wrote:

>> Well, it's not very friendly to the template write is it?
>
> Perhaps, but I think we've all been put off by the crying of "BAD NEW
> PARSER BUG" when its neither new nor a bug.  It might be a nice feature
> or enhancment, but that's a different beast.

Hehe, you know me though Brian. Everything's a major problem that needs to 
be fixed "today" ;-)

>> Forget a single space and your code is exposed instead of being 
>> executed?
>
> WM, and nearly all template languages, are full of things like this.
>
>> I think that if this is something that has always existed, we should 
>> look at removing it for 2.0 if the parser can handle it and it doesn't 
>> break anything else.
>
> Hee hee hee.  Not ever touching that whitespace stuff again.  Nope,
> never.  Set in stone.  Ask Eric why.

I am sure it is a total nightmare. However this particular one can't be too 
hard to fix. We have lots of test cases too.


-- 
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] ACK! Bad new parser bug

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

On Thursday, July 17, 2003, at 03:06  PM, Brian Goetz wrote:

>> I think that if this is something that has always existed, we should 
>> look
>> at removing it for 2.0 if the parser can handle it and it doesn't 
>> break
>> anything else.
>
> Hee hee hee.  Not ever touching that whitespace stuff again.  Nope,
> never.  Set in stone.  Ask Eric why.

I'll volunteer to "fix" this, if we can all agree that it'll be okay.  
I think Marc is right, it works this way because of "#ffee00" stuff... 
and with Lane's "relaxed directive matching" config option, it ain't an 
issue anymore.

eric

Re: [Webmacro-devel] ACK! Bad new parser bug

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

> > why not?  just put a space before the #macroName.  The space will be 
> > eaten by WM.
> 
> Well, it's not very friendly to the template write is it?

Perhaps, but I think we've all been put off by the crying of "BAD NEW
PARSER BUG" when its neither new nor a bug.  It might be a nice feature
or enhancment, but that's a different beast.  

> Forget a single space and your code is exposed instead of being executed?

WM, and nearly all template languages, are full of things like this.

> I think that if this is something that has always existed, we should look 
> at removing it for 2.0 if the parser can handle it and it doesn't break 
> anything else.

Hee hee hee.  Not ever touching that whitespace stuff again.  Nope,
never.  Set in stone.  Ask Eric why.

Re: [Webmacro-devel] Use Case for destroyContext

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

> Firstly, there's the GC - why can't those objects be collected by it?

Objects like Database connections are very expensive -- most databases
limit connections and the cost of getting more is very high.
Finalization can take a long, long time to get triggered, and might
not ever get triggered. 

> Then one could get the Connection and close it on every method call,
> instead of at the tool creation and closing it at the tool destruction.

Right.  With a connection pool, you could acquire and release the
connection every time a tool is accessed.