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

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

On Sun, 20 Apr 2003 12:11:28 -0700, Brian Goetz <br...@qu...> wrote:

>> Recursion-aware template inlining (AKA #include as template where
>> script comes from an inline block) still looks like the most
>> attractive option to me.
>
> As far as I know, you're the first person to try and apply WM to this
> problem.  Not that its not a good idea -- but just don't be surprised
> that WM wasn't built to do that (yet).

Hehe, I'm not. If you look back through the pre-SF list archives you'll see 
me proferring the idea of an XML helper at least a year, maybe two years 
ago. Nobody bit on the idea then, no doubt because they hate XML or they 
could foresee the problems of navigating the tree effectively in WMScript.

> I think that dealing with tree structured data is just outside the
> limits of the current WM model, which is why its giving you so much
> grief.  You found a few back-door ways of dealing with the problem,
> but none that were designed for it.

Yep.

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

...or repeat the child loop in every #macro. That should probably work too 
:-)

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.

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.

> If the community thinks this is a good idea, we can explore it.  But
> my gut feeling is that these "steps forward" have a significant risk
> of introducing more problems than they solve.  I don't want to
> reinvent XSL with WM syntax.

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

I think the bottom line is, you can do this with other page building 
technologies out there, so WM will be incomplete without a reasonable 
solution for this.

The problem is that XSL is revolting. We do not need XSL to use XML as the 
data model for WM template output. XSL is extremely complicated, 
unintuitive, and slow. The idea of doing a "#include as text" that refers 
to a URL that will XSL process my XML source (i.e. Cocoon) and return it 
inline is really quite horrible (not even thinking about caching issues!).

Real people will want to do this real-life task, and increasingly so.

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.

I really can't see the problem.

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

>> You're probably right there. However I think to many people recursion is 
>> natural. If you don't really understand what it means to recurse, you 
>> don't see why there could be problems doing it, and it seems rather 
>> simple :)
>
> I think you must spend too much time with programmers.  Recursion
> confuses just about everyone the first ten times they see it.  Its
> just that programmers had that beaten out of them when then were much
> younger.

Hehe... I'm not so sure. Even HTML is, in a way, recursive. People are used 
to the idea of tree structures and hierarchies - HTML has this, so do 
directories. The notion of calling a single piece of code to "render" a 
node in a tree is not so off the wall.

I think it's time we found the right "tree" solution for WM.

I also think it's going to be hard work :)

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.

It's not fun.

A generic XML helper and simple tree traversal in WM is the way forward. It 
doesn't take long to work that out! Especially as the tree traversal -is- 
display logic, not processing.

Take care!
-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants