|
|
KNotations :: Documentation and development plans from the KnowNet development team
|
Weblog | 84 entries | 23-June-2006 | 1 authors |
|
|
Blog Entry | 1 reply | 20-June-2005 | Mike Malloch |
Last week we put together the beginnings of a Plone product geared to providing efficient but flexible aggregations of knotes posts and discussion for use in Plone site content. KNSin will be ready to use in some of our own sites within 2 weeks.
Knotes can deliver RSS and atom feeds quite flexibly and efficiently. This makes it easy for savvy readers to create aggregate feeds in their news readers which assemble content from knotes weblogs and disucssions in flexible and efficient ways. But a major use for aggregating discussion and weblog content is to use it within the same Plone sites in which the content 'lives'. A common motif in Plone sites not 'built with knotes' is to have the front of site aggregate some content sources, and a few other main site actions display other aggregations: news, events, etc. It is also common to include aggregate summaris in portlets. In our own sites, we have begun to do both of these things using knotes as the source and sql-tool queries instead of z-catalogue searches. This works fine except for two drawbacks:
KNSin addresses both of these problems: It has a simple lines-field property in which a skilled editor can define just about any possible combination of content sources, and it also allows the editor to define a cache-control expiry for the feed data. For instance, the following specification in the lines-field for a KNSin object asks for all the entries from 3 blogs dotted around the vetnet site, as well as entries from one category in a weblog on another site (the other site is in the same KNSQL database). See the attached screenshot as well
parentuid = 'vetnet/Members/pkamarainen/blog/entries'
Did we have other options? We had thought to address these issues with a pure RSS tool that would digest the XML from some feeds and produce python dictionaries from them for use in portal content. We had too much trouble parsing the XML though, and since XML parsing is expensive we asked ourselves 'why parse xml for data we already have in sql'? KNSin is meant to fill the niche where within-instance data need to be assembled in flexible ways, with rich information about the items for flexible displays (for instance, branching the display based on the dc:source of the items. We had also experimented with literally serving the unparsed RSS items but transforming them in the client and on the fly with XSLT. But this seemed a flakey an inaccessible solution for embedded content ( ie xml data ilands within xhtml content ). One of these days we will write a pure-RSS tool, like CMFSin, but for the time being KNSin is what we need. We'll be using an early version of KNSin to improve the front pages of the vetnet and NGRF sites quite soon. I'll be back with more news about this later. |
|
An example of KNSin in action is in my other weblog 'c-Learning' | Discussion Topic | 0 replies1 resource | 07-September-2005 | Mike Malloch |
I've just made a KNSin aggregator to provide a feed for all by blogging across the blogs and portals, and have this feed being sucked into my cLearning blog as a javascript include in my About content.
See the About sidebar in my non-techie blog, c-Learning, for an example of KNSin in action. I made a very simple KNSin aggregator to fetch my recent entries from across the blogs and portals I contribute to. I seldom get a chance to post in c-Learning and wanted visitors there to get some idea that I was still alive and writing :o) I adopted the convention in that blog of fetching profile-ish extra feeds into the About sidebar by javascript ( this allows mashing in my delicious and flickr zeitgeists, andalso saves pageload time ). We have not had much chance to do anything with KNSin - in fact this is the first in-anger use we've made of it. I hope to get some more features and uses out of it soon, especially for generating front-of-site content and cross-site default feeds. |