[xwiki-devs] [Vote] Should the RSS macro extend the Box macro instead of just using it internally?
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. Tnx, Dan
On Fri, Mar 20, 2009 at 12:37, Dan Miron <dan.miron@xwiki.com> 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.
Since rss macro is a box and should support all box macro parameters, if some parameters of box macro break the rss macro then box macro is not generic enough.
-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
All the box macro feature are supposed to be implemented in AbstractBoxMacro and DefaultBoxMacro is just as its name say it: a default implementation for the content of the box. If it's more then it's totally wrong.
-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.
I'm just speaking about the box around the whole rss, making rss macro extends box macro is more about removing code, I can imagine how it could be possible that it make "rewriting this macro from scratch".
So, therefore, I'm -1 for this.
Tnx, Dan _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Dan, I think the general issue is that a macro is not able to "hide" some of its base macro parameters when it has fixed values for them. I don't know the details though. Marius 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.
Tnx, Dan _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
On Fri, Mar 20, 2009 at 14:28, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
Hi Dan,
I think the general issue is that a macro is not able to "hide" some of its base macro parameters when it has fixed values for them. I don't know the details though.
This could be fixed using some tag like @hide which is already needed BTW since Box macro contains a field not usable from syntax/WYSIWYG.
Marius
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.
Tnx, Dan _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Fri, Mar 20, 2009 at 14:40, Thomas Mortagne <thomas.mortagne@xwiki.com> wrote:
On Fri, Mar 20, 2009 at 14:28, Marius Dumitru Florea <mariusdumitru.florea@xwiki.com> wrote:
Hi Dan,
I think the general issue is that a macro is not able to "hide" some of its base macro parameters when it has fixed values for them. I don't know the details though.
This could be fixed using some tag like @hide which is already needed BTW since Box macro contains a field not usable from syntax/WYSIWYG. (not usable until we make a String -> List<Box> -> String bean converter which is not difficult to do anyway but would need http://jira.xwiki.org/jira/browse/XWIKI-3171 to be cleaner)
Marius
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.
Tnx, Dan _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
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/
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
Hi Niels, On Fri, Mar 20, 2009 at 19:37, Niels Mayer <nielsmayer@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@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
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Fri, Mar 20, 2009 at 11:37 AM, Niels Mayer <nielsmayer@gmail.com> wrote:
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()
Answering my own question, you can do the kind of things I asked for like this in Velocity and Xwiki: http://nielsmayer.com/xwiki/bin/view/Timeline/KcrwFeeds2?viewer=code which when wrapped in http://nielsmayer.com/xwiki/bin/view/Timeline/TL3?viewer=code gives: http://nielsmayer.com/xwiki/bin/view/Timeline/TL3 (warning, takes a long time to load). With the RSS code looking like this: {pre} <data> #set( $allcasts = [["http://kcrw.com/podcast/show/at","Crimson"], ["http://kcrw.com/podcast/show/bw","Cyan"], ["http://kcrw.com/podcast/show/de","DarkBlue"], ["http://kcrw.com/podcast/show/fr","DarkCyan"], ["http://kcrw.com/podcast/show/gg","DarkGoldenRod"], ["http://kcrw.com/podcast/show/gf","DarkGray"], ["http://kcrw.com/podcast/show/gd","DarkGreen"], ["http://kcrw.com/podcast/show/lo","DarkKhaki"], ["http://kcrw.com/podcast/show/lr","DarkMagenta"], ["http://kcrw.com/podcast/show/ls","DarkOliveGreen"], ["http://kcrw.com/podcast/show/ma","Darkorange"], ["http://kcrw.com/podcast/show/mb","DarkOrchid"], ["http://kcrw.com/podcast/show/ob","DarkRed"], ["http://kcrw.com/podcast/show/so","DarkSalmon"], ["http://kcrw.com/podcast/show/th","DarkSeaGreen"], ["http://kcrw.com/podcast/show/tb","DarkSlateBlue"], ["http://kcrw.com/podcast/show/bb","DarkSlateGray"], ["http://kcrw.com/podcast/show/pc","DarkTurquoise"], ["http://kcrw.com/podcast/show/ts","DarkViolet"], ["http://kcrw.com/podcast/show/tt","DeepPink"], ["http://kcrw.com/podcast/show/ur","DeepSkyBlue"], ["http://kcrw.com/podcast/show/tu","DimGray"], ["http://kcrw.com/podcast/show/tp","DodgerBlue"], ["http://kcrw.com/podcast/show/ti","ForestGreen"], ["http://kcrw.com/podcast/show/ww","Fuchsia"]] ) #set( $openTab = $xwiki.getXMLEncoded("<TABLE><TBODY>") ) #set( $closeTab = $xwiki.getXMLEncoded("</TBODY></TABLE>") ) #set( $openDesc = $xwiki.getXMLEncoded("<TR><TH>") ) #set( $closeDescOpenVal = $xwiki.getXMLEncoded("</TH><TD>") ) #set( $closeVal = $xwiki.getXMLEncoded("</TD></TR>") ) #set( $openA = $xwiki.getXMLEncoded("<A ") ) #set( $endA = $xwiki.getXMLEncoded(">") ) #set( $closeA = $xwiki.getXMLEncoded("</A>") ) #foreach ($feed in $allcasts) ##{ #set( $feed_obj = $xwiki.feed.getFeed($feed.get(0)) ) #set( $feed_title = $xwiki.getXMLEncoded($feed_obj.getTitle()) ) #set( $feed_link = $xwiki.getXMLEncoded($feed_obj.getLink()) ) #foreach($entry in ${feed_obj.entries}) ##{ #set( $entry_link = $xwiki.getXMLEncoded(${entry.link}) ) #set( $entry_desc = $xwiki.getXMLEncoded(${entry.description.value}) ) <event start="$entry.getPublishedDate().toLocaleString()" title="$xwiki.getXMLEncoded($entry.title)" color="$feed.get(1)" textColor="$feed.get(1)"> ${openTab} ${openDesc}Feed: ${closeDescOpenVal}${feed_title}${closeVal} ${openDesc}Link: ${closeDescOpenVal}${openA}href=’${feed_link}’ target=’_blank’${endA}${feed_link}${closeA}${closeVal} ${openDesc}Media: ${closeDescOpenVal}${openA}href=’${entry_link}’ target=’_blank’${endA}${entry_link}${closeA}${closeVal} ${openDesc}${closeDescOpenVal}${entry_desc}${closeVal} ${closeTab} </event> #end ##} #end ##} </data> {/pre} -- Niels http:nielsmayer.com
participants (5)
-
Dan Miron -
Marius Dumitru Florea -
Niels Mayer -
Sergiu Dumitriu -
Thomas Mortagne