Luca Fossato wrote:
...
> >
> > 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
>
> *If I had understood*:
>
> 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 ?
That is currently not part of Eric's extensions, but the important
thing is : 'what can be expressed using this syntax?'
And yes, that features you speak about can be implemented at a later time.
One might think that the following quick hack might be sufficient (delete
example):
- when deleting rows, check, if there are such rules. If yes, create
a corresponding "delete from foo where referencing_column = value' and
send it to database
this could be implemented within DeleteEvent
However, following problems arise:
- what if we have cascading references?
A <---- B <--- C (let's say both with rule 'delete')
Then we should also delete rows within table C.
If we have:
A <---(delete) B <---- (restrict) C
we might then refuse to delete the row in A.
- Is the current granted to delete in all those tables?
- what about user defined interceptors in other tables?
So I think it would be better to create real update/delete
events that then should be processed by the event handling
system. Surely that would be more work to do.
One question that arises is: We must be able to tell dbforms if
it should care about those rules or if they are handled by something
else (DB triggers, interceptors...). Maybe another attribute here.
>
> > 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 ?
Let's say we have a company where the customer key consists of
area_id and cust_id.
Inside a form about customer's order we want a reference to customer,
because each order belongs to a customer. But we cannot use a
dbforms select: that is just able to handle a single column. I think
of an automatically generated select like:
<select name="...">
<option value="NY::33">Paul Smith from New York
<option value="LON::55">Peter Blabla from London
...
</select>
The key contains both values (area and cust id). We now would have
two possibilities:
- client side: use JavScript to split up the value within an
onChange handler and set the two columns area_id and customer_id
of the form.
- server side: do something similar within dbforms event handling
> >
> > 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.
>
Well, you are right, it can just occurr once, so that would be possible.
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
