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

[Foster T. B. <fbr...@ad...>]

Eric,

On Oct 17, 2006, at 5:44p, Eric Berdahl wrote:

>
> On Oct 17, 2006, at 5:38 PM, Foster T. Brereton wrote:
>
>> Hi Eric,
>>
>> On Oct 17, 2006, at 5:00p, Eric Berdahl wrote:
>>
>>> [snip]
>>>
>>> Other scenarios are similarly easy to describe where the view may =20=

>>> wish/need to display "as much useful information as can be =20
>>> inferred from the input" while also providing feedback that "the =20
>>> input cannot be accurately represented in this view".
>>
>> I think this makes a ton of sense. In all the cases I had =20
>> considered, there was no way the widget would be able to display =20
>> something reasonable with the invalid data. Your example of a =20
>> graph-like widget made a lot of sense, as well as the notion of =20
>> extracting as much worthwhile information as possible and putting =20
>> it up for display. So, in light of that, I'd propose add a view =20
>> concept API to something like:
>>
>> 	void singleton(const model_type& value);
>>
>> We might also want to have a nullary singleton function for the =20
>> case when the widget is asked to display something it can't =20
>> decipher. For example, an edit text field being asked to display =20
>> an icon:
>>
>> 	void singleton();
>>
>> Thoughts?
>
> My only thought now is that the name "singleton" may be misleading =20
> because, as I understand your proposed usage (apply sanity checks =20
> as appropriate), there may be multiple objects in existence at any =20
> point in time, each one providing the "display model" for a given =20
> view. Thus, there is no "singleton" (as described by the classic =20
> use of the design pattern) in the system.

Ah, I think we've found a problem in our thinking. The problem is =20
that the model is not aware what a view's display capabilities are. =20
It simply pipes information to the view. The only case when the first =20=

'singleton' call is ever invoked, then, is when you're inside the =20
view itself (because only the view knows if it itself can display a =20
value it receives), and so should not be a requirement on the view =20
concept. The former 'singleton' call, instead, should just be the =20
view's display().

The second API call should be invoked by the model, however, and is =20
indeed the only place where the call can take place. The model has =20
square data that it's trying to hammer into a round hole, and cannot, =20=

so should notify the view accordingly. Since there is no legitimate =20
conversion from the data type present in the model to the type =20
expected through the view's display() call, the only option is the =20
nullary 'singleton' function. Thus, I think the name of the API in =20
the latter case is still appropriate.

> The term "display model" here being one I'm inventing to =20
> differentiate the model used to actually render the view from that =20
> which is manipulated by the user and may more accurately called the =20=

> "data model". Following this terminology, a "data model" is =20
> transformed into a "display model" when the view needs to create =20
> its presentation. When the data model is "sensible", the display =20
> model may, in fact, be a copy-on-write or other direct reference to =20=

> the data model itself. However, the display model is essentially =20
> read-only. Any interaction with the widget causes changes to the =20
> data model only.

Yes; in the View and Controller concepts we claim that neither a View =20=

nor a Controller necessarily hold any state at all, and so is not a =20
requirement on the concepts. (An example of a stateless view might be =20=

the screen of your television; an example of a stateless controller =20
would be a microphone.) However, in the world of UI widget =20
implementations this is not the case -- they hold state (often lots =20
of it) so they can successfully model the view and controller =20
concepts. Nevertheless, the widget types that model these concepts =20
should 'behave' as if they hold no state at all. (I would imagine =20
this is akin to using an adobe::dictionary_t as a regular type even =20
though under the hood it is ref-counted; it 'behaves' like a regular =20
type so we really don't care what the implementation actually is.) =20
Your "data model" we call the "property model", and is the Adam sheet =20=

in our implementations. All that to say there is a lot of parallel =20
between your last comment and the property model/widget system we =20
have in place within ASL.

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