I think we're misunderstanding each other at a very basic level.
Phillip J. Eby wrote:
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.
I still think that there is some confusion here. I don't see why you'd
want to make a "tree of blocks" a new kind of block. That seems like
mixing apples and oranges. Trees of blocks make a corresponding tree of
widgets when they are visible on the screen, and the persistent
attributes of the widget is all a block really is. Widget properties
don't persist, and tend to be framework specfic, so we try to map them
to block attributes in a way that makes them less framework specific.
Upgrading the UI seems like exactly the same problem as updating content
items. In general it's hard, and since it's not that important, why
bother doing it? Copying templates seems unrelated to widgets,
pluggablity, upgrading UI -- it's no different from having a blank email
account containing default values, which you copy, then make a few
changes as necesary whenever you add a new account.
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.
Sometimes you need new spreadsheets, sometimes you need new formulas,
both make sense. CPIA is the same, sometime you need a new tree of
blocks, sometimes you need to change the attribute on the block that
controls the display, or the data that is displayed. CPIA's strength is
that it can build a whole bunch of different UIs out of different trees
of blocks and the attributes on them. Doing this without writing new
code, or definining new kinds of blocks makes contstructing/changing the
UI simpler. Of course that doesn't preclude new kinds of blocks, it's
just a more difficult task.
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.
I don't think it makes sense for a kind to "create a tree of blocks"
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.
The position of a scrollbar should persist and isn't user-configurable.
The selection, and sort of a table on a collection also needs to persist
and is on a collection displayed in a block
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.
I think you might be confusing UI widgets and blocks. Having a way to
persist the state of UI is what blocks do. Building them out of items is
simpler than building a whole new/different mechanism that does what
items already do well.
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
