I don't see how it's better to put knowledge of proxies into attribute
editors instead of Table (since they're both at the same "level" of
chandlerness).
I agree with Alec that we'll need to put more Chandler-specific
knowledge at the root of the summary view very shortly for the
dashboard, if we're not there already because of this proxy issue.
Because of that, I don't think it makes sense to do a lot of
refactoring (pushing proxy knowledge into AEs) when we're going to have
a convenient Chandler-aware base for the summary view soon.
...Bryan
John Anderson wrote:
On first glance it seems like these features belong more to the
AttributeEditor, not the Table, if you want it to apply to any place
the calendar event mixin is edited.
Jeffrey Harris wrote:
Hi John,
I noticed that in revision 7115 you added RecurrenceDialog to Table. On
first glance it doesn't seem like all Tables should know anything about
recurrence since Tables are used in lots of situations besides the
summary view.
Are there situations where a Table is working with only items that can't
be edited, or only items which could not possibly have been stamped with
CalendarEventMixin? In those circumstances, I agree, a recurrence
dialog won't come into play. My guess was that those circumstances are
rare.
I have little attachment to where the recurrence proxies come into play.
The requirements, as I've understood them, are:
A) Use a proxy whenever a calendar event mixin might be edited
B) Never set a reference attribute's value to a proxy, as the repository
doesn't believe in proxies (the reverse is perfectly fine, however, as
proxies do believe in the repository), so if P is a proxy for A, B.a = P
is disallowed, but P.b = A is fine
C) Use the same proxy for items that are drawn as items that are edited,
so that edits are visible when the recurrence dialog pops up
There used to be a requirement D) that proxies persist between edits, so
that a series of attribute edits to the same item wouldn't pop up the
dialog over and over, but this turns out to have been a misunderstanding.
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
