Dirk Kraemer wrote:
> 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.....
> 

Yes. I understand you better now, with an example. I prefer your idea to
having a separate layout tag.

> > > 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
> 

I would prefer if the DefaultXXX attributes get automaticaly added, with
the primary/referenced key, for example, and then I would just have to
change to whatever I wanted...

>   - 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.

If it's not going to be supported any time soon, better leave it for
later.

Carlos.


-------------------------------------------------------
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

Reply via email to