why does RSS need a box at all? Why not have a separate "box" that wraps it when needed? #boxbegin() {rss:feed...} #boxend() 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() 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@xwiki.com> wrote:
Dan Miron wrote:
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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs