I finally have ZaoBao^? working in some semi-usable format. I created two item collections which are just "all items of type RSSChannel/RSSItem" - so the RSSChannel view just shows the channel, and the RSSItem view shows a summary of all the items.

A big part of this work was hooking up to the detail view. This got a little tricky. The problem is that there are these generic item editors (in parcels/osaf/framework/detail/) and they do annoying things like put "untitled" in fields that you don't care about... Nobody seems to be using the attribute editor classes as they are, as they tend to derive from them so who knows what bugs I'm exposing.

Some issues I ran into today:

• redirectTo - this is used all over and I'm not really happy about it. basically in an Kind declaration you can say that certain attributes redirect to other attributes. I don't mind this in concept but it doesn't seem like something you should need to declare within the Kind itself. Instead, I feel like it should be some external binding. In ZaoBao^?, what this means is that I have to redirect stuff like "who" to "author" and such, polluting the definition of RSSItem and RSSChannel. Instead there should be some other method to bind this redirection, since usually these redirections are used in the summary view and the detail view to know which generic attributes to touch.
• the Title and NotesBody in the detail view. I wish there was an easier way to turn these off. Right now I want everything to display as static text since RSS stuff is read-only, but Title is an edit field. Same goes for NotesBody - RSS tends to put HTML there and I don't want to have to dump that into an edit field. the "contact" Kind solves this by hacking directly into the attribute editors and hiding things like "Title" when contacts are being displayed. yuck.
• The stuff in parcels/osaf/framework/detail/Detail.py needs to be refactored, and given better names. I like that many of them automatically sync with item attributes, but there is kind of a haphazard collection of classes, some of which are application specific (i.e. mail, calendar, etc) and some of which is fairly generic.
• Related to the previous item, I'm glad there are things like DetailSynchronizedLabeledTextAttributeBlock (wow, what a mouthful) but the semantics for using it are not well documented (I can fix that with some comments) and the method for hooking it up (sprinkling itsClass= all over) is somewhat clumsy. Many of these tags should have a default behavior. So instead of having to declare I should be able to say something like

Katie had the idea that we could put each RSSChannel as an item collection - not a bad idea.