Carlos Anjos wrote:
> > The layout config is currently not nested within a table, so it might
> > be not clear what table the column belongs to.
> >
>
> Well, using visibleFields and the other attributes within the foreign
> key would make the layout tag redundant, unless as I said,
yes, I think it could be clearer (and simpler) having it all
within foreign key tag
> it would be
> like a kind of super class that gets used when it's not overridden with
> information from the foreign key tag. In that case, the layout tag could
> support a sintax like "tableName.columnName" or have an attribute for
> the table name which would be better.
>
I'm not 100% sure if I understand you here. I think you want to do
what I try with my DefaultVisibleFields etc. attributes below.....
> > Hmmm, no bad idea...What we are thinking about is that we have an
> > internal key that is used within the database and a second 'human readable key'
> > that should be used whenever the user has to pick a row out of that
> > table. That 'human readable key' is used as a default whereever
> > nothing else is used within references etc.
> >
> > Why not bring that information as a nested element into
> > the referenced table?
> >
> Isn't this the same as having a visibleField (human readable key) and
> storeField (internal key) ?
>
exactly, it is the same. Maybe better say 'DefaultVisibleFields', that
expresses better what it really is:
<table name="customer"
DefaultVisibleFields="first_name,last_name,phone" <!-- will be
default for all visibleFields whenever referencing to this
table and attribute visibleFields is not explicitely set
within foreign key tag -->
DefaultVisibleFieldsFormat="%s %s (Phone %s)"
...>
<field name="no" type="integer" isKey="true"/>
<field name="first_name" .../>
...
</table>
And within a referencing table we could have:
<table name="order" ....>
<field name="order_no" isKey="true"..../>
<field name="customer_no" ..../>
...
<foreign-key foreignTable="customer"
name="customer_in_order"
visibleFields="first_name,last_name,phone"
format="%s %s (Phone %s)"
displayType="select"
>
<reference local="customer_id" foreign="no"/>
</foreign-key>
<table>
That would be the same as:
<table name="order" ....>
<field name="order_no" isKey="true"..../>
<field name="customer_no" ..../>
...
<foreign-key foreignTable="customer"
name="customer_in_order"
displayType="select"
>
<reference local="customer_id" foreign="no"/>
</foreign-key>
<table>
because we use the default values for visibleFields
and format.
Devgui could detect the references within the database and
set a default displaytype of "select" within config file.
In case of a key containing several columns it sets the
displayType to "none" (= do not try include the reference
on the JSP as a select, simply because not supported by underlying tags).
It surely cannot set the visibleFields or format attributes to a
useful value.
The user then
- adds visibleFields and/or format attributes to foreign-key tags
or (simplier)
adds DefaultVisibleFields and/or DefaultFormat attributes to table tags
- adjusts the value of displaytype to his needs, we'll have
initial support for "select", "radio", "none"
- applies the xsl stylesheets to the config file
Maybe we better omitt the onDelete/onUpdate attributes within the
initial version, there will not much functionality supporting this
and it might irritate users. We must anyway talk about that more and
will definitely need more time for that.
Regards
Dirk
-------------------------------------------------------
This sf.net email is sponsored by: viaVerio will pay you up to
$1,000 for every account that you consolidate with us.
http://ad.doubleclick.net/clk;4749864;7604308;v?
http://www.viaverio.com/consolidator/osdn.cfm
_______________________________________________
DbForms Mailing List
http://www.wap-force.net/dbforms
