Jeffrey,
After reading the latest version of the spec (by section):
User Interface / Interactions:
- Are you providing the API to determine which "occurs" choice should be
selected, or am I supposed to figure that out? Likewise, are you
providing the custom string for recurrences that don't map to ours?
- How is the "never" case presented and implemented for the recurrence
"ends" field?
Modifications in the detail view:
- It seems wrong that only the calendar related fields cause the dialog;
any change to any attribute of the item, whether calendar-related or
not, should cause the alert and trigger the resulting exceptional
processing.
- (I don't know the answers to any of the "Issue: [Jeffrey]" questions
you ask in this section, but I think the answers need to be worked out!)
Unstamping a recurring event:
- Presumably, unstamping a recurring event will forget about all
recurrence, so the choices in the dialog shown aren't appropriate.
(Actually, I think "change/remove/delete" is bad: the message and
buttons presented should always be operation-specific.)
Stamping a recurring event:
- The use cases listed are presented without comment, but none of them
are supported use cases in 0.6 (actually, AFAIK, it'll be possible to
email any email item once. If you send an email-calendar item before
adding recurrence, all the recurrences appear as sent emails;
presumably, if you send a recurring email-calendar item, either it gets
sent once, or each send implies creation of an exception. I don't know
how this is expected to work.
Architecture / Overview / Changing Events:
- Who's the "controller" in this story? who's implementing it?
- What's "editsAreUnsafe"?
- It looks like not only UI code, but any modification to ContentItem
attributes must go through this mechanism, right?
- I don't know what this means: "Modifications will by default apply to
THIS if currentlyModifying is None, but such changes result in warnings
being logged." What log? What for?
(I've just gotten to the Modification Logic section; I probably won't do
more reading on this today, and I'm out tomorrow, but I'll finish on
Thursday.)
...Bryan
Jeffrey Harris wrote:
Hi Folks,
The Recurrence spec
(http://viewcvs.o11n.org/docs/trunk/docs/specs/rel0_6/Reccurence-0.6.html)
is pretty much done, unless folks on the dev list have more they'd like
to say about it. I'm going to start implementing the spec very soon.
Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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