At 08:48 AM 9/6/2007 -0700, D John Anderson wrote:
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.
We're not quite on the same page here. I'm saying that blocks have a
significant amount of data (even in the Block base class) that should
not be persistent, either because it's constant, or because it deals
exclusively with visual presentation characteristics (like the
co-ordinate data in RectangularChild).
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
