Re: [Adobe-source-devel] asl-users: View concept singleton state

[Sean P. <sp...@ad...>]

I think for the widget set this is a valid solution - and there are =20
similar cases:

* For a checkbox if the bound value doesn't match either the true or =20
false value you get the dash displayed.
* For a radio button if the bound value doesn't match the radio value =20=

then the radio button is off.

All three of these should be handled consistently - but I don't know =20
that we need, say, a state for an edit_text field if the bound item =20
doesn't contain text.

I have considered the similar case where a value is being display =20
which is poisoned (a value which is derived from a cell which =20
contributes to a false invariant).

For this case I've wanted to display a small caution icon to the left =20=

of the control - along with a message box (a caution icon and text =20
associated with the invariant) at the bottom - and dimming the okay =20
button. There is also a possibility to provide a button to restore to =20=

a good state. There are few dialogs, however, that require such =20
handling so this has been low on the priority list.

Sean

On Oct 17, 2006, at 4:31 PM, Foster T. Brereton wrote:

> Hey all,
>
> I wanted to email the group regarding something I'm implementing =20
> for the preset widget, because I think it can be lifted into the =20
> View Concept as a whole.
>
> A while back Mat and I were talking about the following problem: =20
> what is the proper behavior of a view when it is asked to display a =20=

> value it cannot display? As an example, let us say I have an =20
> 'analog clock' display and it is asked to show the time 25:75. What =20=

> should the clock do? To solve this, (thus far) we came up with the =20
> idea that every view should have a singleton state. The singleton =20
> state for a view is entirely implementation-specific; for instance =20
> in the clock example, the view could set itself to noon and make =20
> the clock have a red background -- something obvious to the user =20
> that says "I no longer accurately reflect the value in the model I =20
> have been asked to display". The instant the model communicates to =20
> the view a new value that it can display, the view should display =20
> the new value normally.
>
> The notion of a 'singleton value' does not exist, so the ability =20
> for the user to put a widget into the singleton state is =20
> prohibited. What would trigger the singleton value for a view =20
> usually takes the form of controller 'A' setting the value of a =20
> cell that view 'B' (also bound to the cell) cannot display. The =20
> value would be valid for A as a controller but not B as a view, so =20
> B reverts to the singleton state.
>
> Therefore, in the case when the view is also a controller (aka a =20
> widget), there is an additional requirement to be placed on the =20
> widget while in the singleton state. In addition to the above view =20
> requirement, the widget must also allow for valid user manipulation =20=

> of the controller while displaying the singleton state. In the =20
> clock example above, (should the clock view be part of a clock =20
> widget), the singleton state should allow for the user to set =20
> another (valid) time (for example, by dragging the hands of the =20
> clock with the mouse).
>
> As a more concrete example, I am reworking the ASL preset widget so =20=

> it models the View concept -- it is bound to a 'result' cell of the =20=

> property model. When the result cell is updated, the preset widget =20
> compares its list of available presets against the result cell -- =20
> when a preset is found whose contents are a subset of the result =20
> cell, that preset is selected. The singleton state, then, occurs =20
> when the result cell is in a state for which no preset exists. The =20
> display behavior I am implementing is to append a menu item named =20
> "Custom" to the preset category list. This will still let the user =20
> select a new preset category from the preset category list, but at =20
> the same time clearly tells the user "the dialog as it stands =20
> matches no presets."
>
> Thoughts?
>
> Blessings,
> Foster
>
>
> --
> Foster T. Brereton              <=E1=BC=B0=CF=87=CE=B8=CF=8D=CF=82><   =
           Romans =20
> 3:21-26
> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
> "What 99 percent of programmers need to know is not how to build =20
> components but how to use them." -- Alexander Stepanov
> "Now we have very simple code and the meaning is perfectly clear. =20
> Drink the Kool-Aid" -- Sean Parent
>