Phillip J. Eby wrote:
In the context of the UI, the issue is more about separating those
characteristics of a UI component that should be persistent (such as
what item is selected or what collection is being displayed) from the
objects used to produce a visual representation of them. In other
words, some things that are part of blocks now could move to being
part of the widgets (or are already there), leaving behind only the
parts that truly need to be persistent. The remaining portions would
then also be directly scriptable for testing purposes in a headless
environment.
+1 on this and the rest of PJE's email (that I snipped for concision):
we should persist much less data and separate UI, application logic and
PIM data much more cleanly. This is not only good for all sorts of
engineering reasons (mentioned by PJE), but also to lower the barrier to
entry for new contributors, the current mix up being a real put off I
think (exhibit A: the difficulty our interns had to dive into the code).
As an example of how puzzling the model we have can be for someone
starting to dabble into the code, just try the following:
- create a note item in Chandler with a simple "Title" and a simple
"Text" in the note
- Press "F4" to browse this item
-> you get a 2 pages long list of data, most of it being block stuff
- Find one attribute starting with "Spacer" in the list and click on its
link
-> you're drowned into an even longer display of "stuff" that bear no
relationship whatsoever with what one can consider as user data
OK, not to say that all of this is unnecessary (and surely the browser
display is verbose) but, as a first time contributor, you can't help but
ask: "Are we really persisting all those data for a *spacer* in the
detail view? What does it has to do with my PIM data anyway? Can't that
object be created dynamically when needed?"
The point I'm trying to drive (may be clumsily) is that the current
philosophy that makes everything a persisted item, makes for a very
difficult to decipher (and maintain and test) structure.
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
