Re[2]: [lmi] Product editor API

[Vadim Zeitlin]

On Tue, 18 Oct 2005 02:46:29 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2005-10-18 0:21 UTC, Vadim Zeitlin wrote:
GC> > 
GC> >  I'm designing the API of the MultiDimGrid class (suggestions for better
GC> > names would be gratefully accepted) which is going to be used in the
GC> > product editor window and I have a couple of questions:
GC> > 
GC> > 1. I suppose we're going to have an arbitrary number N of axis (i.e. not
GC> >    limited nor fixed) and each axis can take different number of values.
GC> 
GC> lmi needs some small number of axes. Small, but mutable, not fixed.

 I thought the axis would be fixed but could be disabled/hidden at the GUI
level. I thought that changing the "cardinality" of the data model on the
fly probably wouldn't be a good idea. But maybe we could swap just the data
part of the control (e.g. when another item is selected in the tree).

GC> Each axis can take on various values. The set of possible values for
GC> each axis is mutable.

 During run-time? I.e. is it possible for this set to change (because of a
program action, I realize that the user can't do it himself) while control
is being used?

GC> Yet it might be a very good idea to let the program itself set them
GC> dynamically upon initialization: then we could read axis values from a
GC> configuration file, and wouldn't need to hardcode them in the source.

 Sure.

GC> >    The only question is whether these values can always be handled as
GC> >    strings or is it important to keep type information for them, i.e.
GC> >    also handle integer (and maybe real/float?) values?
...
GC> Most axes are string-valued. Users would be baffled by integers: they'd
GC> struggle to remember whether 'Female' is 0, 1, or something else.

 Of course, we do need to have string values [too]. The question is whether
we want to have numeric values as well.

GC> But some axes are naturally integer, e.g., 'Duration'.

 Or "Age"... In fact this is why I initially thought about ints support:
using an array of ~100 strings instead of 16..160 (this should be enough
hopefully...) range doesn't seem very elegant.

GC> >    So should we handle integer axis specially or just treat everything as
GC> >    text?
GC> 
GC> I'd suggest keeping it simple, for now at least, and just using strings;
GC> though others on the list are welcome to jump in with different ideas.

 Ok, so I'll use just strings for the axis values.


GC> > 2. Along the same lines, what about the values in the grid? Here I suppose
GC> >    we do want to have integers and reals and also strings. Is there
GC> >    anything else?
...
GC> Upon reflection, though, I see that one might enter
GC>   3.14159.26535
GC> or
GC>   $1,234.56
GC> in a field that has to contain a valid floating-point value. Neither the
GC> control class nor the data class necessarily needs to enforce that, if
GC> they delegate validation to routines available elsewhere in lmi. However,
GC> the delegated-validation approach wouldn't work in wx unless wx has its
GC> own way of validating floating-point input, which I'm sure it does; and
GC> at any rate the control needs some way of knowing the type, so that it
GC> can call the right validator (for strings versus floating point, e.g.).

 Exactly.

GC> We don't need heterogeneous entities, like the integer twelve for males,
GC> the string "true" for females, and a boolean type for our third gender.
GC> All elements of any entity are of the same type.

 This is an important observation, thank you.

 To summarize the point (2): we'll allow all standard wxGrid types
(including strings, ints, doubles, bools) but disallow setting the type for
each cell individually, instead it will have to be selected for the entire
grid.


GC> > 3. I want to separate the data access from the GUI control
...
GC> The only interface lmi needs, aside from the GUI, is read_file() and
GC> write_file().

 Still, I think it would be unwise to directly read grid contents in
read_file() and directly put data in the grid in write_file(). IMO an
intermediate GUI-independent data structure providing an abstract interface
is still needed. I.e. instead of

                 +------+                            +------+
                 | File | <------------------------> | Grid |
                 +------+                            +------+

I'd rather have

            +------+               +-------+               +------+
            | File | <-----------> | Model | <-----------> | Grid |
            +------+               +-------+               +------+

where "Model" isolates the file routines from the GUI stuff.

GC> The goal is not to write a general-purpose database that can serve data
GC> to lmi.

 No, I understand this. I just propose to isolate the GUI code from this
database, whatever it is. I think it would facilitate its maintenance
because it would make it easier to test and to change.

 Regards,
VZ