| Open question on a form navigation best practice [message #385617] |
Tue, 10 February 2009 04:53  |
 |
didiera
Messages: 134
Registered: August 2007
Location: Mauritius
|
Senior Member |
|
|
Hello everyone,
this is an open question regarding how each of you tackle multi-block application development versus data validation and form commits.
I have roughly a year's experience in Forms development and I have often come across daunting issues in ensuring data consistency (thru validation) and flexibility of navigation that you sometimes have to trade off against what I came to call loop-holes. I mean by that, circumstances when a given user manipulation can result into unforeseen bugs and error messages -causing applications to hang or blocking user interaction.
Consider a simple example of a form with a master-detail relation modelling the core of an application with a number of secondary blocks in which some usual CRUD (Create Update Delete) operations are offered in addition. In this simple scenario, a question crops up: where/when to provide the user with 'save' functionnalities when you know that the underlying commit/do_key('commit')/commit_form results in the implicit saving of all modified/deleted/inserted data on all the blocks.
1] What will happen if on any of the blocks some records might not be valid at that point and if at database-level, constraints would have been defined (like not null, referential integrity etc) - Most obviously, the form would hang and return an ugly 'Cannot Insert Record' thing unless validation has not been set to occur at item-level.
2] How should one handle the Validation Unit property of his form in response to this issue (if ever that would be advisable at all)? Would it be better in such cases to allow users to manipulate data up to the Record/ Form level?
3] To what extend would it be advisable to exploit the pre/post block triggers when you know that some of them do not allow certain commands (restricted functions)
These are so many questions that seem to only find their answer in the specific needs of the application; but aren't there 'best practices' as such?
regards,
Didier
|
|
|
|
| Re: Open question on a form navigation best practice [message #385927 is a reply to message #385617] |
Wed, 11 February 2009 23:04  |
 |
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS Australia
|
Senior Member
Account Moderator |
|
|
1) The 'not null' situation should have been handled when the 'item' was created by the wizard. If the initial database definition was 'nullable' and after the form was created, the definition was changed to 'not nullable' then this is a 'maintenance' error. Fix it.
Unfortunately, referential integrity has to be tested for 'manually'. Otherwise you just have to live with the default behaviour or try and catch it later. Neither of which helps if the user has entered 'mucho' data and one of them is wrong.
2) I prefer to validate the data where it is happening. At the field level and possibly at the record level. The latter mainly for combinations of items. You can also call the same Program Unit from each level and item, and instead of raising a form trigger failure, do a 'go_item' to the offending item and pop an alert saying that its value is wrong.
3) For me, pre- and post- block triggers are for the uses detatiled in the reference manual - "Use a Pre-Block trigger to: allow or disallow access to a block, set variable values".
David
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
