Hi Niels,
On Fri, Mar 20, 2009 at 19:37, Niels Mayer <[email protected]> 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 <[email protected]> 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
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
