On Mon, Aug 10, 2009 at 8:15 PM, Andreas Schaefer <schaefera(a)me.com> wrote: 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/DisplayFormatedCodeAttachment… 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/bca0530e5578e5a0e011550e8b83ce65… ") // 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/bca0530e5578e5a0e011550e8b83ce65… 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