Luca, thanks for your suggestion. Your first suggestion worked great, but when it came to changing the visible fields for a non-editable label view (e.g. list.jsp) we were stuck seeing only the id column. Do you know how to get dbforms to recognize defaultVisibleFields and visibleFields in foreign key relationships?
Thanks again, Matthew -- Original Message -- >Hi Richard ! > >> Dear All, >> >> We have three tables: book, chap, and sect (for book, chapter, and >> section). A book contains chapters, a chapter contains sections, and all > >> three have titles. >> >> book: >> - book_id >> - title >> >> chap: >> - default_book_id (fkey to book.book_id) >> - chap_id >> - title >> >> sect: >> - default_chap_id (fkey to chap.chap_id >> - sect_id >> - title >> >> >> On the dbforms page for listing sections, we can get dbforms to display > >> the following columns: >> chap_id, sect_id, title >> >> What we need instead is: >> chap.title, sect_id, title >> >> Can anyone tell us how to do this? > >You could use: > >- a <db:select/> tag > > <%-- section master table --%> > <db:select fieldName="default_chap_id"> > > <%-- get data from the chap detail table --%> > <db:tableData name = "myChapter" > foreignTable = "chap > visibleFields = "title" > storeField = "chap_id"/> > </db:select> > </db:select> > >but the field value is NOT read-only... the user could overwrite the >default_chap_id value taking a new value from the select widget (it >should list all the values from the chap table). > > >- use the new Query Support (by Henner Kollmann) to get joined sql with >a flexible join statement. See: "Chap. 18.0. Query Support Within >Dbforms" for further informations. > > >- and at the last position: a commodity view > >If you work with queries containing joins between "constant" tables >(always the same tables...), you could use a sql view to get >a table containing all the "verbose" informations from the master table >and the related "verbose" informations from the detail table... > >example: an item can be of a certain itemtype; the itemtype.itemtypeid >key migrates into the item table as foreign key (If I remember the sql >theory correcly...). > >[item] (1..n) 0---------- (1) [itemtype] > >CREATE TABLE "item" ( > "itemid" integer, > "name" character varying(64), > "itemtypeid" integer, > "sku" character varying(16), > "indate" date, > "online" boolean, > "isnew" boolean, > "price" real, > "categoryitemid" integer, > "thumbnail" character varying(254), > "image" character varying(254), > "description" text >); > > >CREATE TABLE "itemtype" ( > "itemtypeid" integer, > "name" character varying(32), > "templateid" integer >); > > > >If you want to get all the informations about a certain item record, >and the name of the related item type attribute, you could use a similar > >view: > >-- >-- view_item >-- >CREATE VIEW view_item AS >SELECT > i.itemid, > i.name, > i.itemtypeid, > it.name AS itemtypename, > i.sku, > i.indate, > i.online, > i.isnew, > i.price, > i.categoryitemid, > i.thumbnail, > i.image, > i.description, > ci."path" >FROM > (item i JOIN categoryitem ci ON > ((i.categoryitemid = ci.categoryitemid)) > JOIN itemtype it ON > ((i.itemtypeid = it.itemtypeid))) >ORDER BY > ci."path", i.name; > > >then, into the dbforms config file, you could map the item view as >dbforms' item table. > >PROBLEMS: to get the "insert a new record" dbforms operation working >correctly on the view, you should: > >a) >write view rules into your database ddl... I never tried this system. >Anyway, view rules are not a sql standard. > >b) >write your own new event class that get key informations from the view >and redirects dbforms operations into the related sql table. >To get this behaviour you should set your new event class as: > >b.1) the default event class > b.2) for the "EVENT_NAVIGATION_NEW" event type > b.3) for that table ;^) > >But this procedure could work only with the cvs version of dbforms... >and it is not documented... > >Regards, >Luca > > >> >> Thanks much, >> Richard Bondi >> Matt Stein >> >> >> >> ------------------------------------------------------- >> This SF.NET email is sponsored by: Thawte.com >> Understand how to protect your customers personal information by >> implementing >> SSL on your Apache Web Server. Click here to get our FREE Thawte Apache > >> Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en >> _______________________________________________ >> DbForms Mailing List >> >> http://www.wap-force.net/dbforms >> >> >> > > > > >------------------------------------------------------- >This SF.NET email is sponsored by: Thawte.com >Understand how to protect your customers personal information by implementing >SSL on your Apache Web Server. Click here to get our FREE Thawte Apache >Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en >_______________________________________________ >DbForms Mailing List > >http://www.wap-force.net/dbforms > ------------------------------------------------------- This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will allow you to extend the highest allowed 128 bit encryption to all your clients even if they use browsers that are limited to 40 bit encryption. Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en _______________________________________________ DbForms Mailing List http://www.wap-force.net/dbforms
