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

Re: [Webmacro-devel] Yep, #macro/parser BUG. **Proof**

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

On Fri, 18 Apr 2003 18:19:21 -0700, Brian Goetz <br...@qu...> wrote:

>
>> #macro visitChildren( $node)
>>
>> #foreach $n in $node.Children
>> $n.Text<br>                     #visitChildren( $n)
>> #end

There is one flaw in this, which is probably a side-isse. If $node.Children 
is null, the code would die, but in the test case this is not true.

Just for the record.

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

Re: [Webmacro-devel] Yep, #macro/parser BUG. **Proof**

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

On Fri, 18 Apr 2003 18:19:21 -0700, Brian Goetz <br...@qu...> wrote:

> Of course this causes a stack overflow.  You have written a recursive 
> macro with no base case.  It is equivalent to:
>
> public int screwMe(int n) {
> return screwMe(n-1);
> }

No, it's like:

public int screwMe(int n) {
    if (n > 0)
	    return screwMe(n-1);
    else
	    return 0;
}

> Do the same with your macro.  There must be some way #visitChildren can 
> expand to something that doesn't involve calling #visitChildren....

... not having any children?

Cheers

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

Re: [Webmacro-devel] Yep, #macro/parser BUG. **Proof**

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

On Fri, 18 Apr 2003 22:09:17 -0400, Eric B. Ridge <eb...@tc...> wrote:

> On Friday, April 18, 2003, at 09:19  PM, Brian Goetz wrote:
>
>> Do the same with your macro.  There must be some way #visitChildren can 
>> expand to something that doesn't involve calling > #visitChildren....
>
> Did I miss something obvious or wouldn't that case be when $n has no 
> children?

Yes, exactly. I don't think I'm being stupid. This is standard node-tree 
traversal logic. No children, no further recursion.

It's a bug I tell you!



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

Re: [Webmacro-devel] Yep, #macro/parser BUG. **Proof**

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

On Friday, April 18, 2003, at 09:19  PM, Brian Goetz wrote:

> Do the same with your macro.  There must be some way #visitChildren 
> can expand to something that doesn't involve calling > #visitChildren....

Did I miss something obvious or wouldn't that case be when $n has no 
children?

eric

>
>
> --
> 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:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

Re: [Webmacro-devel] Yep, #macro/parser BUG. **Proof**

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

>## ********************************************************
>## Here is the code
>## ********************************************************
>
>#macro visitChildren( $node)
>
>  #foreach $n in $node.Children
>         $n.Text<br>                     #visitChildren( $n)
>  #end
>
>#end

And, even if this doesn't work at all, does not having recursive macros 
mean #macro is broken?



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

http://www.quiotix.com

[Webmacro-devel] Tag Markers?

[Kelvin W. <ke...@lu...>]

Hi All,

I know it goes against some of the principles WebMacros was designed =
for,  but what do you think about adding parsing for a very basic set of =
begin/end tags maybe <% and %>... this is really pandering to designers, =
but it means the pages can still look "pretty" in Dreamweaver.

Re: [Webmacro-devel] Yep, #macro/parser BUG. **Proof**

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

>#macro visitChildren( $node)
>
>  #foreach $n in $node.Children
>         $n.Text<br>                     #visitChildren( $n)
>  #end
>
>#end
>
>## ********************************************************
>## Call the code
>## ********************************************************
>
>#visitChildren( $rootNode)

Of course this causes a stack overflow.  You have written a recursive macro 
with no base case.  It is equivalent to:

public int screwMe(int n) {
   return screwMe(n-1);
}

In order to make recursive functions stop, you must reach a base case:

public int factorial(n) {
   if (n < 0)
     throw new ArithmeticException("negative factorial");
   else if (n == 0 || n == 1)
     return 1;
   else
     return n * factorial(n-1);
}

Do the same with your macro.  There must be some way #visitChildren can 
expand to something that doesn't involve calling #visitChildren....


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

http://www.quiotix.com

[Webmacro-devel] #bean in WM defaults

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

Hey I don't recall the decision to put #bean in the default list of 
directives in 1.1, but it's there :(

Either way, the Wiki docs need updating to reflect this, as BeanDirective 
is still listed as optional on the AllDirectives page.


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

[Webmacro-devel] Yep, #macro/parser BUG. **Proof**

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

Hi all - hope you are having a nice Easter holiday, it sure is quiet around 
here :)

I modelled my #macro stack overflow problem using purely #bean and #macro. 
StackOverflowError is the result, in build phase I think, rather than 
evaluation. This completely eliminates my XML helper class. The problem is 
WM or me misunderstanding the capabilities of #macro.

I think this warrants pretty quick examination - I am certainly screwed 
without a fix for this and I would be really grateful if someone who 
actually understands the parse/build mechanisms can look at this. I sure as 
hell don't :(

Here is the complete template, using simple recursion. :


## ********************************************************
## This is all just to set up a trivial tree structure ## 
********************************************************

#bean $rootNode = "java.util.Hashtable"
#set $rootNode.Text="root"

#bean $wmdocNode = "java.util.Hashtable"
#set $wmdocNode.Text="wmdoc"

#bean $titleNode1 = "java.util.Hashtable"
#set $titleNode1.Text="title1"

#bean $paraNode1 = "java.util.Hashtable"
#set $paraNode1.Text="para1"

	#bean $titleNode2 = "java.util.Hashtable"
	#set $titleNode2.Text="title2"
	#bean $paraNode2 = "java.util.Hashtable"
	#set $paraNode2.Text="para2"

#bean $paraNode3 = "java.util.Hashtable"
#set $paraNode3.Text="para3"

#set $rootNode.Children = [ $wmdocNode]
#set $paraNode1.Children = [$titleNode2, $paraNode2]
#set $wmdocNode.Children = [$titleNode1, $paraNode1, $paraNode3]

## ********************************************************
## Here is the code
## ********************************************************

#macro visitChildren( $node)

  #foreach $n in $node.Children
	$n.Text<br>     	    	#visitChildren( $n)
  #end

#end

## ********************************************************
## Call the code
## ********************************************************

#visitChildren( $rootNode)





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

[Webmacro-devel] FAO Brian/Lane: #macro/parser bugs I think

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

Hi,

There's some kind of weird problem going on with #macro and recursion I 
think. I'm trying to traverse a tiny XML node tree and getting stack 
overflows.

Trouble is I can't reproduce this with a simpler template. I'm 99% sure it 
is a bug because:

   If I leave a call to the macro in the template, it spews, even if 
variables required to execute the macro are not defined, implying that the 
overflow is occurring during the macro build process, which rules out my 
XML and templat code I think because it shouldn't be possible for me to 
cause the overflow given that the values I am passing to the macro (XML 
nodes) do not exist yet (i.e. you remove the #set required to get the node 
tree).

Here's the template - the macro that "causes" the problem is likely the top 
one, and the code that calls it is at the end - inline comments there to 
explain what I mean. FWIW you will also see that I have some "redundant" 
#else clauses in my #if statements. Those are required if the template is 
to get as far as the overflow. Remove them and it pukes expecting more 
"#end"s. This is bizarre, as i can't isolate this in small #macro templates 
either. Maybe I'm being a dunce, but something seems very screwy here. 
Simple templates demonstrate that macro recursion per se is not broken, but 
it is hard to test without a big #bean template (and enabling #bean) which 
I haven't yet had time to do. Only just worked out that this isn't my 
problem, AFAICS.


#include "includes/header.wmt"

#set $headingDepth = 1

#macro renderChildren( $baseNode)
     #foreach $node in $baseNode.Children

          Node: $node.Name

          #if ($node.IsElement)
               #if ($node.Name == "title")
                    #renderTitle($node)
               #elseif ($node.Name == "para")
                    #renderPara($node)
               #elseif ($node.Name == "code")
                    #renderCode($node)
               #elseif ($node.Name == "bulletlist")
                    #renderBulletList($node)
               #elseif ($node.Name == "listitem")
                    #renderListItem($node)
               #elseif ($node.Name == "directive")
                    #renderDirective($node)
               #else
               #end

          #elseif ($node.IsText || $node.IsCDATA)
               $node.Value
          #else
          #end

     #end
#end

#macro renderTitle($node)
     <h$headingDepth class="wmdoc_directive">
          #renderChildren($node)
     </h$headingDepth>
#end

#macro renderPara($node)
     <p class="wmdoc_directive">
          #set $headingDepth = $headingDepth + 1
          #renderChildren($node)
          #set $headingDepth = $headingDepth - 1
     </p>
#end

#macro renderCode($node)
     <code class="wmdoc_directive">
          #renderChildren($node)
     </code>
#end

#macro renderBulletList($node)
     <ul class="wmdoc_directive">
          #renderChildren($node)
     </ul>
#end

#macro renderListItem($node)
     <item class="wmdoc_directive">
          #renderChildren($node)
     </item>
#end

#macro renderDirective($node)
     <span class="wmdoc_directive">
          #renderChildren($node)
     </span>
#end

<h1>WebMacro Ignition Documentation</h1>

#set $docName = $Form.DocName

#set $xmlDocURL = "$(Ignition.ServerURL)$(Ignition.DocumentBaseURI) 
/docs/data/$(docName)"
#set $xmlDoc = $xml.open($xmlDocURL)
#set $xmlDoc.Complex = true

#comment  !!!!!!!!!! Look this is commented out, so the node var DOES NOT 
EXIST BUT... the template still gets a stack overflow if the 
#renderChildren call
   is left in
   #set $wmdocNode = $xmlDoc.getFirstChild("wmdoc")

#end

#comment
   The next line calls the recursive macro. Remove/comment it and the page 
"works"
   but leave it in, even with the previous #set commented out, and you get 
the overflow.
#end

#renderChildren( $wmdocNode)

#include "includes/footer.wmt"



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

Re: [Webmacro-devel] Hold off on the SF bug tracker!

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

On Monday, April 14, 2003, at 10:30  AM, Marc Palmer wrote:

> How about we run this instead of relying on SF's lame offering... with 
> the bonus that we can run it at webmacro.org :)

That's no bonus for me...

eric

[Webmacro-devel] Hold off on the SF bug tracker!

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

Guys, kick-ass bug tracking software alert - FREE to open source projects:

Demo is at:

http://jira.atlassian.com/secure/Dashboard.jspa

Info/download site is at:

http://www.atlassian.com/software/jira/

How about we run this instead of relying on SF's lame offering... with the 
bonus that we can run it at webmacro.org :)



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

[Webmacro-devel] Find out which ContextTools exist?

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

...is there any way at runtime to find out which ContextTools are defines 
for a WM instance, without looking at the settings properties file? i.e. 
some kind of Broker.get("contextTools") thing?

I should make it so my webapp's help pages can show help for the context 
tools that are provided.

I think it would be nicer to ask WM for this info instead of looking at the 
properties file in case we have a full settings abstraction in future and 
they are no longer in a properties file :-)

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

[Webmacro-devel] Re: [WebMacro-user] NextRelease

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

On Thu, 10 Apr 2003 08:52:01 -0700, Lane Sharman <la...@op...> 
wrote:

> Following on the recent thread.
>
> http://www.webmacro.org/NextRelease is where you should dump stuff that 
> you think ought to be a relatively agreed to idea. If it is voted off, 
> here is where to make it known that you want it off.

Great stuff Lane.

> Plugin Friendly
> With the above in mind, I propose making WM plugin-friendly so the likes 
> of Marc can see how their distros and frameworks get produced and what 
> standard exists to be a rightful "WM Plugin".

I'm not entirely sure what you're getting at here, but it sounds good.

Something I am coming across now is that there is overlap in terms of 
"helper classes" between my forthcoming general-use WM webapp and general 
WM usage.

As such, I think we should look at a way of presenting the "optional 
helpers" for WM as a separate source tree (org.webmacro.helpers.xxxx) 
containing "approved" general purpose helpers. The "unapproved" stuff would 
still stay in /contrib

This would be a bit like ANT's core tasks and optional tasks. I think you 
should be able to download a WM binary that will run as is with minimum 
frills (just the core directives) and if you also download 
WebMacroPlusPack.jar or similar, and put it on your classpath, you will get 
all the great extra directives and helper classes people have written.

The key thing is that as many of these "helpers" should work as both 
ContextTools -or-normal classes just placed into the context by an 
application.

For example, the optional add-on jar might include:

* A Date helper class(should work as either) you can put use to create and 
manipulate dates. I have some starter code for this.

* A filesystem helper class - for traversing a local filesystem (again I 
have starter code for this)

* A simplified XML traversal helper. We have code for this too we can 
contribute.

...and any other useful self-contained helper classes and general purpose 
(i.e. not "niche") directives.

This jar would work well with my webapp design you see - you could leverage 
the same tools from standard WM in this app. Right now I'm adding helpers 
to this webapp's source tree that really should be somewhere else for 
everybody to use in WM apps.

> Storage
> I think we need storage directives that implementors can implent to 
> load/save objects into a context from a store and back.
>
> The last one will raise a lot of hackles. Tough. I need it and I know 
> there are some others who need it in the context of general WM 
> processing.

Hehe :-)

I don't understand why you want this as a directive. Why not just do it as 
a context tool / helper? Why do you need to do it as a directive? There's 
minor syntactic sugar agreed, but is it worth "restricting" the code to 
usage as a directive?

As long as it's not a core directive, I won't complain :-)

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

[Webmacro-devel] #macro/parser bug

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

Erm, if create a macro with a name beginning with "end" (and presumably 
with any existing directive name) the parser just dumps out the text of the 
macro call line, instead of executing the macro.

i.e.

#startSection( "Section 1")
#endSection

Where both are defined as macros in the same file... the output contains 
the expanded startSection macro but then has #endSection in the output, 
instead of calling that macro.

Either this is a bug or a limitation of the parser (would seem odd). Either 
way if there is no good workaround we should make #macro spew if you define 
a macro that uses a name like this which will cause problems.

$0.02

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

Re: [Webmacro-devel] SF Tracker, shall we use it?

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

On Tuesday, April 8, 2003, at 12:17  PM, Marc Palmer wrote:
> The subject says it all...

I suppose we should.  We've got Bugzilla too, but it's broken and 
way-the-hell out of date.  I wouldn't mind turning Bugzilla off...  
Anyone else have an opinion?

eric

> I'm discovering the odd bug or two and we need to keep on top of them 
> so that we can all chip in and fix them, and assign them to the right 
> people. A list of who is the current "brains" behind different areas 
> of WM would be useful too...
>
> Sorry, don't mean to suddenly step in and ordering people about - just 
> want to see WM moving forward, cleaning up, and getting more popular > :)
>
> Best wishes,
> Marc
> -- 
> Marc Palmer (Wangjammer5)
> http://www.wangjammers.org
> Java Consultants
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb: Dedicated Hosting for 
> just $79/mo with 500 GB of bandwidth! No other company gives more 
> support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Webmacro-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webmacro-devel

[Webmacro-devel] SF Tracker, shall we use it?

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

The subject says it all... I'm discovering the odd bug or two and we need 
to keep on top of them so that we can all chip in and fix them, and assign 
them to the right people. A list of who is the current "brains" behind 
different areas of WM would be useful too...

Sorry, don't mean to suddenly step in and ordering people about - just want 
to see WM moving forward, cleaning up, and getting more popular :)

Best wishes,
Marc
-- 
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants

[Webmacro-devel] (off-topic) Good EJB critique

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

For those of us who know in our hearts why EJB is a pile of $%!@ but 
couldn't be bothered to waste 4 years working precisely all its failings, I 
found this last night:

http://www.softwarereality.com/programming/ejb/index.jsp

It's a year old but I bet most if not all of it still holds. The first 
thing we experienced in real-life when playing with EJB was vendor-lock in. 
That alone is enough to forget it.


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

Re: [Webmacro-devel] Req: some housekeeping changes...?

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

>Well large-scale refactoring of all that is very simple using IDEA...

It sure is!

>so if we can come up with a policy for WM 1.2 (or WM 2 more likely) and be 
>sure about any repercussions / breaking other peoples' code, then we 
>should go and do it all. No reason to keep everything dusty. The more 
>organised and sensible things are, the more maintainable and the more 
>professional WM is :)

I agree.  There are a whole lot of classes which should not appear in the 
external API anyway -- so such reorg should be quite practical and not 
break things, for the most part.


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

http://www.quiotix.com

Re: [Webmacro-devel] Req: some housekeeping changes...?

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

On Mon, 07 Apr 2003 17:35:33 -0700, Brian Goetz <br...@qu...> wrote:

>
>> WebMacro.defaults has:
>>
>> ContextTools.Math: org.webmacro.servlet.MathTool
>> ContextTools.Text: org.webmacro.servlet.TextTool
>> ContextTools.Type: org.webmacro.servlet.TypeTool
>> ContextTools.Variable: org.webmacro.servlet.VariableTool
>> ContextTools.List: org.webmacro.servlet.ListTool
>>
>>
>> Shouldn't all those be in a different package? They are nothing to do 
>> with servlets... org.webmacro.contexttools perhaps?
>
> That makes sense to me.
>
> In fact, the whole package organization is a mess.

Well large-scale refactoring of all that is very simple using IDEA... so if 
we can come up with a policy for WM 1.2 (or WM 2 more likely) and be sure 
about any repercussions / breaking other peoples' code, then we should go 
and do it all. No reason to keep everything dusty. The more organised and 
sensible things are, the more maintainable and the more professional WM is 
:)

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

Re: [Webmacro-devel] Req: some housekeeping changes...?

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

>WebMacro.defaults has:
>
>ContextTools.Math: org.webmacro.servlet.MathTool
>ContextTools.Text: org.webmacro.servlet.TextTool
>ContextTools.Type: org.webmacro.servlet.TypeTool
>ContextTools.Variable: org.webmacro.servlet.VariableTool
>ContextTools.List: org.webmacro.servlet.ListTool
>
>
>Shouldn't all those be in a different package? They are nothing to do with 
>servlets... org.webmacro.contexttools perhaps?

That makes sense to me.

In fact, the whole package organization is a mess.


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

http://www.quiotix.com

[Webmacro-devel] Req: some housekeeping changes...?

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

Guys, maybe this has come up before and it's been thrown out because of 
backward compatibility issues...

WebMacro.defaults has:

ContextTools.Math: org.webmacro.servlet.MathTool
ContextTools.Text: org.webmacro.servlet.TextTool
ContextTools.Type: org.webmacro.servlet.TypeTool
ContextTools.Variable: org.webmacro.servlet.VariableTool
ContextTools.List: org.webmacro.servlet.ListTool


Shouldn't all those be in a different package? They are nothing to do with 
servlets... org.webmacro.contexttools perhaps? Most people have these only 
in WebMacro.defaults so I can't see that moving them to tidy things up will 
cause many problems. I tried to find ListTool a minute ago and it was 
nowhere I expected it to be...

Comments?

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

[Webmacro-devel] Obscure #if bug

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

Hi guys,

I've found a bug in the latest source. Not sure if it is a regression. Also 
not yet sure if it is #if or #macro that is the "problem", or perhaps even 
the parser.

The full template file is shown at the end, but the basic problem is:

#macro showRSS($url, $channelTemplate, $itemTemplate)
     #if ( condition1 )
          #foreach ....
             ...
          #end
          #if ( condition2 )
             OK it works!
          #end
     #else
        Bla bla bla
     #end
#end

...The code of the above form does not render in WM 1.1 - it fails thinking 
there should be another "#end", even though they are perfectly balanced. A 
clue to the problem can be found, by a lucky hunch I had, if you change the 
#if (condition2) block to have a #else part:

#macro showRSS($url, $channelTemplate, $itemTemplate)
     #if ( condition1 )
          #foreach ....
             ...
          #end
          #if ( condition2 )
             OK it works!
          #else
             Don't actually need anything here, just the "else" clause
          #end
     #else
        Bla bla bla
     #end
#end

The above will render fine. So, it looks like some weird confusion with 
nested #if and #else handling, maybe related to being within a #macro? 
Anyway, I'm sure there's an expert out there who can work this out. True a 
more refined test template would help but I have so little time at the 
moment between baby and family duties... I wanna get the webapp done. :(

Thanks in advance... full template follows. No it won't work without the 
XML helper we have written...

#macro doItem( $item, $itemTemplate)
        #set $rssItemTitle = $item.getChildByName("title")
        #if ($rssItemTitle != null)
          #set $rssItemTitle = $rssItemTitle.Text
        #end
        #set $rssItemDescription = $item.getChildByName("description")
        #if ($rssItemDescription != null)
          #set $rssItemDescription = $rssItemDescription.Text
        #end
        #set $rssItemLink = $item.getChildByName("link")
        #if ($rssItemLink!= null)
          #set $rssItemLink = $rssItemLink.Text
        #end
        #include as template "$itemTemplate"
#end

#macro doChannel( $channel, $channelTemplate)
   #set $rssChannelTitle = $channel.getChildByName("title")
   #if ($rssChannelTitle != null)
     #set $rssChannelTitle = $rssChannelTitle.Text
   #end
   #set $rssChannelLink = $channel.getChildByName("link")
   #if ($rssChannelLink != null)
     #set $rssChannelLink = $rssChannelLink.Text
   #end
   #set $rssChannelDesc = $channel.getChildByName("description")
   #if ($rssChannelDesc != null)
     #set $rssChannelDesc = $rssChannelDesc.Text
   #end
   #set $rssChannelDate = $channel.getChildByName("lastBuildDate")
   #if ($rssChannelDate != null)
     #set $rssChannelDate = $rssChannelDate.Text
   #end
   #set $rssChannelImage = $channel.getChildByName("image")
   #if ($rssChannelImage != null)
     #set $rssChannelImage = $rssChannelImage.getChildByName("url")
     #if ($rssChannelImage != null)
       #set $rssChannelImage = $rssChannelImage.Text
     #else
       #set $rssChannelImage = null
     #end
   #end
   #include as template "$channelTemplate"
#end

#macro showRSS($url, $channelTemplate, $itemTemplate)

     #set $doc = $xml.newDoc()
     #set $rootNode = $doc.open( $url)

     #if ($doc.DocType == "rss")

          Root node: $rootNode.Name<br>
          #set $rssNodes = $rootNode.getChildrenByName("rss")

          #set $rssCount = 0
          #foreach $rssNode in $rssNodes

               #set $rssCount = $rssCount + 1

               RSS node: $rssNode.Name<br>
               node is doctype: $rssNode.IsDocumentType<br>
               #foreach $attrName in $rssNode.AttributeNames
                 ...$attrName<br>
               #end

               #set $rssVer = $rssNode.getAttribute("version")

               #if ($rssVer != "0.91")
                 <b>RSS Version is not 0.91 - sorry can't show it!</b>
               #else

                    #set $channelNodes = 
$rssNode.getChildrenByName("channel")
                    #foreach $channel in $channelNodes

                       #if ($channelTemplate != null)
                            #doChannel($channel, $channelTemplate)
                       #end

                       #if ($itemTemplate != null)
                            #set $items = 
$channel.getChildrenByName("item")
			    #foreach $item in $items
                        	 #doItem($item, $itemTemplate)
		            #end
                       #end

                    #end
               #end
          #end


          #if ($rssCount == 0)
             bla bla bla
          #else
          #end

     #else
        <b>URL does not reference a valid RSS 0.91 document, doctype is not 
rss.</b>
     #end

#end

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

[Webmacro-devel] #macro... "return" or "break" ?

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

Hi all,

Do we have a "return" or "break" mechanism for #macro? If not, it would be 
very useful because it gets very ugly if you have to test for conditions 
that prevent the macro from working... you can get huge blocks around code 
and it gets hard to read and maintain.

Would this be difficult to do? I'm guessing that it might be quite tricky, 
as the "#break" or similar would only be legal in #macro (and maybe 
#foreach) and may require explicit knowledge of those directives unless we 
add a mechanism for directives to be told to "stop executing".

Thanks,
Marc

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

[Webmacro-devel] Slightly off topic: Good XPath impl anyone?

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

Hi all,

Does anyone know of a good (i.e. simple and small) XPath implementation 
that can work with regular W3C DOM nodes?

I would like to add at least something like XPath to our XML helper for WM 
templates, to make node selection a bit less boring in WM script. XSLT 
processors have
XPath implemented but we only want the XPath bit... and effectively we just 
want:

  public NodeList evaluateXPathExpression( Node context, String expression)

...so that in WMscript we can do things like:

#set $channels = $XMLHelper.find( "rss/channel")

Otherwise we currently have to find the "rss" nodes, then find the 
"channel" nodes under that etc. - boring and very longwinded if you are 
looking for something more than one or two levels deep.

I notice the XPath part of Apache Xalan-Java is available... but it looks a 
bit more complicated than what we need/want. I don't want to have to 
implement 10 interfaces just to get this working if I can avoid it.

TIA
-- 
Marc Palmer