20 Mar
2009
20 Mar
'09
11:47 p.m.
Hi Niels,
On Fri, Mar 20, 2009 at 19:37, Niels Mayer <nielsmayer(a)gmail.com> wrote:
why does RSS need a box at all? Why not have a
separate "box" that wraps it
when needed?
#boxbegin()
{rss:feed...}
#boxend()
We could remove all box support in rss macro and use the box macro
arround rss macro like this:
{{box}}
{{rss field="feed="http://some.feed.com""}}
{{/box}}
but was decided that the default design of a rss macro was a rss feed
printed inside a graphical box and it's easier for a user to use only
one macro.
Because otherwise, you have to do all sorts of ridiculous things to
get rid of the "box", like
http://nielsmayer.com/xwiki/bin/view/Macros/styledRSS?viewer=code
http://nielsmayer.com/xwiki/bin/view/Timeline/KcrwFeeds?viewer=code
just to get http://nielsmayer.com/xwiki/bin/view/Timeline/KcrwFeeds
Finally, it would be nice if there was a more-useful-for-use-in-velocity
version of {rss:feed} something that just generated the feed as an abstract
"iterator" and then let you pull out fields as strings, and then decorate
them as you wish in velocity&html, e.g. via #beginfeedbox() #endfeedbox()
and #feedbox-item() in the example/wish below:
#set( $feeds = $xwiki.getFeed("http://kcrw.com/podcast/show/ww")
#beginfeedbox()
#foreach ($f in $feeds)
#feedbox-item ($f.title , !$f.date, !$f.description , !$f.link )
#end
#endfeedbox()
What you need here is a rss management api. The easiest way to do what
you need is to write a java plugin exposing ROME api to acces it from
velocity or directly use ROME api (which is packaged with XWiki) from
a groovy script. See https://rome.dev.java.net/ for more details.
The current mail is about the XWiki 2.0 rss macro which is not a
script tool but wiki syntax to execute a "pre designed" feature to
nicely print a rss in a page.
The above "layered" approach also permits
reuse of the feed primitives for
other purposes, such as "extract all media feed references and their names."
Also, it seems inconsistent to have something like {rss:feed} when most of
the other curly-markups like that aren't quite as "active" and tend to
just
define blocks of wiki-code. I'm not sure if "block of wikicode" is the
right
abstraction for an RSS feed.
Niels
http://nielsmayer.com
On Fri, Mar 20, 2009 at 10:21 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
--
Thomas Mortagne
Dan Miron wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi guys! I'd like to know what you think
about this matter, which has
been raised on http://jira.xwiki.org/jira/browse/XWIKI-3375.
As I posted there, this is what I think:
-the parameters for the two macros are completely different, so i see no
point for having the box specific parameters (cssClass, title, image,
width and blockTitle) among the rss macro's ones, this will lead to
confusion for the user. The box parameters are deduced from the rss
feed's properties and then passed to the box macro. No need for them to
be exposed in the Rss Macro. Therefore, extending the RssMacroParameters
from the BoxMacroParameters is unreliable.
-extending the RssMacro from the AbstractBoxMacro<RssMacroParameters>
doesn't mean simply implementing AbstractBoxMacro.parseContent instead
of Macro.execute. Currently, most of the code about the box around the
css macro is placed in the box macro's implementation, which is
DefaultBoxMacro, so we do make use of the existing implementations.
Giving up using the box macro internally means giving up using most of
the features already presented in the box macro and rewriting them
-and finally, the most time costing disadvantage is that extending the
rss macro from the box basically means rewriting this macro from
scratch, because it involves redesigning it, task that will cost us time.
So, therefore, I'm -1 for this.
Inheritance implies an "is-a" relationship. So, the important question
is: is a RSS display a Box? Will a RSS display always be a box?
IMHO, no. The fact that currently the RSS macro uses a box is a
presentation detail that might change in the future. Hierarchies are
harder to change, compositions are easier.
+1 for composition (RSS not extending Box, but using one internally, as
it is done now).
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs