Alec Flett wrote:
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.
Actually, it's the summary view TrunkParentBlock's delegate that
decides which view to choose, not a block or a Kind. However, it seems
reasonable to me that a Kind could specify information about a prefered
viewer that the delegate could take advantage of. In the repository
viewer you should get a completely different view because the
TrunkParent block has a different delegate making the decision.
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,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
