At 06:25 PM 9/5/2007 -0700, D John Anderson wrote:
On Sep 5, 2007, at 5:03 PM, Grant Baillie wrote:
On 5 Sep, 2007, at 14:47, D John Anderson wrote:
On Sep 5, 2007, at 2:05 PM, Katie Capps Parlante wrote:
- Perhaps we shouldn't be storing UI items in the repository. Yes,
transparently persisting UI state is in theory a cool property,
but in
practice I don't know that we are effectively getting the
persistence
right and it perhaps comes at too great a cost.
Are you proposing that we don't use transparent persistence for
storing blocks and other associated UI data structures?
Yes, that is the suggestion/proposal.
It seems to me that the transparent persistence isn't a problem but a
feature because it makes the code so much easier to write and much
less error prone.
Having worked on lots of projects that required I do a SQL queries
every time I need to access some data convince me that it slows
progress. I suspect a better solution would be to keep a mostly
transparent persistence model but change the data storage and/or data
structure underneath it to avoid requiring the programmer to manage
the data access manually.
Right, we need to distinguish between access transparency and schema
transparency. Access transparency is a good thing.
On the other hand, it's pretty well established at this point that
schema transparency tends to run counter to our goals at certain
points; we use EIM for sharing and dump/reload specifically to
*break* schema transparency, because it's better for us to have an
explicit delineation between internal objects and external schemas.
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.
This is of course all hypothetical, depending on the overall
direction taken. But basically, if we're going to refactor the
desktop architecture, we want to increase the independence of the
visual UI from the application logic, and the application logic from
the persistence mechanism. In terms of access transparency, we
actually want *more* transparency than we currently have. Ideally,
it should be possible to completely test the application logic
without there being *any* persistence dependency OR wx
dependency... which incidentally means that you should also be able
to start and test Chandler's visual components without needing a
repository, or the application logic, for that matter, as well as the reverse.
In addition to making things easier for everybody to test, this will
also reduce the amount of bottlenecking/roadblocking we have in
trying to fix bugs and deliver features, because people doing app
logic won't have to wait for persistence or UI, and vice-versa. With
the appropriate event-management glue, it should be possible for
application logic and views to be developed in parallel.
These types of separation and improved testing are all things that I
think we've wanted to have for a long time, but they aren't going to
happen unless we make them a priority and budget the time for them.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
