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. _______________________________________________ Setools mailing list [email protected] http://lists.squeakfoundation.org/mailman/listinfo/setools
