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