Katie Capps Parlante wrote:
Would
you feel differently if the annotation and attribute had different
names that didn't imply "hint to layer above me", but made it clear
that the annotation belonged to the view layer?
Well, I do feel better about the ownership when its used in that way,
but my overall objection to this specific approach stands. pje's more
detailed list of issues (multiple "views" per kind, how to deal with
stamping, specialized views, etc) are more examples of issues that
developers will eventually need to deal with, and provide more
arguments against actually teaching new chandler developers this
pattern.
I think the detail view architecture really does handle this stuff very
well. In fact, as I iterate these issues, I'm realizing how well it
does address them and I feel even more confident that it is what we
should be teaching users.
Alec
class GenericViewAnnotations(schema.Annotation):
"""
Annotate the kind class with default detail view mapping,
used by the generic branch point.
"""
schema.kindInfo(annotates=schema.Kind)
defaultDetailView = schema.One(Block.Block)
or
class ScaryViewAnnotations(schema.Annotation):
"""
Annotate the kind class with a "scary" detail view mapping.
Some custom branch point will pick this view on halloween.
"""
schema.kindInfo(annotates=schema.Kind)
scaryDetailView = schema.One(Block.Block)
Can't we still think of the view code as annotating the model code and
owning that annotation, thereby not polluting the layers? Some view
parcel could provide only the annotation to some existing model, for
example.
I'm not necessarily arguing we should do this (especially not in 0.6),
but it doesn't seem fundamentally unclean to me.
Cheers,
Katie
Alec Flett wrote:
I personally I don't see annotations as an
excuse to start blurring different layers of the application, but I
obviously think it has its place. In the case of collections colors I
view that as a piece of code saying "I need to remember some of my own
proprietary information about this object" whereas I think the
ViewableKind thing is more the other way around - a kind saying "I'll
provide a hint to the layer above me, in case it needs it"
So annotating 'Kind' would make more sense if the detail view or trunk
parent block were attaching information to the kind like "Oh, next time
I display this kind, I'll need this information.." - but if it is used
that way, where does it get that information to begin with?
If anything its like the way 'color' is still an attribute of
AbstractCollection - its relying on some base type to provide an
attribute, and hoping there is some specialized use of the base case
that will make use of the attribute.
So I think it comes down to semantic ownership. Annotation is, for me,
for allowing the owner of some data to attach that data to something
else that it doesn't own. Like if you came to a party and I asked you
to wear a name tag calling you "Phillip with two L's" - that name has
little or no meaning for you, but I can use it to distinguish you from
related people I know like "Philippe with Two P's and an E"
I feel like the ViewableKind annotation is more like if you made and
wore your own name tag with a pronunciation guide in Cyrillic, assuming
that anyone who needs to pronounce your name will know Cyrillic.
Alec
My question is entirely independent of the
discussion at hand; I want to learn more about how people perceive the
annotations concept, whether they perceive it as good or bad. The fact
that you seem to see it as both simultaneously makes you an especially
good person for me to learn something interesting from. :)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
