Inclusion of root topic in DBRECURSE call (for RSS feed)

Hi there,

I'm trying to make an RSS feed to return results of updates to a tree of topics (including the root). I can't work out how to make DBRECURSE return the root topic as well as the sub-topics (see code snippet below).

%DBRECURSE{
  "RootTopic"
  limit="10"
  sort="modified"
  reverse="on"
  format=" <*RSS MAGIC STUFF GOES HERE*>"
}%

This query returns:

SubTopic1
SubTopic2
...
SubTopicn

But not RootTopic

My questions are:

Any hints?
Is this type of query supported in in DBCachePlugin?
Should I be making an RSS feed like this using a different method?
I looked at using TreePlugin for this, but I couldn't order the results by reverse modification date or limit the number of results. So I assume it's not suitable for a RSS feed where I would want to return the 10 most recently updated topics.

-- HughBlair - 28 Aug 2011

Hi Hugh,

I'm afraid I don't use this plugin any more, but you might be able to use the header parameter to emit the root element with $web.$topic. If you already use header param, you might want to move some or all of it into subheader. If you don't use any header param at the moment, you probably want to set the subheader empty, Eg. (untested):

%DBRECURSE{
  "RootTopic"
  limit="10"
  sort="modified"
  reverse="on"
  header="<*RSS MAGIC STUFF FOR ROOT $topic GOES HERE*>"
  subheader=""
  format=" <*RSS MAGIC STUFF GOES HERE*>"
}%

If that doesn't work, I guess you'll have to write something like:

%DBRECURSE{
  "RootTopic"
  limit="10"
  sort="modified"
  reverse="on"
  header="<*RSS MAGIC STUFF FOR ROOT RootTopic GOES HERE*>"
  subheader=""
  format=" <*RSS MAGIC STUFF GOES HERE*>"
}%

or

<*RSS MAGIC STUFF FOR ROOT RootTopic GOES HERE*>
%DBRECURSE{
  "RootTopic"
  limit="10"
  sort="modified"
  reverse="on"
  format=" <*RSS MAGIC STUFF GOES HERE*>"
}%

And if that's unacceptable (you don't want to write RootTopic twice), you might turn this into a sectional INCLUDE (see 4. Include a topic MyTopic with two parameters).

Also, please don't use GluePlugin's ~~~ syntax - it's unnecessary 99% of the time - I've created Tasks.Item11103 to get the plugin description updated to reflect this.

-- PaulHarvey - 04 Sep 2011

Hi Paul, thanks for your feedback on this. The above crossed my mind as a solution, but I discarded it without trying because I assumed it means that RootTopic will always be included in the RSS results even when it hasn't been updated, or have I missed something? The general idea is that the reverse, sort and limit arguments would apply to RootTopic in combination to the other results in the Query as well. Thoughts?

-- HughBlair - 05 Sep 2011

Whoops, you're right. Hrmm. Maybe try a custom filter query, something like:

%DBRECURSE{
  "RootTopic"
  filter="parent='$name' OR name='RootTopic'"
  limit="10"
  sort="modified"
  reverse="on"
  format=" <*RSS MAGIC STUFF GOES HERE*>"
}%

-- PaulHarvey - 06 Sep 2011

Thanks for the tips Paul.

Actually now that I think about it, a well-behaved RSS reader should be able to ignore subsequent identical results if the attributes are the same (it should cache the previous RSS result for comparrison). So it should not matter if the RootTopic is returned each time.

So I...

removed the reverse and sort parameters (RSS readers should be able to do that by themselves anyhow), I'll probably add them back in again in my next iteration.
removed the limit paramater, but again I'll probably put it back in again once I've tested it
changed the item title field to include the revision so that a topic update doesn't show as a repeat result
configured the date using $http time since the RSS readers I've tried seem happy with that.
used the URL parameter "roottopic" as the topic name in my example so an RSS link can be used in the skin template for a link like "Subscribe by RSS to this topic (and all sub-topics)".

Here's the variation on your suggestion above that I've tried. It seems to work ok so far:

%DBQUERY{ \
   topic="%URLPARAM{"roottopic"}%" \
   format="<item rdf:about=$quot$topic$quot> \
              <title>$topic revision $expand(info.rev) </title>$n \
              <link>$topic</link>$n \
              <description> current revision is $expand(info.rev) (last changed by $expand(info.author)) </description>$n \
              <dc:date> $formatTime(@topic.info.date,'$http') </dc:date> $n \
              <dc:contributor>$n <rdf:Description link=$quot$topic$quot>$n <rdf:value>$expand(info.author)</rdf:value>$n </rdf:Description>$n </dc:contributor> \
           </item>" }%

%DBRECURSE{ \
   "%URLPARAM{"roottopic"}%" \
   format="<item rdf:about=$quot$topic$quot> \
              <title>$topic revision $expand(info.rev) </title>$n  \
              <link>$topic</link>$n \
              <description> current revision is $expand(info.rev) (last changed by $expand(info.author)) </description>$n \
              <dc:date> $formatTime(@topic.info.date,'$http') </dc:date> $n \
              <dc:contributor>$n <rdf:Description link=$quot$topic$quot>$n <rdf:value>$expand(info.author)</rdf:value>$n </rdf:Description>$n </dc:contributor> \
           </item>" }%

Cool!

By the way, you don't need trailing slashes to break up a registerTagHandler macro (most macros in Foswiki).

You only need trailing slashes to break up line-sensitive WikiSyntax aka 'TML' markup, like tables or lists. Also, in Foswiki, <html> tags must be on a single line, unless you break them up with trailing slashes. So, the following are normal usages of \:

| *Heading1* | *Heading2* |
| This \
  is \
  a \
  really \
  long table cell | b |
| c | d |

<a \
  href="/this/is/a/really/long" \
  class="tag" \
> foo
</a>

It helps to understand that %MACROS{..}% are expanded first in the rendering pipeline, and only then is WikiSyntax/TML rendered.

So, if you can review inside-out, left-to-right, you'll (hopefully!

see why in fact you don't need any trailing slashes at all in this example:

| *Heading1* | *Heading2* |
| %INCLUDE{
  "This"
  is="a"
  really="long"
  macro="expression"
  for="a single table cell value"
  however="its result must not contain any newlines (or if it,
                 does they must be escaped with trailing slashes)"
}% | b |
| c | d |

-- PaulHarvey - 07 Sep 2011

That's great! Even more readable than with glue or trailing \...

What about multi-line variable assignments, for example in my code snippet above I use two identical format arguments to DBCachePlugin, can I do a multi-line Set statement to avoid double handling the code?

I tried this both with trailing \ and with glue chars, but neither give quite the right result, here's how I tried it:

   * Set ROYALDECREE = "kingdom of \
blah"

What is %ROYALDECREE%


   * Set PRESIDENTIALMANDATE = "parliament of 
~~~ blah"

What is %PRESIDENTIALMANDATE%

-- HughBlair - 07 Sep 2011

I'm afraid set statements are evaluated separately to the rendering process, where neither trailing slash nor glue will help. Best to store multiline stuff in an include section or formfield

-- PaulHarvey - 08 Sep 2011