gnue-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUe-dev] Re: Technote about new forms XML format


From: Reinhard Mueller
Subject: [GNUe-dev] Re: Technote about new forms XML format
Date: Wed, 29 Mar 2006 09:47:44 +0200

Hello, Jan!

Thanks for your feedback!

Am Mittwoch, den 29.03.2006, 08:37 +0200 schrieb Ischebeck, Jan:
> a) vbox, hbox:    
> 
> I would prefer to stay with the <box> element, which is already
> implemented and just add a "orientation" attribute  to differentiate
> between vertical and horizontal.

Is there any specific reason for this except for <box> already being
used (although for a slightly different thing)?

> You describe much extra functionality for the vbox -- 2 column table,
> labels left, entries right, ... -- 
> I understand that it makes form creation much easier.  But it should
> get a more explicit name, f.e. <table>

The approach with the boxes being really tables originates from the idea
that for a person designing a form, an entry and its label are really
one single control, not two distinct controls, just like the box of a
checkbox and its label are a single control. The fact that most user
interfaces implement it as two distinct controls should be hidden from
the user.

> A <table> would inherit a <box> and would order label / entry pairs
> horizontally or vertically.
> 
> hor:   Name  |   Address  |  Birthday  |   Birthplace
>       ____   |   ________ |  _______   |    ________

This would be standard behaviour of a <hbox>.

> vert:
> Name        : ______
> Address     : _______
> Birthday    : _______
> Birthplace  : _______

This would be standard behaviour of a <vbox>.

> It would also be possible to define the number of colums, to create
> f.e. two columns of label entry pairs.
> 
> Name      :  ______      Birthday   : _______
> Address   : _______      Birthplace : _______

<hbox>
  <vbox>
    <entry label="Name" field="fldName"/>
    <entry label="Address" field="fldAddress"/>
  </vbox>
  <vbox>
    <entry label="Birthday" field="fldBirthday"/>
    <entry label="Birthplace" field="fldBirthplace"/>
  </vbox>
</hbox>

> A problem for this <table> element or <vbox> as you called it, is how
> to order/arrange labels and entries in it.
> Currently we don't have a binding between entries and labels, so they
> have to be in the right order, like:
> Lbl 1, Lbl2, Lbl3, Ent1, Ent2, Ent3   or   Lbl1, Entr1,Lbl2, Entr2 but
> both options are not very stable.
> 
> I would propose to allow binding labels to entries by just making the
> label a child of the entry:
>    <entry name="...">
>         <label name="sdfsd"/>
>    </entry>

I would propose to make the label an attribute of the entry, as in the
example above. We also would need an attribute telling where the label
is (left of the entry, above the entry) and another attribute for the
alignment of the label (left, right, center).

> b) <grid>
> 
> I agree to remove the row and rowSpacer attributes. Instead elements
> like <grid>, <box>, <table> and even <page> should have a attribute
> called "scrollable" or "recordscroll" or "datascroll" or something
> else. If the attribute is true, multiple records should be displayed
> in this elements display area. For a <grid> this attribute would be
> true by default.
> The difference between a <grid> and a <table> would  be, that a grid
> looks more like a spreadsheet, while a  <table datascroll="Y"
> orientation="horizontal"> or a <box datascroll="Y"> would look more
> like a subform.

Can you give an example of where this would be useful?

> Concerning the connection between entries and labels in the grid, the
> same method as in the <table> should be used.

There is a conflict between having the label as a child of the column it
is displayed in and having the label as a child of the entry it belongs
to. It can only be one of them.

> c) Layout management
> 
> I would propose to use a layout management, based on the following
> concepts:
>       - anchors (element starts at  top/bottom, left/right)

I think having the anchors implicit by their placement within a <vbox>
or <hbox> is an intuitive solution.

>       - resizeable (horz, vert, minSize, maxSize)  <-- some properties
> would be 
>       - a span attribute (numerical value, which describes the ratio
> of space the object will get in relation to other objects, <a
> span=1><b span=2>   is the same as <a span=10><b span=20>) 

Yes. Most of these attributes will have usable defaults.

Thanks,
Reinhard

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil


reply via email to

[Prev in Thread] Current Thread [Next in Thread]