On Sep 5, 2007, at 6:53 PM, Phillip J. Eby wrote:
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.
The design we current have puts the persistent information in the
block and the display logic in the widget. Of course some people may
not have always followed that rule either because they didn't
understand it or because there are ambiguities.
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.
I'm concerned that a this could lead to a very large scale
refactoring project that might take time away from incorporating user
feedback to improve our design -- and put at risk our goal of getting
user adoption.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
