How to design a form to handle a many-to-many relationship

Hi all

I'm new to this group, but I would like to hear your opinion for
this...

We are building a web application, and I have to design a form to
handle
a many to many relationship between to entities.

Given that we are using quite a dynamic UI, I'm not forced to used
just selects
or tables; I have been thinking of drag and drops, but I'd prefer to
avoid that
if something with the same level of usability can be achieved through
standard
form elements, which people are used to.

How would you design such a form? Being able to maintain a glance over
the status of the relationships is a plus.

Thanks a lot for your feedback
cheers
Francesco

On Dec 12, 1:48 pm, drvillo <f.viv... (AT) gmail (DOT) com> wrote:

Hi all

I'm new to this group, but I would like to hear your opinion for
this...

We are building a web application, and I have to design a form to
handle
a many to many relationship between to entities.

Given that we are using quite a dynamic UI, I'm not forced to used
just selects
or tables; I have been thinking of drag and drops, but I'd prefer to
avoid that
if something with the same level of usability can be achieved through
standard
form elements, which people are used to.

How would you design such a form? Being able to maintain a glance over
the status of the relationships is a plus.

Thanks a lot for your feedback
cheers
Francesco

On Dec 12, 1:48 pm, drvillo <f.viv... (AT) gmail (DOT) com> wrote:

Hi all

I'm new to this group, but I would like to hear your opinion for
this...

We are building a web application, and I have to design a form to
handle
a many to many relationship between to entities.

Given that we are using quite a dynamic UI, I'm not forced to used
just selects
or tables; I have been thinking of drag and drops, but I'd prefer to
avoid that
if something with the same level of usability can be achieved through
standard
form elements, which people are used to.

How would you design such a form? Being able to maintain a glance over
the status of the relationships is a plus.

Thanks a lot for your feedback
cheers
Francesco

I think I know what you are talking about. For many-to-one GUI
insert/update
screens I've always used what I refer to as "array subscreens,"
where an array screen is any sub-block of input widgets that can
submit multiple values,
multiple times, to a single relationship.

For instance, if you want to allow researchers to attach N-complex
descriptions of their
publications to a single 'researcher' table, then you present array
screen one. After the user
fills out sub-screen one they then click 'next subscreen' and they see
the same screen again,
with blanked out values and an incremented index number. In an
application,
when they click "submit" all N-subscreens get processed at once, as N-
inserts or updates to the personnel table.

So, this is easy to do in an application, and damned tricky form a
post-submit html form.
In an html context you have to send a post for each switch to a new
"array subscreen"
and then repaint the browser, using various session variables to keep
track
on the server. Or you can use Ajax, sending multiple updates on the
fly.
Google's GWT libraries make updating the
server, without repainting the browser, a fairly painless process. But
GWT is java
programming (that gets translated into javascript, by the Google
compiler).

I see what you mean.
Actually I tihnk what you describe is most useful when the
relationship
has some attributes attached to it (in your example the descriptions).

In my case I have sites (aka datacenters) and business units: to
say that 5 business units are hosted into a datacenter is just to fill
a
map table.

I've made a simple wireframe, maybe clearer.

http://atalayasec.org/wiki/UiModelin...nits/AdminUnit

Do you see what I mean. Everything should be done in one page, and
I think it's possbile to do so (yes, we use asyncronous transfering
already,
even if not with GWT).

What do you think?
thanks a lot
cheers
F

I think I know what you are talking about. For many-to-one GUI
insert/update
screens I've always used what I refer to as "array subscreens,"
where an array screen is any sub-block of input widgets that can
submit multiple values,
multiple times, to a single relationship.

For instance, if you want to allow researchers to attach N-complex
descriptions of their
publications to a single 'researcher' table, then you present array
screen one. After the user
fills out sub-screen one they then click 'next subscreen' and they see
the same screen again,
with blanked out values and an incremented index number. In an
application,
when they click "submit" all N-subscreens get processed at once, as N-
inserts or updates to the personnel table.

So, this is easy to do in an application, and damned tricky form a
post-submit html form.
In an html context you have to send a post for each switch to a new
"array subscreen"
and then repaint the browser, using various session variables to keep
track
on the server. Or you can use Ajax, sending multiple updates on the
fly.
Google's GWT libraries make updating the
server, without repainting the browser, a fairly painless process. But
GWT is java
programming (that gets translated into javascript, by the Google
compiler).