Katie Capps Parlante wrote:
Alec, do you have objections to the mechanism beyond the issue of two different patterns? If so, can you elaborate?The mechanism, as it was described to me, allows you to annotate a 'kind' item with a reference to a particular block, allowing for a "ViewableKind". This means I can say, create an AmazonItem kind, and annotate it with a reference to an AmazonDetailView This seems incredibly broken to me: 1) establishing a link from the low level datamodel right up to the highlevel model for the UI. I think it breaks the whole model of the UI as one of many ways of viewing a set of data. The Kind should not decide which UI it will be displayed with and we should not encourage this notion. 2) It encourages siloing data - this specific type of item is displayed with this isolated block tree, and so forth. I think of these as being pre-chandler way of doing things - i.e. this is how you might do this in a more traditional application that doesn't allow such dynamic data typing as is available in Chandler. This is not to say that a little scaffolding isn't helpful for readers to understand what Chandler is all about, but why invent a new, legacy-like system, encourage users to use it, and then throw it all away after we've reinforced a pattern that we're trying to deviate from? Alec Cheers, |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
