Hi Carlos!
Carlos Anjos wrote:
>
(about proposed foreign key syntax within dbforms-config.xml like:)
> >
> > <foreign-key foreignTable="customer" name="customer_in_order"
> > onDelete="cascade" onUpdate="restrict">
> > <reference local="area_id" foreign="area_id"/>
> > <reference local="cust_id" foreign="cust_id"/>
> > </foreign-key>
> >
....
> >
> > I hope we can quickly agree on that.
>
> Yes. These are excelent ideas. Perhaps the tool that contructs the
> config file could even pick that information from databases that support
> foreign keys (mysql not being one of them)
>
Yes, that is exactly what will happen. Eric sent me a message
yesterday offering to take over that part. His first version
might not support the ondelet/onupdate rules, but will definitely
write information about the tables and columns taking part in
references into the config file.
The rules support can be added at a later time, we must anyway talk
about that.
> >
> > 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.
>
> This alone would save me vast amounts of time. I'm all for it.
>
> >
> > 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.
> >
>
> Yes, I can see a problem there. What would be the alternatives ?
> Instead of having a preferred displayType of "select" we could have
> something else.
> Perhaps something with some search facility. Several alternatives could
> be implemented later as diferent views (select/radio/search/etc).
>
I currently don't know if Eric already supports it, but I hope that
radio fields will not too difficult to support, don't they use
the same nested tags?
Another option (that is what I originally thought of) must always
be to ignore the reference and simply create an input field like
it is now done.
....
> > 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...
> >
>
> Not sure I understand. Is it possible to have some table with different
> collumns but equal names ? Would it not be a bad idea ?
>
The layout config is currently not nested within a table, so it might
be not clear what table the column belongs to.
> > 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.
> >
> > 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.
> >
>
> I never needed this, but what you propose could be a solution.
>
Apart from other things one important difference between dbforms
and lots of other systems out there is that it supports
keys consisting of more than one column. We should at least put
a comment into the docs where we don't support this.
Just to make clear: It is not a problem of Eric's extensions,
but of the underlying select tag.
> > 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?
> >
>
> Agree. It would be more consistent.
>
> > 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"/>
> >
>
> Yes. This makes perfect sense. We should be able to define as much as
> possible in the config file, so that the automatic tools can do most of
> the work. This was also of what I had thought of adding, as attributes
> to the field element. But as we discussed earlier, this kind of approach
> is a better one.
>
There is hope we might be able to include a kind of 'sprinf for Java', I'm in
contact with Shawn, who offered to do some work here. The method we are talking about
is also able to use formats like '%5d', '%7.3f'.
> > 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>
> >
> > 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.
>
> This would make configuration simpler. And it makes sense, since
> different tables when referencing some other table, will want to diplay
> different fields (for example, when referencing a user table, one table
> would display a user's full name whereas another table would display a
> user's login, although they reference the same table.)
> Pehaps we could use the layout element as a kind of superclass. Let me
> explain: if we have some table that is referced a lot of times, and we
> figure that it's always the same fields that are displayed with the
> same format, and the same field that gets stored, we could put that
> information in a layout element outside the table element, intead of
> having to put that information inside every foreing key element.
>
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?
Thank you for taking part in this discussion
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
