Hi all,
John and I have already spoken (secretly)
about his proposal, please let me explain it a bit more:
You might ask:
Recently we already had a discussion about foreign key
integration into dbforms, what is this now about, why shall
we talk about it again?
Answer: The discussion we recently had was covering two aspects:
1) How do we write the foreign key information into the config file?
Our result followed the layout of what the torque people do:
Embed a foreign-key tag into table, within that at least one
reference tag. We extended this with some dbforms specific
attributes like visibleFields and format.
In the beginning of his proposal John just summarizes
what we already have, there is nothing new about that.
Devgui is (within local copy) already extended to support
these new tags. Also digester extension is no problem, that
is all more or less done.
2) How will we use this information to let devgui and it's
stylesheets automatically generate JSPs that have
automatically selects for lookups built in?
Eric is currently working on the stylesheets to use the
new information and let them automatically generate selects,
radio groups etc.
But Eric's idea was: How do use existing tags, he does not
change the tag library, he just uses it as it is.
John's proposal is different. With current dbforms we have three
problems in the area of references:
Missing functionality:
1) The tableData tag offers to present the user not an
internal key value, but other fields which have more
meaning for him. To do that, developers can use the
visibleFields attribute. We have extended config file
to be able to specify default values for these attribute for
references as well as for tables within config file.
But this functionality is missing within readonly forms.
We don't have a dataLabel that knows how to lookup values
within another table.
2) We are not able to handle references that consist of
multiple columns like in
<foreign-key foreignTable="customer"
name="customer_known_in_order"
visibleFields="first_name,last_name,phone"
format="%s %s (Phone %s)">
<reference local="area_id" foreign="area_id">
<reference local="cust_id" foreign="id">
</foreign-key>
All our current tags are related to fields, so we can
just handle references containing a single column.
Not missing functionality, but a bit annoying:
3) Although we have foreign key information within config file,
just Eric's new stylesheets will use this, we did not plan
to touch the tags, so they will ignore it.
As a result, we have to repeat all the reference
specification again when we use tableData tags within
selects etc.
So these are the ideas:
a) introduce new tags that are not used to render fields,
but references
b) in the same way as we refer to a field by name we can
refer to any reference by its name, we will then have
all information needed available.
c) create tags to render selects, radio groups to be used
within updatable forms, another tag to be used within
a readonly form
d) design all tags that they are able to handle keys
containing more than just one column
e) make them all look similar, supporting the same set of
attributes (where it makes sense)
f) try to make them as easy as possible, by supporting
default values for attributes within config file, but
make it also possible to override these values
within single usage
So here are the examples again:
Read only form:
<db:dbform name="order" ...>
...
<db:body>
<db:dateLabel field="date"/>
<db:foreignKeyLabel foreignKeyName="customer_known_in_order"/>
...
</db:body>
</db:dbform>
Editable Form using select tag:
<db:dbform name="order" ...>
...
<db:body>
<db:dateField field="date"/>
<db:foreignKeySelect foreignKeyName="customer_known_in_order"/>
...
</db:body>
</db:dbform>
Editable Form using radio tags:
<db:dbform name="order" ...>
...
<db:body>
<db:dateField field="date"/>
<db:foreignKeyRadio foreignKeyName="customer_known_in_order"/>
...
</db:body>
</db:dbform>
Within all these tags developers would have the possibility
to specify a different set of visibleFields and how to format
them:
<db:dbform name="order" ...>
...
<db:body>
<db:dateField field="date"/>
<db:foreignKeyLabel foreignKeyName="customer_known_in_order"
visibleFields="last_name" format="Customer: %s" />
...
</db:body>
</db:dbform>
Please note that it would not be able to handle a reference like
in example above currently, it contains several columns. But even if
we have just one column, compare
the old (current) style:
<db:select fieldName="cust_no">
<db:tableData
name="customer_in_order"
foreignTable="customer"
visibleFields="first_name,last_name,phone"
format="%s %s (Phone %s)"
storeField="cno" />
</db:select>
to what can be written then (if defaults are ok):
<db:foreignKeySelect foreignKeyName="customer_in_order"/>
We welcome your comments
Dirk
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
DbForms Mailing List
http://www.wap-force.net/dbforms
