[Cuis-dev] The Preference model

[Mariano Montone]

I'm looking at Squeak model for preferences and they have something 
similar to what I suggest.

They have a 'type' instance variable in Preference, that they assign to 
a Symbol (I would use Smalltalk classes and objects instead).

And then, they have a hierarchy, but not for Preference or preference 
types, but for views.

And instead of a visitor, they use a registry, a mapping from preference 
type -> preference view class (PreferenceViewRegistry class).

Perhaps we can get some ideas from Squeak model.

Cheers,

Mariano

El 27/4/22 a las 14:36, Mariano Montone escribió:
> El 27/4/22 a las 13:56, Hilaire Fernandes via Cuis-dev escribió:
>>
>> Hi,
>>
>> I don't understand the PreferenceType interest, why not subclassing 
>> Preference for specific model and behavior.
>>
> Personally I like the idea of being able to augment current 
> preferences in Cuis with type information, without introducing new 
> classes.
>
> We could go ahead and annotate current preferences with 
> preferenceType: Boolean,Integer,Color etc.
>
>> The visitor pattern makes the understanding more complex (your code 
>> snipped really show it) and as I understand it (I never used that 
>> pattern), it is for situation where the model can't be modified. It 
>> is not the case here as we are just discussing on the most 
>> appropirate model
>>
> I think I would use a Visitor in the end in any case. Let's say you 
> subclass Preference class and create StringPreference class. How do 
> you decide what class of widget to use for editing it? You would 
> "hardcode" the widget class somewhere in StringPreference class?
>
> My preference is to use a Visitor (that's how it is done in my 
> packages; I have a PreferenceWidgetBuilder that given a preference 
> type builds a widget for it. ).
>
>> I am slightly concern it will be over engineered.
>>
> I understand. This is how I would do it, and see it as a price to pay 
> in order to prevent introducing new classes and for the possibility of 
> having separate widget building objects. But have no problem with 
> doing it in some other way if it is decided that this is unnecessarily 
> complex.
>
> Mariano
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220428/7a24815f/attachment.htm>