[Dev] Upgrading Chandler

[Phillip J. Eby]

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.