Re: Forms definition features request

[Jason Cater]

Robert, 

Thanks for the many suggestions. That's a lot of information to absorb
at once. 

One thing I'ke like to point out is our underlying philosophy for GNUe
Forms: We are not a widget set and we don't target certain display
interfaces. While not all of the requirements listed below are outside
of that philosophy, several are. Properly designed forms should be
equally runnable and functional on a variety of interfaces: 

  * Hi-Res GUI (Windows, Mac, GTK, QT, OS/2)
  * Text-only (Curses)
  * Low-Res GUIs (PDAs)
  * Telephone-feedback system (via Bayonne)
  * HTML (Raw HTML, XUL, etc)

Obviously we don't have a good chunk of these done, but you get the
point. 

Also, I wonder if you've taken a look at our triggers. Several of the
things you mention can in fact be accomplished via triggers. 

More specific comments inline... 

> 1: Facility for accurate positioning of elements on a graphical form.
> i.e. In the form definition, add something like 'x-scale' and
> 'y-scale' to define the minimum screen resolution required for the
> form. All coordinates & sizes of elements would then be scaled from
> these values.
> If these default to 80 x 24 when not explicitly given, then present
> form definitions should work with existing character coordinates.
> 
> (Would'nt is be advisable to change over to higher resolution
> 'graphics friendly' coordinates as soon as possible? Surely it's going
> to be easier than converting more complex code in the future?)

I think this goes against our goal of interface-independence.  You are
then writing your code to graphics interfaces. This is a direction we
don't want to go in. 

However, we do plan to move to a pluggable "layout management" style in
the near future. This will allow people to use various Layout Managers
besides our "Character-based" default.  One such style will be, I'm
sure, an absolute positioning system as you describe. 

For now, though, x,y coordinates solve 99.999% of our immediate needs. 

> 2: Block definitions; add capability for subforms / tables (so the
> whole block can be repeated as either multiple forms or a table).
> Change from 'rows' to minrows & maxrows to set limits for
> variable-size subforms??

This is interesting. I have thought about subforms in the past. My
knee-jerk reaction is this would be really nice to have.  But the more I
think about it, the more I'm not sure of its necessity. We currently
have importable libraries which solve the same problems. You can
actually import blocks, datasources, pages, etc from other forms. 

> Add 'scroll' boolean to give scrollbar if there is more data to
> display than '(max)rows'.
> 
> Add 'suppress-labels' (after first row) option. A subform could be
> defined as repeated, complete form, where both labels and entries are
> duplicated, or as a single row of elements with labels above it, which
> gives a 'columns with headings' effect when displayed with labels
> suppressed (and rowspace set correctly).
> 
> Add x / y / height / width so a block can be accurately positioned
> within the form or page.

I imagine this would not be a <block>, but instead an <import-form>. 

> 
> Add 'frame' or 'border' boolean to allow display of a box around the
> block.

This gets UI specific. 

> Add 'label' value to display text inset in the frame. Alternatively to
> these two, use 'box' to give visual, as opposed to logical, grouping.

We actually have an outstanding patch that makes <box> a container, with
relative x and y coordinates. It would have been in the 0.4.0 release
except that I had a few stability issues at the last minute and
commented out the code.

> Add 'line' or 'divider' to display a horizontal seperator.
> 
> Make all coordinates relative to the 'parent' form / page / block etc.
> Elements in a block really need the position & size to be referenced
> to the parent object, rather than the form size. Absolute values can
> easily be calculated at run time, but for a complex or multipage form,
> it's a lot easier to read the definitions relative to the current
> block or page rather than the start of the form. (Possibly only when
> form x-scale is
> >120 or 'requiregui' is set etc., so it works just for
> graphics-mode-only forms). It would also make life a LOT simpler in
> cases where multi page forms are displayed by page swapping rather
> than scrolling.
> 

I'm not entirely sure what you mean here.  We do have notebook-style
pages currently, which sounds like your page-swapping. 

> Add foreground & background colour parameters to all displayable
> elements. (I know it's rather low priority...)

This one I'm not so sure about... my knee-jerk reaction is that it's
GUI-specific once again. 

> 3: 'Entry' changes / additions:
> Change max-length to allow (e.g) 5.2 format for numeric values.

We have input masks that accomplish this, as well as much more complex
requirements.  Expect these to be stable within 1-2 releases.  

> Case / typecase / style - these overlap and seem redundant. If 'style'
> had options such as
> Label, text, upper, lower, alpha, date, time, choice (or dropdown),
> boolean, y/n, checkbox etc.
> then case and typecase are not needed.

I certainly don't follow this. Let me explain the 3 attributes: 

case: This can be "upper", "lower", or "mixed". This is actually a
lazy-man's input mask.  I expect case to be deprecated at some point.
This only affects text entries. 

typecast: This defines whether the entry is text, numeric, or datetime.
This is directly related to the underlying database field... if your
database field is a number, then this needs to be "numeric." This has
nothing to do with input validation or masking, even though it may
implicitly create such rules. 

style: Style is strictly a suggestion to the UI Driver of how to handle
the display of this field... should it be a regular text field,
checkbox, combo box, etc. This can't be combined with the others simply
because it is a suggestion.  If an underlying UI doesn't have, say, a
combo box, then this attribute would simply be ignored, but the form
would still function perfectly.  See the Forms Tech Ref for a better
explanation of why we choose this route. 

> Add 'minval' & 'maxval' for setting limits on numeric values

This is certainly a possibility.  Do note that this can currently be
handled via triggers. 

> Add means to explicitly define a virtual field (i.e. for calculated
> values or data derived from a relationship that is not to be stored).
> Possibly just reserve 'virtual' as the 'field' name?

The "field" attribute is completely optional.  If omitted, the entry
then becomes a virtual one.  This field can be populated via triggers.
Or, triggers on this virtual field can populate hidden, bound fields. 

> Add 'derivation' option to give source "formula" for data to be
> displayed in virtual fields?
One word: Triggers. 

> Possibly add a 'group' parameter to elements? So all elements with a
> specific 'group number' are are updated when any other element in that
> group is changed, for example to update a virtual 'tax' field on a
> price entry.

Triggers (cf., Post-Change)

>  - What I'm thinking of is something understandable to Joe User.
> Numbered groups and basic spreadsheet style derivation formulas are a
> crude way of automating updates, but the majority of users will
> understand the concepts and be able to create simple apps, where few
> will understand trigger scripts written in python, regardless of how
> essential these are for serious application. 

I'm not quite sure how to respond to this. As far as form creation goes,
we are targeting Joe Developer, not Joe User. However, GNUe Designer
automates A LOT and can even automatically create certain types of
triggers on the fly. 

> 4: 'label' does not have a 'height' parameter, this would be needed
> for scaleable graphic display.
>  - I notice 'label' is mentioned as an option for 'style' in the
>  'entry'
> section of the docs - is 'label' going to be redundant as a separate
> entity?

Not really. A <label> is static text to be displayed. An <entry
style="label"> is an entry that is bound to a database field, but is
displayed like a label (i.e., non-navigable, read-only.) From a
designer's standpoint, the difference is quite large... from a user's
standpoint, not so large.  However, the developer is the only one that
will see the GFD internals. 

> 5: Both entry and label need view / edit security control. For many
> business apps, different users need different access to certain
> elements of a standard form.

I agree.  We are still working on our RBAC (role-based) integration. I'm
not sure what approach we will take. 

> If 'hidden' and 'readonly' could have a numeric setting (as well as
> just true/false), this would make element-specific security simple -
> only display the element (or label) if it's 'hidden' parameter is >=
> the security level and likewise for 'readonly' to control editing. 1 =
> enabled at lowest level, higher values = higher security (up to, say,
> 9 for highest level.)
> 
> The labels need the same facility as it's a bit obvious to users that
> data is being hidden if it's label is still visible!
> 
> If the default security level is '1' and true equates to 0 / false
> equates to 1, existing code would still work.
> 
> 
> 
> P.s. Please keep the docs on the web site more up to date - for
> example the 'forms' tech refs are many versions older that the ones in
> the source packages and anyone downloading those old docs to get an
> overview of GNUe will get a very in-accuarate impression.

Duly noted.  We are working on a much-improved developer's corner.
Hopefully, this will help. Documentation is a touchy subject in
GNUe-land :)

I hope my comments aren't discouraging in any way. We do welcome and
encourage feedback. However, I just wanted to further explain our
philosophy. 

-- Jason