[Setools] Settings and forms

[Igor Stasenko]

At current stage we have variable code which uses different approaches
and different messages to access settings and show UI for editing
them.

I really think that we need to develop a common way how to access
settings and how provide users a way to manage them.

Currently there are 3 use cases, where we need to access settings:
- .ini file settings
- global settings (aka model)
- process settings

For accessing .ini file settings i think we should use
'self session settings'
but Q2Object>>settings must not point to them by default, actually
this must be an abstract method, which defines a protocol.

For accessing global settings we must use
'self model settings' and for process - 'self process settings'.

I don't see a need in defining other messages, like #processSetting:
in Q2Object class, or #modelSettingAt: in Q2Model class.
Maybe, for cleaning out the code we may add
#processSettings and #modelSettings to Q2Object, which will return
corresponding: 'self model settings' and 'self process settings' ?
But such changes will require from us to return some object, known as
'settings' which will have some protocol (basically #at:, #at:put:).
Should we enforce such behavior? or maybe better define a protocol in
Q2Object, like:
#settingAt:, #settingAt:put: , so we will not need an intermediate
object(s) to access different settings?
But returning intermediate object haves own benefits - when we need to
show UI for editing settings, we can simply use something like:
self model settings getEditorComponent , which should return a ready
for use component for editing it.

Now, about providing UI for editing settings.
A Q2Object have a methods in category 'formvalue'
- #editForm
- #editFormBuffer
I think this is very good scheme which gives us ability to edit
contents of any Q2Object by sending #editForm message to it. But its
have own limitations - in some cases we need to build a multi-tab
forms containing multi-form value for showing settings UI.

Maybe we should, instead of asking form from object, ask for
component(s) which represent UI for editing its contents?
A Q2Object having an abstract method #addComponentsIn: , so what if we do:
self model settings addComponentsIn: ... for getting editor UI?
Then particular Q2Object can determine what component it needs to add
to given component to represent itself. It can check access and
provide viewer or editor component depends on access rights.
But in some cases, we need to tell that we need only view of object's
contents, so what if we define method like following:
Q2Object>>addComponentsIn: blabla
  ^ self addComponentsIn: blabla forEditing: true.

And now, #addComponentsIn:forEditing: can be implemented in subclasses.

Another problem, on which i want to pay your attention, is about
changing forms dynamically.
In current design, a form is build as something static and then based
on it we build a components which then live long and don't change even
if form changed.
I know, that this was done for speed reasons , to not create
components each time we need to render forms. But we need some
mechanisms to synch forms and their corresponding components, when
form was changed.
Actually even forms can be changed dynamically (for example - i need a
value for each stage name in color settings, and for this i need to
rebuild form each time a stage with new name appeared / removed).
Maybe we should add a 'dynamic field' class, a subclass of Q2Field,
which can be used for editing/showing contents of current state of
model?
Lets say, model is array of strings - and we need to show a list of
fields for editing each string, and then if something in model got
changed (new string added or removed) we need to show different list
of edit controls for it.
The best way i think is to let fields render themselves without
creating components. So, the only component will be a Q2FormComponent
, but fields will be rendered without creating components. This will
reduce the amount of complexity and will give us a way to make dynamic
forms which always will represent editor/viewer for model in current
state.
Actually , there already some misconcept: fields used
#addComponentsIn: to define components which represent for editing
values of target, but not field itself!
I added a #fillForm: method to make editor UI for field in forms
constructor, but i suspect that this should be #addComponentsIn: ,
since Q2Object states that this method must add editor/viewer or
receiver's contents.
Currently, im refactoring fields by adding accessors to them (instead
of selector ivar).
I think  we should change the protocols how fields should be rendered,
but i don't have a clear concept of it.
I added a field grouping and divider , which is a Q2Field subclasses ,
but they don't have any values to edit , they simply a UI decorations.
But to add this i was need to hack and write ugly code and i not very
satisfied with it :)


-- 
Best regards,
Igor Stasenko AKA sig.