[xwiki-devs] [Vote] Should the RSS macro extend the Box macro instead of just using it internally?
20 Mar
2009
20 Mar
'09
12:37 p.m.
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
20 Mar
20 Mar
2:20 p.m.
New subject: [xwiki-devs] [Vote] Should the RSS macro extend the Box macro instead of just using it internally?
On Fri, Mar 20, 2009 at 12:37, Dan Miron <dan.miron(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
2:28 p.m.
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:40 p.m.
New subject: [xwiki-devs] [Vote] Should the RSS macro extend the Box macro instead of just using it internally?
On Fri, Mar 20, 2009 at 14:28, Marius Dumitru Florea
<mariusdumitru.florea(a)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:
--
Thomas Mortagne
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:42 p.m.
New subject: [xwiki-devs] [Vote] Should the RSS macro extend the Box macro instead of just using it internally?
On Fri, Mar 20, 2009 at 14:40, Thomas Mortagne
<thomas.mortagne(a)xwiki.com> wrote:
--
Thomas Mortagne
On Fri, Mar 20, 2009 at 14:28, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
(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)
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:
--
Thomas Mortagne
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:21 p.m.
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/
7:37 p.m.
New subject: [xwiki-devs] [Vote] Should the RSS macro extend the Box macro instead of just using it internally?
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(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:47 p.m.
New subject: [xwiki-devs] [Vote] Should the RSS macro extend the Box macro instead of just using it internally?
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
24 Mar
24 Mar
2:29 a.m.
New subject: [xwiki-devs] [Vote] Should the RSS macro extend the Box macro instead of just using it internally?
On Fri, Mar 20, 2009 at 11:37 AM, Niels Mayer <nielsmayer(a)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
5712
days inactive
5716
days old
8 comments
5 participants
participants (5)
-
Dan Miron -
Marius Dumitru Florea -
Niels Mayer -
Sergiu Dumitriu -
Thomas Mortagne