At 02:04 PM 10/12/2005 -0700, John Anderson wrote:
Phillip J. Eby wrote:
At 12:06 PM 10/12/2005 -0700, Bryan Stearns wrote:
- Take advantage of John's suggestion to have the upgrade mechanism be
cognizant of our ability to discard and reload UI blocks completely;
only worry about upgrading content item schema and instances, and
preference/account settings.
As it happens, I didn't even get into this subject at all, so your
suggestion also doesn't reduce any of the complexity in the issue I did
write about. UI evolution in the presence of user preferences is an
entirely separate problem, caused by the conflation in CPIA between
what's effectively "code" (or template) and what's effectively "data" (or
parameters), placing them in the same item instead of different
items. (The need to have any block copying in the first place, is also a
symptom of this confusion.)
I either don't understand or don't agree. Trees of blocks are only
parameters (not code, or preferences) -- ignoring the fact that a block
belongs to a class that has methods. The fact that we make a copy of a
template, just means we need a new set of parameters for a new situation,
since we can't know all the situations when the repository is built.
My point is that - at least as I understand it - CPIA doesn't allow you to
encapsulate a tree of blocks as a *new kind of block*, or to treat them as
a template for a tree of widgets, or allow treating widget properties as
pluggable items, or any other composability mechanism that would make UI
upgrades relatively simple, and not require any copying.
Many people who use Excel will copy a spreadsheet and change the numbers,
then use their desk calculator to fill in the totals. That's what we're
doing today with CPIA, at least as I understand it, because CPIA doesn't
let you create the equivalent of "formulas". We can't turn a tree of
blocks into a new class of block, we still have to create the individual
blocks. If you could do that, there would be no need to copy anything, and
the UI upgrade problem would then be identical to all other schema upgrade
problems.
Now, I understand you *could* implement a new kind that creates its own
tree of blocks, but you would also need to implement onValueChanged hooks
to propagate parameter changes, and there would still be distinct upgrade
issues, in that you're still creating blocks for every instance. The
fundamental problem, then, is that Blocks really "want" to be templates for
widgets, not things that you have an instance of for every widget.
The only things there should be instances of are user-configurable
components, that need an independent persistent state, such as the main
views themselves. But their persistent state should consist only of the
user's settings, not the independent state of an abritrary collection of
blocks, that may or may not be the same blocks when upgraded.
Meanwhile, the blocks defining the layout have no particular reason for
being persistent themselves, at least not until/unless we have a UI
builder. But even then, there's nothing that requires those objects to be
defined by the repository persistence scheme, vs. say a pickle in a blob in
the repository. And even then, there's nothing that says (architecturally)
that you have to have an instance of each one for every widget the block
defines, any more than you have to have a class for every object.
So, that is the template vs. parameter distinction I'm drawing. To my
present knowledge, CPIA doesn't currently make this distinction, so it
can't take advantage of any of the performance benefits, code
simplifications, or upgrade simplifications that it would allow. In 0.7,
therefore, I think it might be worth exploring some of the possible ways to
represent such a distinction, especially since it should also make it
easier for us to provide simpler components for common developer tasks like
creating a detail view for a new content type.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
