Re: [xwiki-devs] Blog Wiki 2.0 Upgrade 7th Draft
Hi I know that we all volunteer for this project and so this is not a critic of anybody's work but I have to say that the Feed Plugin has more holes than a Swiss cheese and I should know. I could work around all the issues but now the SyndEntryDocumentSource class does not render Wiki 2.0 code (hard coded to 1.0). There is also an issue where the conversion of Categories fails in the Rome Converters because the Categories is a String but the Rome expects a SyncdCategory. The only conversion that works so far is atom_0.3. One of the problems I see with the Feed Plugin is that the test suite is not sufficient and therefore many of the method now fail in 2.0. I would volunteer to help to build it if someone could show me to how to setup a test environment where I could execute the Feed Plugin against (Blog first). Is there a plugin that tests against a mock up XWiki to make sure it is working? Cheers Andreas Schaefer
On Aug 11, 2009, at 5:15 AM, Andreas Schaefer wrote:
Hi
I know that we all volunteer for this project and so this is not a critic of anybody's work but I have to say that the Feed Plugin has more holes than a Swiss cheese and I should know. I could work around all the issues but now the SyndEntryDocumentSource class does not render Wiki 2.0 code (hard coded to 1.0).
There is also an issue where the conversion of Categories fails in the Rome Converters because the Categories is a String but the Rome expects a SyncdCategory. The only conversion that works so far is atom_0.3.
One of the problems I see with the Feed Plugin is that the test suite is not sufficient and therefore many of the method now fail in 2.0. I would volunteer to help to build it if someone could show me to how to setup a test environment where I could execute the Feed Plugin against (Blog first). Is there a plugin that tests against a mock up XWiki to make sure it is working?
Yes, the feed plugin was written pre-new architecture (component-based with tests)... It'll need to be redesigned/rewritten at some points to align it. This rewrite is not planned by any current committer so this will take a while (unless someone volunteers to do it) so I think it's safe to fix it here and there if needed for the moment. Thanks -Vincent
Hi Vincent Ok, so I will go ahead and update the Feed Plugin to make it work for the Blog from 1.9 (with Wiki 1.0) as well as the one with Wiki 2.0. This means it will no longer work with a blog based on XWiki.ArticleClass (version ?). I would also to add this methods to the API: - String createFeedOutput(SyncdFeed feed, String type): this would enable anyone to convert a feed into an output format without having to overload so many methods I hope that I have this done by tomorrow and will attach a patch to a JIRA report I am going to create (none of the open JIRA report matches this issue). This should finally make the Blog Upgrade complete, I hope. BTW I am going to upgrade my server to 2.0m3 when I become available and will test as far as I can. In case something goes wrong I will revert back to 1.9.2 but I hope I don't have to do it. On another little note I was wondering what should I do with the Panels? - Are the left on Wiki 1.0 code? - Is there a Base Panel which is in Wiki 2.0 (Panel.PanelSheet) - if not do we want to create a Wiki 2.0 based Panel Sheet? The reason why I am asking is that I saw Jetty run out of memory or stack space having a Blog Panel in Wiki 2.0 using Panel.PanelSheet. I am not sure what is the reason but when I reverted the panels back to 1.0 the problems went away. FINALLY is the idea, after the blog 2.0 upgrade, to create a Blog Plugin that would provide the code for a Blog inside Java? Or is that a Macro or Extension? Cheers - Andy On Aug 11, 2009, at 1:02 AM, Vincent Massol wrote:
On Aug 11, 2009, at 5:15 AM, Andreas Schaefer wrote:
Hi
I know that we all volunteer for this project and so this is not a critic of anybody's work but I have to say that the Feed Plugin has more holes than a Swiss cheese and I should know. I could work around all the issues but now the SyndEntryDocumentSource class does not render Wiki 2.0 code (hard coded to 1.0).
There is also an issue where the conversion of Categories fails in the Rome Converters because the Categories is a String but the Rome expects a SyncdCategory. The only conversion that works so far is atom_0.3.
One of the problems I see with the Feed Plugin is that the test suite is not sufficient and therefore many of the method now fail in 2.0. I would volunteer to help to build it if someone could show me to how to setup a test environment where I could execute the Feed Plugin against (Blog first). Is there a plugin that tests against a mock up XWiki to make sure it is working?
Yes, the feed plugin was written pre-new architecture (component-based with tests)... It'll need to be redesigned/rewritten at some points to align it. This rewrite is not planned by any current committer so this will take a while (unless someone volunteers to do it) so I think it's safe to fix it here and there if needed for the moment.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Andreas Schaefer a écrit :
Hi Vincent
Ok, so I will go ahead and update the Feed Plugin to make it work for the Blog from 1.9 (with Wiki 1.0) as well as the one with Wiki 2.0. This means it will no longer work with a blog based on XWiki.ArticleClass (version ?).
You can go ahead.. The FeedPlugin has not been used for Feed output for now. The only part that we need to be very carefull with is the Feed acquisition (reading feeds from the network)
I would also to add this methods to the API: - String createFeedOutput(SyncdFeed feed, String type): this would enable anyone to convert a feed into an output format without having to overload so many methods
How is that different from /** * Converts a feed into its string representation using the specified syntax * * @param feed any type of feed, implementing the {@link SyndFeed} interface * @param type the feed type (syntax) to use, <b>null</b> if none. It can be any version of RSS or Atom. Some * possible values are "rss_1.0", "rss_2.0" and "atom_1.0" * @return the string representation of the given feed using the syntax associated with the specified feed type */ public String getFeedOutput(SyndFeed feed, String type) { return plugin.getFeedOutput(feed, type, getXWikiContext()); }
I hope that I have this done by tomorrow and will attach a patch to a JIRA report I am going to create (none of the open JIRA report matches this issue). This should finally make the Blog Upgrade complete, I hope. BTW I am going to upgrade my server to 2.0m3 when I become available and will test as far as I can. In case something goes wrong I will revert back to 1.9.2 but I hope I don't have to do it.
On another little note I was wondering what should I do with the Panels? - Are the left on Wiki 1.0 code? - Is there a Base Panel which is in Wiki 2.0 (Panel.PanelSheet) - if not do we want to create a Wiki 2.0 based Panel Sheet? The reason why I am asking is that I saw Jetty run out of memory or stack space having a Blog Panel in Wiki 2.0 using Panel.PanelSheet. I am not sure what is the reason but when I reverted the panels back to 1.0 the problems went away.
This probably requires some work and strategy from the core team to move the Panels to full 2.0 syntax and as well support compatibility with old panels.. But at one point a new default Wiki should definitively be full 2.0 syntax.
FINALLY is the idea, after the blog 2.0 upgrade, to create a Blog Plugin that would provide the code for a Blog inside Java? Or is that a Macro or Extension?
Having a blog plugin to move some code to Java would definitively make sense. This plugin could also provide Blog Post APIs and Blog posting by email. Ludovic
Cheers - Andy
On Aug 11, 2009, at 1:02 AM, Vincent Massol wrote:
On Aug 11, 2009, at 5:15 AM, Andreas Schaefer wrote:
Hi
I know that we all volunteer for this project and so this is not a critic of anybody's work but I have to say that the Feed Plugin has more holes than a Swiss cheese and I should know. I could work around all the issues but now the SyndEntryDocumentSource class does not render Wiki 2.0 code (hard coded to 1.0).
There is also an issue where the conversion of Categories fails in the Rome Converters because the Categories is a String but the Rome expects a SyncdCategory. The only conversion that works so far is atom_0.3.
One of the problems I see with the Feed Plugin is that the test suite is not sufficient and therefore many of the method now fail in 2.0. I would volunteer to help to build it if someone could show me to how to setup a test environment where I could execute the Feed Plugin against (Blog first). Is there a plugin that tests against a mock up XWiki to make sure it is working?
Yes, the feed plugin was written pre-new architecture (component-based with tests)... It'll need to be redesigned/rewritten at some points to align it. This rewrite is not planned by any current committer so this will take a while (unless someone volunteers to do it) so I think it's safe to fix it here and there if needed for the moment.
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Mon, Aug 10, 2009 at 8:15 PM, Andreas Schaefer <[email protected]> wrote:
I know that we all volunteer for this project and so this is not a critic of anybody's work but I have to say that the Feed Plugin has more holes than a Swiss cheese and I should know. I could work around all the issues but now the SyndEntryDocumentSource class does not render Wiki 2.0 code (hard coded to 1.0).
I often wonder why I've used the feed plugin at all when it seems like I can retrieve the information I need to retrieve, and do any of the conditional processing I might need to do in groovy rather than velocity. It's very simple, maintainable, perspicuous, and concise: {{groovy}} def rss = new XmlSlurper().parseText(" http://weather.yahooapis.com/forecastrss?p=92625".toURL().text) println rss.channel.title println "Sunrise: ${rss.channel.astronomy.@sunrise}" println "Sunset: ${rss.channel.astronomy.@sunset}" println "Currently:" println "\t" + rss.channel.item.condition.@date println "\t" + rss.channel.item.condition.@temp println "\t" + rss.channel.item.condition.@text {{/groovy}} It seems like the current FeedPlugin contains a lot of stuff that has very little to do with feeds, and more to do with creating documents from feed contents (e.g. SyndEntryDocumentSource). That seems to be a separate, and very application-specific (xwikiwatch?) part of the feed plugin. I'm also unclear on why these separate, "fundamental 2.0 webapp components" are mixed together, rather than separate, composable components. The groovy-model, perhaps because of its real type system and 1-to-1 correspondence with Java Pojo's seems more suitable to better decomposition. For example lets say that instead of turning a feed entry into an Xwiki document, you could also just download it and add it as an attachment, and then render it in the main document out of the attachment. For example something like this http://code.xwiki.org/xwiki/bin/view/Snippets/DisplayFormatedCodeAttachments... could render a document retrieved via WWW and added as attachment with the following code: {{groovy}} try { URL file = new URL(" http://github.com/mmcgrana/clj-garden/blob/bca0530e5578e5a0e011550e8b83ce659... ") // 1. get the file via a HTTP connection def connection = file.openConnection(); def text = connection.content.text // 2. attach it and save the desired document def targetDoc = xwiki.getDocument("Groovy.GroovyTest4") targetDoc.addAttachment("clj_rome_parser", text.bytes); targetDoc.save() } catch (Exception e) { println( e.message ) } {{/groovy}} As part of 2.0, now that Xwiki has solid support for a real scripting language and JSR223, the ability to use Xwiki "library" functionality as easily separable components would be a big improvement; the useful functionality provided by the FeedPlugin should be refactored into separable components and not be as "monolithic" and app-specific.For example, http://github.com/mmcgrana/clj-garden/blob/bca0530e5578e5a0e011550e8b83ce659... demonstrates this more component-oriented access to underlying Rome library java functionality, facilitated by a high-level scripting language like Clojure. Once a proper base of these separable, composable components have been created as plugins, one should never have to write an application plugin in Java again... Just script it in a high-level language like groovy (and eventually clojure via JSR223). Niels http://nielsmayer.com
participants (4)
-
Andreas Schaefer -
Ludovic Dubost -
Niels Mayer -
Vincent Massol