Dirk Kraemer wrote:
Erics contributions:
1) extend dbforms-config.xml to support the declaration of foreign keys. Here is an excerpt
from eric's summary from developer's list:
<table name="TRAFFIC">
...
<field name="EMAIL_ID" fieldType="int" size="10"/>
<field name="CAMPAIGN_ID" fieldType="int" size="10"/>
...<foreign-key foreignTable="EMAIL">
<reference local="EMAIL_ID" foreign="EMAIL_ID"/>
</foreign-key>
<foreign-key foreignTable="CAMPAIGN_ID">
<reference local="CAMPAIGN_ID" foreign="CAMPAIGN_ID"/>
</foreign-key> <!-- add "granted-privileges" element for security constraints -->
</table>
*If I had understood*:I would agree to Eric to use that syntax, it supports:- multiple columns within one key - giving names to the constraints - specifying rules what should happen in case of deletion, updates
the latter point is *fantastic*. For example I use to specify "cascade" conditions using interceptors.
when you delete a record from a "master table", you should delete all the related records from any "mapping table"
[user] (1) ---- (n) [user_class] (n) ---- (1) [class]
If I delete an "user" record, I should delete all the records from the user_class table (that maps the n:m relation between user and class)
that are related to that records.
To do that, I can use my database triggers or stored procedures, or I can write the related code and use interceptors to fire the jdbc query (if you like to be "as database independent as posssible").
With these new features, I can specify that rules into the dbforms xml file, and maybe dbforms can provide specific "callback" interceptor classes that do the work...
Am I right ?
2) Eric's idea:
a) Extend xsl stylesheets used by devgui to generate initial JSPs to use that foreign key information. Instead of including a textual input field, e.g. a select field should appear
automatically filled with column values from referenced
table
b) do _not_ automatically create a select tag whereever
a reference is. That would be no good idea if referenced
tables contain millions of rows.
b) Instead of presenting the user an internal identifier
that might be used for internal references, but does not mean
anything to end users, other columns are presented within
the select field. That corresponds e.g. to the visibleFields
attribute within the tableData tag.
sounds good. Usually I never use xslt to build the view pages; It seems that in this manner you can get a more intelligent build procedure.
So we need an extension within config file to specify which
columns should be rendered as select tag instead of simple input fields and which column(s) should be presented to the
end user when filling the select tag. Here is Eric's suggestion: A new Tag
<layout-config>
<col name="EMAIL_ID" displayField="EMAIL" displayType="select"/>
...
</layout-config>
within dbforms config file. Eric's stylesheets transform this to
<db:select fieldName="EMAIL_ID">
<db:tableData ... foreignTable="EMAIL"
visibleFields="EMAIL" storeField="EMAIL_ID" />
</db:select>
I see following topics to talk about:
1) The column name is used to state that a select tag
has to be created. What if we have several columns with
same name but different semantics within the database? wouldn't it be better to use the reference name instead?
That should be unique at least within one config file...
if the layout-config xml element is not a child of the table element, it is possible to use TABLENAME.FIELDNAME ?
2) What if a reference consists of several columns? That is a base problem: Current select tag does not support
this. Theoretically that should be possible. Have the
select tag separated from the other tags and whenever it is
set, use a bit of Javascript to update several form fields with the values of the key.
Could you or Eric make an example ?
But currently that is not possible. Would be ok for me
it it just works for single-column references and generates
an error in other cases. But must be documented.
3) tableData tag supports multiple visibleFields, why not
do the same here and also rename the attribute to use the same name as within tableData?
Sounds good.
4) tableData supports a format tag that might be used
to do something like
.. visibleFields="firstName,name,phone"
format="%s %s (Phone %s)"
(or similar, it is currently a bit in discussion)
I'd suggest to support that here, too. Should be just passed...
So it would become something like (format attribute not used):
<layout-config>
<ref name="customer_in_order" visibleFields="first_name,name,phone"
displayType="select"/>
...
</layout-config>
Another example:
<ref name="customer_ref2" visibleFields="firstName,name,phone" format="%s %s (Phone %s)" displayType="select"/>
5) Last question:
Would it make sense to include this information nested within the foreign-key tag itself? Something like:
<foreign-key foreignTable="EMAIL" name="email_in_order" onDelete="cascade" onUpdate="restrict">
<reference local="email_id" foreign="email_id"/>
<display visibleFields="EMAIL" displayType="select"/>
</foreign-key>
This seems to be the "incapsulation" rule of the OOP paradigm... If foreign key is the "java class"... would it make sense to include the visibleFileds attribute in that class ? I think it's a good idea.
I must admit, I cannot currently oversee what that would mean
for the xsl stylesheets, if that would be difficult or not. It is
just a question of what syntax we would like to use within config file.
Regards
Dirk
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
DbForms Mailing List
http://www.wap-force.net/dbforms
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ DbForms Mailing List http://www.wap-force.net/dbforms
