Re: [Webmacro-devel] Revised #macro stack overflow test code

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

> For what it's worth, relatively simple cases (with shallow depth and simple 
> structure) can be implemented using #macro and without recursion (#foreach 
> on all the child nodes you are interested in, and examine each only for the 
> 1 or 2 deep children you are interested in).

And these are probably the cases we care about anyway, aren't they?  

> However the simplest way to deal with these things is usually to have a 
> single loop "macro" and a long #if list checking tag type and 
> calling/including the bit of WMScript to render a node of that tag type.

And the long #if _can_ be a macro since it doesn't call back to the looper.

> I have used the "hard coded" method so far with my RSS display code for WM, 
> but I am using the recursion method on the wmwebapp docs because it is a 
> less rigid structure, were <code> can appear inside a <para> or a <title> 
> for example.

How about an XPath tool?  I suspect that would go a long way towards
making the sorts of problems you want to solve more tractable without
building DOM support into the template language.

> By community do you mean webmacro-devel or webmacro-users?

Either!  But since this conversation is on -devel, that's the one that
has a bigger chance of responding.

> Have you looked at Google's web services, or Amazon's web services? I will 
> be building demo templates that retrieve XML information about a product 
> search on Amazon and dump out the product image thumbnails, prices, 
> descriptions etc. - this is KILLER stuff, and WM needs to be there doing 
> it.

Yes, I've even written an article about it.  Very slick.  Took me less
than an hour to build an Amazon search web-app with Glue+IDEA+WM.
Since it came back as Java objects, no need to even touch the XML.
Glue rocks.

> Remember, the solution can be as simple as supporting an inline template 
> directive - and whether "crazies" like me use it for the "right" reasons or 
> not is not really an issue. 

The issue is when some "crazy" uses it for the "wrong" reason and then
posts to the list something like "#include is broken -- proof!" :)

> Inline template sections would be very useful 
> for many things I think, although I agree it does move one step closer to 
> WMScript becoming a little more like a "functional" language.

The only reason inline templates never made it was that we didn't have
a syntax for the substitution.  If we had inline templates without
context substitution, it would take no more than five minutes for
peopel to say "How about some way of calling this template with this
parameter list..."

Now that the parser has been upgraded to do argument lists, this would
be pretty simple to write:

  #template t(arg-list) { block }
  #expand t(arg-list)

Hnm, that was what you were asking for, right?  

> Thanks for your discussion on this so far Brian. Have you dealt with
> any XML / tree-based data in apps using WM yet? If so, what were
> your solutions? If not... then perhaps you should try it. Get
> yourself a free developer token from Amazon and start writing code
> that puts this data into a WM template.

This is a great example.  I used the Glue wsdl2java tool (which is
nicely integrated with IDEA), and it generated Java classes for all
the types used in the WSDL.  They are bean types, so you can justput
an array of them right in your context, done!  Look Ma, no XML!

Working Amazon WS example:

        KeywordRequest request = new KeywordRequest();
        request.keyword = httpServletRequest.getParameter("query_string");
        request.devtag = MY_AMAZON_TOKEN;
        request.type = "heavy";
        request.page = "1";
        request.mode = "books";
        ProductInfo pi = amazon.KeywordSearchRequest(request);
        context.put("search_results", pi.Details);

where Details is an array of ProductInfo objects, which are generated
by GLUE directly from the WSDL.