Hi Katie:
I think Bryan's example is pretty close to a good example of adding an
Item to the detail view -- and quite similar to what I hoped to do for
that case. I think the only real issue here that remains is that I'd
like to introduce 3 key CPIA ideas, a Kind, an instance and a tree of
blocks in a context that is simpler than this detail view case -- and
hoped to do it in fewer lines of code. I don't have to do that in the
detail view and could do it in a different place, e.g. a developer only
"learning CPIA" skin. Neither Bryan nor Alec think that's a good idea --
and if I understand them correctly -- they think we shouldn't introduce
any CPIA concepts except as they relate to a particular part of
Chandler. I thought understanding basic CPIA concepts first would make
understanding them in Chandler easier.
Jon
Katie Capps Parlante wrote:
Arguments about proper uses of the annotation mechanism aside (more
later), I agree with Bryan that his example is reasonably simple. It
is arguably simpler than John's example because it uses the existing
HeadlineArea, instead of defining a new one. It also has the advantage
of using an api consistent with the other existing parcels.
Perhaps an MP3 isn't a great hello world example, as it doesn't add
any additional visible attributes with simple types. Or perhaps the
button counts, and use of the "about" attribute.
"DetailTrunkSubtree" is a mouthful, but of course we've already
discussed that (Bug 4281).
Cheers,
Katie
Bryan Stearns wrote:
But this is the central point of my objection, John: I believe this
is a bad example, because it doesn't help the developer learn a
couple of important concepts that they're sure to need to play in the
real Chandler world, and *aren't hard to explain*.
John Anderson wrote:
I think your example is similar to what I was proposing for my
future example explaining how to add an Item to the existhing detail
view. I think it introduces more than basic CPIA concepts not
appropriate for a trivial hello world example -- which I had hoped
would only introduce a new Kind, instance and a trivial tree of
blocks viewer for it:
#A new Kind
class MP3(Note):
audio = schema.One (schema.Lob)
#An instance
song = MP3.update(parcel, "French Rock",
about = "French Rock")
#A viewer
blocks.Trunk.ViewableKind(MP3.getKind(repositoryView)).detailView
= view
#blocks making up the view:
view = blocks.BoxContainer.update( .... )
attributeEditorBlock = blocks.ControlBlocks.AEBlock.update( .... )
button = blocks.ControlBlocks.Button.update( .... )
Bryan Stearns wrote:
I've attached a simpler version of the sample to the bug - no other
changes required, and it shows the normal way to add a detail view.
https://bugzilla.osafoundation.org/attachment.cgi?id=1259
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
