I've been over the dashboard spec again, and made this list of what I
think are the requirements that affect the domain model. I don't have
proposals for resolving these - I'm sending these to the list so that
the services folk can start mulling them over.
Also, I made a quick list of tasks represented by requirements the spec
here:
<http://wiki.osafoundation.org/bin/view/Journal/DashboardTasks20060629>.
It's not prioritized or organized or prioritized yet, and some of the
notes have questions that I'm still working on answering. I'll be going
over it in more detail, and figuring out dependencies, but the biggest
dependencies are the domain-model issues, so I wanted to get the first
discussion going.
...Bryan
-- Domain Model Issues --
Sorting
- New indexes, or indexing changes, to represent complex sort orderings
like sectioned-triage (which has different sorts for sections, at least
one of which is spec'd to order differently forwards and backwards) and
the who/date/comm/reminder columns (which depend on presence/absence of
many kind-specific attributes)
- Do we need specific Calculated methods for index-dependent dynamic
values? (Does Calculated need to move to Schema for this?)
- For later: how to model manually-set ordering in the table (when the
user manually reprioritizes items by dragging them within a summary view)
Ticklers
- Are they just a special type of (or the same as) existing Reminder
objects?
- How to represent ticklers relative to event start time (when start
time changes)? Do we convert to an absolute date upon set? Timezone
interactions?
- How to represent ticklers relative to current time? Do we convert to
an absolute date upon set?
- How to model ticklers with no date set (eg, when user removes the
date from the Date column of a non-event with a tickler)
- How to model ticklers which persist after firing (do we need a
"fired" boolean, to avoid re-finding fired ticklers?)
- How to model ticklers vs recurrence?
How to represent triage status
- How to represent pending-but-not-Purged triage status?
- How to represent last time Triage changed (needed for sorting)
- How to set automatically triage status to NOW when a tickler time
arrives
- How to set automatically triage status to NOW when a start datetime
arrives (should all events have a hidden tickler for this?)
Sections (these are more CPIAish)
- Where to persist open/closed state of sections in a general way
- What's the architectural connection between columns and sectioning?
(Right now, columns specify an attribute name, and the attribute name is
used for indexing and sectioning)
General domain issues
- Are we sticking with attribute redirection as it is? This impacts
how the complex decisions about what to show in Who & Date work, and
hence how sorting works. (Bug 2167)
- How to represent (and what mechanisms will update) First-time
Communication, Update, Created, Edited, Draft, Queued, Sent, Error (and
in future, Forwarded, Replied To)
- How to update LastModified (same as Edited?) time?
- Need to represent Read/Unread state; by what mechanism should it
change? (nb, "clicking on an unread row also marks the item as read")
- Need to represent Needs Reply - is this just a boolean field that
defaults to False, is settable by the user clicking on the comm cell,
and is cleared on Send?
- How to represent In versus Out versus Neither
- Who/Date column labeling specifies displaying selected attribute of
most-recently-selected item if more than one is selected. How should we
model and persist selection order in table views?
- How to model calendar events with no date set (eg, when user removes
the date from the Date column of an event with no tickler): do we make
startTime optional? There's also a future requirement to store
'gobbledygook' in the start time field, though I don't know what this
means for sorting, attribute-editor picking, etc.
- For future, displaying items more than once in the summary would
preclude assuming one collection member == one row; do we need a
different model for this?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
