Menu
▾
▴
webmacro-devel — Discuss development issues related to the core of WebMacro
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(28) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(103) |
Feb
(44) |
Mar
(65) |
Apr
(140) |
May
(72) |
Jun
(233) |
Jul
(466) |
Aug
(51) |
Sep
(2) |
Oct
(17) |
Nov
(1) |
Dec
(7) |
| 2004 |
Jan
(8) |
Feb
(5) |
Mar
(28) |
Apr
(9) |
May
(7) |
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
(3) |
May
(24) |
Jun
(7) |
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(12) |
| 2006 |
Jan
|
Feb
(3) |
Mar
(8) |
Apr
(59) |
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(3) |
| 2008 |
Jan
|
Feb
(1) |
Mar
(16) |
Apr
(2) |
May
(2) |
Jun
|
Jul
(11) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(44) |
Dec
(34) |
| 2009 |
Jan
(12) |
Feb
(14) |
Mar
(11) |
Apr
(16) |
May
(41) |
Jun
(19) |
Jul
(33) |
Aug
(8) |
Sep
(3) |
Oct
|
Nov
|
Dec
(7) |
| 2010 |
Jan
(8) |
Feb
(50) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(16) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Marc P. <ma...@an...> - 2003-04-23 22:04:43
|
Well I did it using #include and #macro, and I'm quite happy with the
results - although the #include is just a hack until we have a nice inline
template snippet definition + eval (a directive form of Keats' tool).
Here's the rather simple template... just #set $currentNode = $yourRootNode
and include the template once...
#macro renderChildren( $node)
#set $currentNode = $node
## Ho ho ho template recursion - this includes THIS template ## that
we are currently in
#include as template "includes/renderchildren.wmt"
#end
#macro renderTitle($node)
<h$headingDepth class="wmdoc_title">#renderChildren($node)
</h$headingDepth>
#end
#macro renderPara($node)
<p class="wmdoc_para">#renderChildren( $node)</p>
#end
#macro renderCode($node)
<code class="wmdoc_code">#renderChildren( $node)</code>
#end
#macro renderBulletList($node)
<ul class="wmdoc_bulletlist">
#renderChildren( $node)
</ul>
#end
#macro renderListItem($node)
<li class="wmdoc_listitem">
#renderChildren( $node)
</li>
#end
#macro renderDirective($node)
<span class="wmdoc_directive">
#renderChildren( $node)
</span>
#end
#macro renderSection($node)
<div class="wmdoc_section">
#renderChildren( $node)
</div>
#end
## Ho ho ho this bit is recursively called by recursive includes
#foreach $node in $currentNode.Children
#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)
#elseif ($node.Name == "section")
#renderSection($node)
#end
#end
#elseif ($node.IsText || $node.IsCDATA) $node
#end
#end
Which works perfectly well with XML like this:
<wmdoc>
<title>An Overview of Programming with Ignition</title>
<para>Ignition provides bla bla bla...</para>
<section>
<title>The Core Concepts</title>
<section>
<title>Blackboards</title>
<para>
A blackboard allows objects to be "advertised" for
other
components of the application to access. There are two
kinds of blackboard in Ignition - a global blackboard
and a
session blackboard.
</para>
<para>A global blackboard contains items that are accessible
to
all plugins in a module, no matter what their session is.
This is a
way to advertise "singleton" style services that are not
session
specific, for example the service for sending an email
supplied by
the SendEmailAction.</para>
<para>A session blackboard contains items that are specific
to a
client session in the module. Such items might include a
user-specific
database connection, or a shopping cart service to be
accessed by
several different actions.</para>
<para>As a general rule, use the session blackboard where
you might
usually use a Servlet session variable. As Ignition session
variables are
scoped by plugin, plugins cannot easily see the session
variables of other
plugins.
</para>
<para>Use the global blackboard when your information or
service is
not client-specific.</para>
</section>
<section>
<title>Session Attributes</title>
</section>
<section>
<title>Template Variables</title>
</section>
</section>
</wmdoc>
--
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants
|
|
From: Marc P. <ma...@an...> - 2003-04-23 21:21:43
|
On Wed, 23 Apr 2003 16:51:10 -0400, <Kea...@di...> wrote: > I updated the Wiki page to explain this issue with an example. Take a > look and see if it's ok. > > http://www.webmacro.org/IfDirective Nice one Keats! I edited it to correct a single typo (you had "and" instead of "an"). Thanks for the clarification. Maybe one day I -will-find a bug :) -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: <Kea...@di...> - 2003-04-23 20:51:30
|
I updated the Wiki page to explain this issue with an example. Take a look and see if it's ok. http://www.webmacro.org/IfDirective Keats Kea...@di... Sent by: web...@li... 04/23/2003 01:47 PM To: ma...@an... cc: web...@li..., web...@li... Subject: Re: [Webmacro-devel] New bug/misunderstanding - which is it :) ? I don't think there is a bug here, but some clarification of the docs is definitely needed. The #end before an #else or #elseif is optional, just like the #begin. The final #end is required. #if (true) #if (true) #end #elseif (false) #end would be interpreted as: #if (true) #begin #if (true) #begin #end #elseif #begin #end so you need another #end. If you want the #else to go with the outer #if, you would have to write #if (true) #if (true) #end #end #elseif (false) #end to disambiguate the syntax. It's unfortunate that the implicit #end doesn't work here. There was talk long ago about having an #endif syntax or something like that. This would solve your problem, but nobody seemed excited about it. Keats Marc Palmer <ma...@an...> Sent by: web...@li... 04/23/2003 01:14 PM Please respond to marc To: web...@li... cc: Subject: Re: [Webmacro-devel] New bug/misunderstanding - which is it :) ? On Wed, 23 Apr 2003 12:53:04 -0400, Eric B. Ridge <eb...@tc...> wrote: > Another thought, what if you rewrite it like this: > > #if (true) > #if (true) > #end > #end > #elseif (false) > #end > > I bet that'll parse correctly... Yes it seems to. Is #end before #elseif required? I suppose it should be, but without nested #if this has worked for me fine, so one way or another something needs "fixing". Either we require #end always before #elseif or we fix the nesting issue. Sound reasonable? The #if page in Wiki doesn't mention behaviour with #end blocks - only { and } blocks, and of course it shows that a closing } is required before #elseif. Which makes me wonder if this is deliberately implemented to work without #end, and there's something screwy in the impl. Cheers -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants ------------------------------------------------------- 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 |
|
From: Marc P. <ma...@an...> - 2003-04-23 18:50:44
|
Hiya, OK Brian's new WM(Properties) handling is largely OK. However I have found an issue. It relies on Properties.equals() to compare the properties passed in against those used for previous WM instances. This seems to work OK, unless you construct a Properties that defers to a default Properties object. In this case it returns the wrong WM instances if only the defaults are different. As I read the JDK 1.4 docs, it looks like Properties.equals is implemented under the terms of Map, which I guess means it doesn't call equals on the defaults. I don't have JDK source installed to check this but it certainly seems like what I was getting. Basically: Properties props = new Properties( defaultProps) props.putAll( moduleSpecificProps); WM wm = new WM( this, props); Now I might do this many times in my webapp, once for each module defined by the user. The thing is if there are no new properties defined by the module (a rare case, but it has happened during testing) but the defaultProps differ between modules (as they always do), WM returns the same WM instance for all of the modules. I can workaround this with: Properties props = new Properties() props.putAll( defaultProps); props.putAll( moduleSpecificProps); WM wm = new WM( this, props); ...and it works fine. Marc -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: <Kea...@di...> - 2003-04-23 17:47:49
|
I don't think there is a bug here, but some clarification of the docs is
definitely needed. The #end before an #else or #elseif is optional, just
like the #begin. The final #end is required.
#if (true)
#if (true)
#end
#elseif (false)
#end
would be interpreted as:
#if (true)
#begin
#if (true)
#begin
#end
#elseif
#begin
#end
so you need another #end.
If you want the #else to go with the outer #if, you would have to write
#if (true)
#if (true)
#end
#end
#elseif (false)
#end
to disambiguate the syntax. It's unfortunate that the implicit #end
doesn't work here.
There was talk long ago about having an #endif syntax or something like
that. This would solve your problem, but nobody seemed excited about it.
Keats
Marc Palmer <ma...@an...>
Sent by: web...@li...
04/23/2003 01:14 PM
Please respond to marc
To: web...@li...
cc:
Subject: Re: [Webmacro-devel] New bug/misunderstanding - which is it :) ?
On Wed, 23 Apr 2003 12:53:04 -0400, Eric B. Ridge <eb...@tc...> wrote:
> Another thought, what if you rewrite it like this:
>
> #if (true)
> #if (true)
> #end
> #end
> #elseif (false)
> #end
>
> I bet that'll parse correctly...
Yes it seems to. Is #end before #elseif required? I suppose it should be,
but without nested #if this has worked for me fine, so one way or another
something needs "fixing". Either we require #end always before #elseif or
we fix the nesting issue.
Sound reasonable? The #if page in Wiki doesn't mention behaviour with #end
blocks - only { and } blocks, and of course it shows that a closing } is
required before #elseif.
Which makes me wonder if this is deliberately implemented to work without
#end, and there's something screwy in the impl.
Cheers
--
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants
-------------------------------------------------------
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
|
|
From: Marc P. <ma...@an...> - 2003-04-23 17:33:28
|
On Wed, 23 Apr 2003 18:14:18 +0100, Marc Palmer <ma...@an...> wrote: > On Wed, 23 Apr 2003 12:53:04 -0400, Eric B. Ridge <eb...@tc...> wrote: > >> Another thought, what if you rewrite it like this: >> >> #if (true) >> #if (true) >> #end >> #end >> #elseif (false) >> #end [snip] > Which makes me wonder if this is deliberately implemented to work without > #end, and there's something screwy in the impl. Duh I can see why this isn't the problem. #elseif could be for the inner #if after the #end therefore it is an ambiguous situation. Is there a way we can make it so #elseif does NOT require a #end prior to it, in fact it cannot have one, which would remove the ambiguity wouldn't it? ...or always force #end before #elseif if we cannot do the above. Cheers -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: Marc P. <ma...@an...> - 2003-04-23 17:14:42
|
On Wed, 23 Apr 2003 12:53:04 -0400, Eric B. Ridge <eb...@tc...> wrote:
> Another thought, what if you rewrite it like this:
>
> #if (true)
> #if (true)
> #end
> #end
> #elseif (false)
> #end
>
> I bet that'll parse correctly...
Yes it seems to. Is #end before #elseif required? I suppose it should be,
but without nested #if this has worked for me fine, so one way or another
something needs "fixing". Either we require #end always before #elseif or
we fix the nesting issue.
Sound reasonable? The #if page in Wiki doesn't mention behaviour with #end
blocks - only { and } blocks, and of course it shows that a closing } is
required before #elseif.
Which makes me wonder if this is deliberately implemented to work without
#end, and there's something screwy in the impl.
Cheers
--
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants
|
|
From: Eric B. R. <eb...@tc...> - 2003-04-23 16:53:12
|
Another thought, what if you rewrite it like this:
#if (true)
#if (true)
#end
#end
#elseif (false)
#end
I bet that'll parse correctly...
eric
On Wednesday, April 23, 2003, at 12:28 PM, Marc Palmer wrote:
>
> Hi all,
>
> OK I've been experiencing this for a while but it has been hard to
> isolate.
>
> There appears to be a bug in #elseif handling when nested #if is used.
> This is the smallest, simplest example I can reduce it to:
>
> #if (true)
> #if (true)
> #end
> #elseif (false)
> #end
>
> This template will not build (try it!). It complains of EOF because it
> expects another #end. If you add redundant #else clauses it will work:
>
> #if (true)
> #if (true)
> #else
> #end
> #elseif (false)
> #else
> #end
>
> The expressions here are not important - they are just placeholders to
> make it build.
>
> Obscure huh? I can't believe nobody found this before - which makes me
> think it is to do with using #begin...#end blocks with implicit
> #begin. Most people seem to use { } blocks which I don't like.
>
> So, bug or misunderstanding this time? :-)
>
> --
> Marc Palmer (Wangjammer5)
> http://www.wangjammers.org
> Java Consultants
>
>
>
> -------------------------------------------------------
> 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
|
|
From: Eric B. R. <eb...@tc...> - 2003-04-23 16:49:43
|
On Wednesday, April 23, 2003, at 12:28 PM, Marc Palmer wrote: > > Hi all, > > OK I've been experiencing this for a while but it has been hard to > isolate. > > There appears to be a bug in #elseif handling when nested #if is used. > This is the smallest, simplest example I can reduce it to: > > #if (true) > #if (true) > #end > #elseif (false) > #end I think WM is seeing it as: #if (true) #if (true) #end #elseif (false) #end it's hard to say wether this is a bug or not. Like you, I would expect the #elseif to be part of the outer (first) #if, but it's being added to the inner #if. The reason it's hard to say is that this is perfectly valid syntax: #if (true) #end #elseif (false) #end because you can use #end to end *any* block, regardless of subdirectives. Maybe Brian has some ideas on how this can be "fixed". eric |
|
From: Marc P. <ma...@an...> - 2003-04-23 16:28:48
|
Hi all,
OK I've been experiencing this for a while but it has been hard to isolate.
There appears to be a bug in #elseif handling when nested #if is used. This
is the smallest, simplest example I can reduce it to:
#if (true)
#if (true)
#end
#elseif (false)
#end
This template will not build (try it!). It complains of EOF because it
expects another #end. If you add redundant #else clauses it will work:
#if (true)
#if (true)
#else
#end
#elseif (false)
#else
#end
The expressions here are not important - they are just placeholders to make
it build.
Obscure huh? I can't believe nobody found this before - which makes me
think it is to do with using #begin...#end blocks with implicit #begin.
Most people seem to use { } blocks which I don't like.
So, bug or misunderstanding this time? :-)
--
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants
|
|
From: <Kea...@di...> - 2003-04-23 16:09:19
|
>> The syntax is a bit funky. =A0I'll try to make a Wiki page. =A0(I'm a bi=
t=20
>> busy right now, having started a new job this week.)
> New job, eh? cool! Are you still in VA?
I'm in MD now (less than 2 mile from home). Now if I could just get them=20
to use WebMacro.
;-}
>> I'd also like to make a directive version of this. =A0Something like:
>>
>> #template $sqr { =A0
>> =A0 =A0 =A0 =A0 =A0#set $y =3D $x * $x
>> =A0 =A0 =A0 =A0 =A0$y
>> }
>> $sqr.Args.x =3D 10
>> $sqr.eval()
>>
>> Thoughts?
>That would get us closer to the default arg stuff that Nikhil G.=20
>Daddikar was looking for, and it would give us the recursion that Marc=20
>wants, right?
>I just don't like the idea of defining a template in a template. Heh,=20
>call it #macro...
Well the actual class is called MacroTemplate, so maybe the directive=20
could be #macrotemplate or something.
Keats
|
|
From: Eric B. R. <eb...@tc...> - 2003-04-23 15:57:16
|
On Wednesday, April 23, 2003, at 11:48 AM, Kea...@di...=20=
wrote:
> The syntax is a bit funky. =A0I'll try to make a Wiki page. =A0(I'm a =
bit=20
> busy right now, having started a new job this week.)
New job, eh? cool! Are you still in VA?
> I'd also like to make a directive version of this. =A0Something like:
>
> #template $sqr { =A0
> =A0 =A0 =A0 =A0 =A0#set $y =3D $x * $x
> =A0 =A0 =A0 =A0 =A0$y
> }
> $sqr.Args.x =3D 10
> $sqr.eval()
>
> Thoughts?
That would get us closer to the default arg stuff that Nikhil G.=20
Daddikar was looking for, and it would give us the recursion that Marc=20=
wants, right?
I just don't like the idea of defining a template in a template. Heh,=20=
call it #macro...
eric
|
|
From: <Kea...@di...> - 2003-04-23 15:48:53
|
Thanks, Lane. I introduced the $Template ContextTool quite a while ago, but I never got much feedback. It's been in the distro, but not enabled by default. The syntax is a bit funky. I'll try to make a Wiki page. (I'm a bit busy right now, having started a new job this week.) The code is quite simple. See http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/webmacro/webmacro/src/org/webmacro/servlet/TemplateTool.java?rev=1.5&content-type=text/vnd.viewcvs-markup I'd also like to make a directive version of this. Something like: #template $sqr { #set $y = $x * $x $y } $sqr.Args.x = 10 $sqr.eval() Thoughts? Keats Kirsch Internet Developer III Discovery Communications 240-813-2574 Kea...@Di... Lane Sharman <la...@op...> 04/23/2003 11:08 AM To: Kea...@di... cc: ma...@an..., web...@li... Subject: Re: [Webmacro-devel] Ugh - the reality of XML and flattened trees Hi Keats, This is __really cool__. I would definitely check this in to WM as an example application. So, is Template a context tool that is part of the current distro? It basically follows a pattern ebr and I worked on a while ago which was to embed in the context an instnace of WM to do helper evaluations. I like it! Could you give some more examples and place them in the distro and write up a verbose wiki page too. -Lane Kea...@di... wrote: >I wrote a little demo program to show how this can be done using the >$Template tool. > >The demo simulates a simple threaded message board. I created a simple >$Jdom tool so that I could construct the JDOM document in the template. >The #msg macro adds a new Message element to the JDOM document. > >I use #text inside of a #setblock to create the template string. It would >have been much cleaner to put this a separate file and use >$Template.fromFile(), but I wanted to have everything in one template for >simplicity. > >In order for the recursion to work, I had to pass a reference to the >template into the templates context. > >Let me know what you think. > >Keats > >################################# Start of WMScript > >#macro msg($parent, $title, $text){ > #set $junk = $msg.setAttribute("Title", $title) > #set $msg.Text = $text > #set $junk = $parent.addContent($msg) >} > >#set $el = $Jdom.newElement("Messages") >#set $doc = $Jdom.newDocument($el) > >#msg($el, "JDOM in a WebMacro template", "This is <b>way</b> cool!") > >#msg($el, "XSLT sucks", "Actually it's kind of cool, <i>for gear >heads</i>.") > >#msg($el, "Recursive templates", "Does this stuff really work?") > >#set $el2 = $msg > >#msg($el2, "RE: Recursive templates", "Could be") > >#set $el3 = $msg > >#msg($el3, "RE: RE: Recursive templates", "Looks like it does!") > >#msg($el2, "RE: Recursive template", "You're friggin' nuts!") > ><h3>Messages</h3> > >#setblock $tmplText { > #text > #foreach $child in $el.Children { > <blockquote> > <b>$child.AttributeValue.Title</b><br> > <i>$child.Text</i><br><br> > #set $tmpl.Args.el = $child > #set $tmpl.Args.tmpl = $tmpl > $tmpl.eval() > </blockquote> > } > #end >} > >#set $tmpl = $Template.fromString($tmplText) >#set $tmpl.Args.el = $el >#set $tmpl.Args.tmpl = $tmpl >$tmpl.eval() > > #################################### End of WMScript > > > > >------------------------------------------------------- >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 > > > |
|
From: Lane S. <la...@op...> - 2003-04-23 15:12:40
|
Hi Keats,
This is __really cool__.
I would definitely check this in to WM as an example application. So, is
Template a context tool that is part of the current distro? It basically
follows a pattern ebr and I worked on a while ago which was to embed in
the context an instnace of WM to do helper evaluations. I like it!
Could you give some more examples and place them in the distro and write
up a verbose wiki page too.
-Lane
Kea...@di... wrote:
>I wrote a little demo program to show how this can be done using the
>$Template tool.
>
>The demo simulates a simple threaded message board. I created a simple
>$Jdom tool so that I could construct the JDOM document in the template.
>The #msg macro adds a new Message element to the JDOM document.
>
>I use #text inside of a #setblock to create the template string. It would
>have been much cleaner to put this a separate file and use
>$Template.fromFile(), but I wanted to have everything in one template for
>simplicity.
>
>In order for the recursion to work, I had to pass a reference to the
>template into the templates context.
>
>Let me know what you think.
>
>Keats
>
>################################# Start of WMScript
>
>#macro msg($parent, $title, $text){
> #set $junk = $msg.setAttribute("Title", $title)
> #set $msg.Text = $text
> #set $junk = $parent.addContent($msg)
>}
>
>#set $el = $Jdom.newElement("Messages")
>#set $doc = $Jdom.newDocument($el)
>
>#msg($el, "JDOM in a WebMacro template", "This is <b>way</b> cool!")
>
>#msg($el, "XSLT sucks", "Actually it's kind of cool, <i>for gear
>heads</i>.")
>
>#msg($el, "Recursive templates", "Does this stuff really work?")
>
>#set $el2 = $msg
>
>#msg($el2, "RE: Recursive templates", "Could be")
>
>#set $el3 = $msg
>
>#msg($el3, "RE: RE: Recursive templates", "Looks like it does!")
>
>#msg($el2, "RE: Recursive template", "You're friggin' nuts!")
>
><h3>Messages</h3>
>
>#setblock $tmplText {
> #text
> #foreach $child in $el.Children {
> <blockquote>
> <b>$child.AttributeValue.Title</b><br>
> <i>$child.Text</i><br><br>
> #set $tmpl.Args.el = $child
> #set $tmpl.Args.tmpl = $tmpl
> $tmpl.eval()
> </blockquote>
> }
> #end
>}
>
>#set $tmpl = $Template.fromString($tmplText)
>#set $tmpl.Args.el = $el
>#set $tmpl.Args.tmpl = $tmpl
>$tmpl.eval()
>
> #################################### End of WMScript
>
>
>
>
>-------------------------------------------------------
>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
>
>
>
|
|
From: <web...@st...> - 2003-04-23 07:26:06
|
On Tue, 22 Apr 2003, Marc Palmer wrote:
| On Tue, 22 Apr 2003 15:33:51 +0100, Marc Palmer <ma...@an...> wrote:
|
| > On Tue, 22 Apr 2003 It's an XSLT-alike tool. It looks quite simple (in
| > the examples) but it follows the declarative model of XSLT which I don't
| > like myself... especially for "simple" tasks.
|
| Also, from what I can tell it's not made for producing normal content that
| "contains" some XML derived information - it looks like a straight XML
| processor using Velocity. At least, that looks like how it would work
| because it is declarative, so how would you control where your XML based
| data comes out inside the rest of your HTML WM content?
Trying to not sound like a feetlicking fan of Geir, but the guy is quite
good with his magic. I haven't had a single look at the code, but I
believe that such interesting things ("some XML-translated "code" within a
template") would be totally doable, considering his apparent "generality"
when it comes to coding..
Well.. Thought I'd just mention it, anyway..! "Steal" some ideas at least!
Endre
|
|
From: <Kea...@di...> - 2003-04-23 05:31:42
|
I wrote a little demo program to show how this can be done using the
$Template tool.
The demo simulates a simple threaded message board. I created a simple
$Jdom tool so that I could construct the JDOM document in the template.
The #msg macro adds a new Message element to the JDOM document.
I use #text inside of a #setblock to create the template string. It would
have been much cleaner to put this a separate file and use
$Template.fromFile(), but I wanted to have everything in one template for
simplicity.
In order for the recursion to work, I had to pass a reference to the
template into the templates context.
Let me know what you think.
Keats
################################# Start of WMScript
#macro msg($parent, $title, $text){ |
|
From: Marc P. <ma...@an...> - 2003-04-22 14:44:37
|
On Tue, 22 Apr 2003 15:33:51 +0100, Marc Palmer <ma...@an...> wrote: > On Tue, 22 Apr 2003 It's an XSLT-alike tool. It looks quite simple (in > the examples) but it follows the declarative model of XSLT which I don't > like myself... especially for "simple" tasks. Also, from what I can tell it's not made for producing normal content that "contains" some XML derived information - it looks like a straight XML processor using Velocity. At least, that looks like how it would work because it is declarative, so how would you control where your XML based data comes out inside the rest of your HTML WM content? -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: Marc P. <ma...@an...> - 2003-04-22 14:34:05
|
On Tue, 22 Apr 2003 16:15:24 +0200 (CEST), Endre Stølsvik <web...@st...> wrote: > On Tue, 22 Apr 2003, Marc Palmer wrote: > > [ -- a whole bunch of XML parsing stash -- ] > > Have you guys had a look at PSML (or whatever it was called) over at > Velocity? Geir wrote some apparently cool code to do XML "translation" > using Velocity. Maybe this would be stealable? It's an XSLT-alike tool. It looks quite simple (in the examples) but it follows the declarative model of XSLT which I don't like myself... especially for "simple" tasks. Docs here: http://jakarta.apache.org/velocity/dvsl/users-guide.html -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: <web...@st...> - 2003-04-22 14:15:29
|
On Tue, 22 Apr 2003, Marc Palmer wrote: [ -- a whole bunch of XML parsing stash -- ] Have you guys had a look at PSML (or whatever it was called) over at Velocity? Geir wrote some apparently cool code to do XML "translation" using Velocity. Maybe this would be stealable? -- Mvh, Endre Stølsvik M[+47 93054050] F[+47 51625182] Developer @ CoreTrek AS - http://www.coretrek.com/ CoreTrek corporate portal / EIP - http://www.corelets.com/ |
|
From: Marc P. <ma...@an...> - 2003-04-22 10:21:24
|
On Tue, 22 Apr 2003 11:03:00 +0100, Marc Palmer <ma...@an...> wrote: >>> #macro renderPara($node) >>> <p> >>> !!!! WHAT DO I DO HERE? !!!! >>> </p> >>> #end >> >> It depends on what a PARA can contain. If it can only contain text, B, >> I, TT, DIV, SPAN, and a few other text-formatting tags, you're fine. > > ...how? Using #foreach, and no #break/continue are you going to go > through the node list in each render macro, and then "return" to the > calling loop without having the calling loop also render the children you > just iterated over in the render macro. OK I see what you're saying now... don't have a full flattened list, just; 1. iter flattened list of para nodes 2. render for para iters flattened list of bold/italic/code and text nodes... ... but there are still lots of loops. I think it's really ugly, especially if we have another grouping node under <para> for example. Marc -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: Marc P. <ma...@an...> - 2003-04-22 10:04:43
|
On Mon, 21 Apr 2003 17:48:34 -0700, Brian Goetz <br...@qu...> wrote: >> OK so my colleague gave me the latest revision of our XML helper. So I >> start trying to write my simple template to render a simple XML based >> documentation grammar using a complete flattened tree and I'm already >> screwed. > > If your document grammar really is "simple", then it should not require > unbounded recursion. This isn't really fair Brian - you know that once things get over 1-2 nodes deep the code becomes much uglier than it needs to. > Most grammars for things like documents have a _fixed_ number of > hierarchy layers -- books contain chapters, chapters contain sections. > Sections do not contain books, nor do paragraphs contain other > paragraphs. If the template understands this grammar, it should be > possible to write something that traverses it without _unbounded_ > recursion. What you're describing requires lots of repetitive code, hard-coding for a specific DTD structure, which in my view is a short-term design bound to cause problems... > Also, why not let XPath do that for you? You want all the sections? > Select /doc/section. Want the paragraphs within a section? Select > "para" from a section node. OK, what about <bold>, <italic>, <code>, <bulletlist>, <listitem> etc. - it gets very unwieldy very quickly, even if you have a restricted hierarchy (bold under para only). Are you saying I should force that if something is bold and italic that bold must always come first?! If not, the code for handling either case will be interesting, and a waste of time IMO. > Think XP -- look for simplifying assumptions that describe the real-world > problems you're trying to solve, rather than look for a way to solve the > most general case you can think of. ...but in this case the solution for the most general case IS the simplest solution Brian! It's why programmers use recursion for this kind of thing. It is the most compact and least error-prone way of doing things, in terms of number of lines of code and maintaining the DRY principle (don't repeat yourself). >> To cut a long story short, I want to render <para> as <p> in HTML, and >> </p> when </para> occurs. Except DOM doesn't work like that. There are >> no closing nodes. So, it is not reasonably possible, without recursion, >> to write closing output tags when you have finished rendering child >> nodes. We could modify the helper to add closing nodes but that would be >> pretty stupid IMO. > > Annoying, but pretty easy to work around. Using #include for recursion ;-) Or, repeating the node iter loop in each render macro perhaps, but how to we break out? Maybe I'm being stupid but I can't see the easy workaround from here. >> #macro renderPara($node) >> <p> >> !!!! WHAT DO I DO HERE? !!!! >> </p> >> #end > > It depends on what a PARA can contain. If it can only contain text, B, > I, TT, DIV, SPAN, and a few other text-formatting tags, you're fine. ...how? Using #foreach, and no #break/continue are you going to go through the node list in each render macro, and then "return" to the calling loop without having the calling loop also render the children you just iterated over in the render macro. -- Marc Palmer (Wangjammer5) http://www.wangjammers.org Java Consultants |
|
From: Brian G. <br...@qu...> - 2003-04-22 00:48:56
|
>OK so my colleague gave me the latest revision of our XML helper. So I >start trying to write my simple template to render a simple XML based >documentation grammar using a complete flattened tree and I'm already screwed. If your document grammar really is "simple", then it should not require unbounded recursion. Most grammars for things like documents have a _fixed_ number of hierarchy layers -- books contain chapters, chapters contain sections. Sections do not contain books, nor do paragraphs contain other paragraphs. If the template understands this grammar, it should be possible to write something that traverses it without _unbounded_ recursion. Also, why not let XPath do that for you? You want all the sections? Select /doc/section. Want the paragraphs within a section? Select "para" from a section node. Think XP -- look for simplifying assumptions that describe the real-world problems you're trying to solve, rather than look for a way to solve the most general case you can think of. >To cut a long story short, I want to render <para> as <p> in HTML, and ></p> when </para> occurs. Except DOM doesn't work like that. There are no >closing nodes. So, it is not reasonably possible, without recursion, to >write closing output tags when you have finished rendering child nodes. We >could modify the helper to add closing nodes but that would be pretty >stupid IMO. Annoying, but pretty easy to work around. >#macro renderPara($node) > <p> > !!!! WHAT DO I DO HERE? !!!! > </p> >#end It depends on what a PARA can contain. If it can only contain text, B, I, TT, DIV, SPAN, and a few other text-formatting tags, you're fine. -- Brian Goetz Quiotix Corporation br...@qu... Tel: 650-843-1300 Fax: 650-324-8032 http://www.quiotix.com |
|
From: Marc P. <ma...@an...> - 2003-04-22 00:37:12
|
Hi all,
OK so my colleague gave me the latest revision of our XML helper. So I
start trying to write my simple template to render a simple XML based
documentation grammar using a complete flattened tree and I'm already
screwed.
It is not a good solution.
Take the following trivial XML:
<wmdoc>
<para>This is some text</para>
</wmdoc>
To cut a long story short, I want to render <para> as <p> in HTML, and </p>
when </para> occurs. Except DOM doesn't work like that. There are no
closing nodes. So, it is not reasonably possible, without recursion, to
write closing output tags when you have finished rendering child nodes. We
could modify the helper to add closing nodes but that would be pretty
stupid IMO.
To demonstrate - I get all those nodes (wmdoc, para, text node) as a
flattened list and pass them to code like this:
#macro renderDocs( $nodeList)
#foreach $node in $nodeList
#if ($node.IsElement)
#if ($node.Name == "title")
#renderTitle($node)
#elseif ($node.Name == "para")
#renderPara($node)
#else
#end
#elseif ($node.IsText || $node.IsCDATA)
$node
#else
#end
#end
#end
#macro renderPara($node)
<p>
!!!! WHAT DO I DO HERE? !!!!
</p>
#end
As you can see above, without any recursion renderPara cannot work, as you
cannot "call out" to have the children rendered before your </p> tag. The
only workaround I can see for this is some ugly stack object and some nasty
code to work out when the current parent changes "up" (tricky).
So, unless anybody has any bright ideas here, I think we can safely scrub
off the "use a flattened tree" as an option for rendering even simple trees
where you want every node and need its "ancestral history" for context.
Comments? foreach/#foreachnode with tree support is looking more attractive
by the day :)
For what it's worth, I just used #setblock for the first time to do
something neat - display the source of a WM template:
#setblock as macro $source #include as text "$templateName"
#end
<pre>
$Text.HTMLEncode( $source)
</pre>
Neat huh? Not rocket science, sure... but useful for teaching people by
showing them the template behind the page they just viewed.
--
Marc Palmer (Wangjammer5)
http://www.wangjammers.org
Java Consultants
|
|
From: Brian G. <br...@qu...> - 2003-04-21 16:59:24
|
> OK from Brian's extremely helpful discussion on this issue already, > I think we can now narrow the problem space into two sections. I > would like to add that at this point I think it is helpful to > remember that we are not just discussing XML usage here - we should > consider any tree structure - although XML is the most prevalent > example that springs to mind. Putting my XP hat on, I'm not sure the full generality case is worth the cost if the XML case covers 90+% of the situations where you'd want it. Are you sure that the non-XML case is really all that important right now? As I've mentioned, the issue of tree traversal has not come up very often. So if the real-world problem in front of us today is XML traversal, then I think the XPath solution is perfect, because it addresses the XML problem quite nicely and cleanly with no changes to the WM syntax and no new directives. After thinking about it for a day, the XPath solution seems very powerful to me and a very clean fit. XPath lets you select parts of the tree even if you don't know its exact structure (e.g., "select all FOO elements"). > #foreachnode $node in $mytreeData topdown filtering ( $node.IsText && > ($node.Parent.Name == "description")) > $node.Value > #end Of course, the filtering could be achieved via a #continue directive too. > Problem 2 can either be solved by having a helper class that can > return ALL nodes flattened, or by a similar tree iteration > mechanism. Which is basically what XPath does for XML. > Flattening a whole tree is often easy enough - and in fact in my current > XML problem scenario we have a method to do this - but it is really rather > wasteful of memory and processing. I think the efficiency argument is a red herring. First of all, the time it takes to convert a tree to a flattened list is mostly the time to traverse it once. That's usually fast. And it only requires enough memory to store an additional set of references to the nodes -- because you can re-use the nodes. First, get the result you want, and then, if its super-inefficient, figure out how to make it faster. For small-ish trees, you might find that the cost is dwarfed by other things you do on every HTTP request. |
|
From: Brian G. <br...@qu...> - 2003-04-21 16:39:05
|
> Do you know of a good free XPath lib we can pull in to use for this? I > haven't found one yet. There's one in Apache Xalan 2 but I am pretty sure > it depends on a lot of Xalan code so it would be serious overkill. Jaxen. |
237 messages has been excluded from this view by a project administrator.
