[Dev] Upgrading Chandler

[John Anderson]

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.
>