Autocommit and Buttons

Questions and answers on designing your Servoy solutions, database modelling and other 'how do I do this' that don't fit in any of the other categories

Autocommit and Buttons

Postby huber » Mon Jan 11, 2016 11:57 am

Hi

Our application ist designed with autocommit (behavior). We use a Report Menu and an Action Menu button to offer reports (JasperReports) and special actions. The (open) Report Menu may look like the attached one.

When the user enters or changes any value in a record, for example the mark (column Note) in the screenshot, and directly opens from there the Report Menu and selects (and executes) a report, NO autocommit is done, i. e. no database save of the record. Therefor, the user will get a report showing the wrong value for the changed record (if the report contains this data). The report will show the previous value instead of the expected changed value. Same is true of course with the Action Menu.

For the user, autocommit means clicking anywhere outside a record (row) or field to be sure it's saved. But that does not work with buttons (either placed on a form or made with the solution model).

For my understanding, the autocommit should always occur when clicking somewhere on the application window and looks therefore like a bug to me.

Regards,
Attachments
report menu.png
Changing the mark 6 to another value and executing a report leads to a wrong result
report menu.png (125.7 KiB) Viewed 747 times
Robert Huber
7r AG, Switzerland
SAN Developer
http://www.seven-r.ch
User avatar
huber
 
Posts: 288
Joined: Mon May 14, 2012 11:31 pm

Re: Autocommit and Buttons

Postby Andrei Costescu » Mon Jan 11, 2016 1:10 pm

You can perform the save in that case from code.

This is actually how it works. Autosave will save when selecting another record - that is the most usual case + a few other triggers (like clicking directly on a free space on the form).
If UI is kind of the same - showing the same record that has changes - it will not autosave when you just focus or click another element.
Andrei Costescu
Servoy
Andrei Costescu
 
Posts: 934
Joined: Tue Jun 26, 2007 3:14 pm

Re: Autocommit and Buttons

Postby huber » Mon Jan 11, 2016 5:52 pm

Hi Andrei

From the users point of view this behavior is very counter intuitive. For the user clicking outside means commiting (saving). That's what is tought for an autocommit application, isn't it?
How can a user know about the difference when clicking on menu, a triangle in db tree view, for example, or some other elements - and under what circumstances it's saved or not saved? This is very prone to errors.
How would you user train that?
And, how do I know as a developer, which elements lead to a save and which do not? Where can I find a list showing which elements do not lead to a save when clicked?
Is there a reason Servoy behaves like this?

Thanks and regards,

Andrei Costescu wrote:You can perform the save in that case from code.

This is actually how it works. Autosave will save when selecting another record - that is the most usual case + a few other triggers (like clicking directly on a free space on the form).
If UI is kind of the same - showing the same record that has changes - it will not autosave when you just focus or click another element.
Robert Huber
7r AG, Switzerland
SAN Developer
http://www.seven-r.ch
User avatar
huber
 
Posts: 288
Joined: Mon May 14, 2012 11:31 pm

Re: Autocommit and Buttons

Postby Andrei Costescu » Tue Jan 12, 2016 10:23 am

I agree that the user shouldn't care much about making sure something is auto-saved before performing some action. But this is controlled by the developer - where the solution needs even the record that is currently being edited to be in DB. When the user clicks on something that needs even the currently shown (being edited) record to be saved in DB it should be done in code.

Clicking on any field in the same selected record will not save (so it's not related to element types, but more to a record being still considered as being edited by the user). So the user starts editing a record, changes as many fields as he wants (without having update queries performed after each field change) and then he either changes record (in table view/list view this means just clicking on another row for example) which prompts the auto-save, or changes shown form which auto-saves, or if he wishes he can click on an empty area on the form to force auto-save. Close solution will also perform auto-save; some Servoy API calls that manipulate data or change selection will auto-save as well; even data broadcast can stop editing I think for a record.

As a developer you just have to be aware that the current record in the form might still be edited by the user when some JS gets triggered. So whenever what you need to do in code is based on custom queries or needs in some way the data to be saved in the DB (JasperReports in your case) - not just present in Servoy foundsets/records - you should save as well.
Andrei Costescu
Servoy
Andrei Costescu
 
Posts: 934
Joined: Tue Jun 26, 2007 3:14 pm

Re: Autocommit and Buttons

Postby huber » Tue Jan 19, 2016 11:35 am

Hi Andrei

Andrei Costescu wrote:I agree that the user shouldn't care much about making sure something is auto-saved before performing some action. But this is controlled by the developer - where the solution needs even the record that is currently being edited to be in DB. When the user clicks on something that needs even the currently shown (being edited) record to be saved in DB it should be done in code.

You say this is controlled by the developer. Why does it not just work? I don't see it controlled by the developer, because if the user clicks somewhere on the form, the record gets saved, i. e. autocommit is executed. But not so only for pressing the (menu) button in my example.
I don't recognize an underlying concept here. Again, as a developer, how can I know which elements lead to an autocommit, and which do not?

Andrei Costescu wrote:Clicking on any field in the same selected record will not save (so it's not related to element types, but more to a record being still considered as being edited by the user). So the user starts editing a record, changes as many fields as he wants (without having update queries performed after each field change) and then he either changes record (in table view/list view this means just clicking on another row for example) which prompts the auto-save, or changes shown form which auto-saves, or if he wishes he can click on an empty area on the form to force auto-save. Close solution will also perform auto-save; some Servoy API calls that manipulate data or change selection will auto-save as well; even data broadcast can stop editing I think for a record.
As a developer you just have to be aware that the current record in the form might still be edited by the user when some JS gets triggered. So whenever what you need to do in code is based on custom queries or needs in some way the data to be saved in the DB (JasperReports in your case) - not just present in Servoy foundsets/records - you should save as well.


I agree, as long as a user is editing a record, it's transparent to him that no save has taken action. But for a user there is no clear distinction between an "empty area" and another "not so empty" part of the form.

To stay with my example, is there a reason for Servoy to NOT save a record if the user presses a button on a form?

Regards,
Robert Huber
7r AG, Switzerland
SAN Developer
http://www.seven-r.ch
User avatar
huber
 
Posts: 288
Joined: Mon May 14, 2012 11:31 pm

Re: Autocommit and Buttons

Postby Andrei Costescu » Tue Jan 19, 2016 11:59 am

huber wrote:(...) because if the user clicks somewhere on the form, the record gets saved, i. e. autocommit is executed. But not so only for pressing the (menu) button in my example.
I don't recognize an underlying concept here. Again, as a developer, how can I know which elements lead to an autocommit, and which do not? (...)

As I said before it is not the elements (element types) that lead to an autocommit or not. It is only actions that change the record that is being edited (which can be changes of shown form, clicks on buttons (or other event handlers) that change selected record from code, the user starting to edit another record in the UI in case of tableviews for example) or need the data to really be in the database (actions Servoy knows that need to run SQL) + the special click-on-empty-area that the user can use if he really wants to save right away.


huber wrote:(...) To stay with my example, is there a reason for Servoy to NOT save a record if the user presses a button on a form? (...)

For example you could have a button or an onChange/focusLost/focusGained/... that only modifies 3 fields in the record currently being edited - depending on what the user has already entered so far. So it's similar to the user just changing those during manual editing.

Now that I think of it more, the plugin API you are using to generate reports knows that it needs queries and that it should auto-commit if auto-commit is enabled. So maybe this can be enhanced in the plugin, not necessarily in solution code (plugins do have access to autosave as well).
Andrei Costescu
Servoy
Andrei Costescu
 
Posts: 934
Joined: Tue Jun 26, 2007 3:14 pm

Re: Autocommit and Buttons

Postby huber » Sun Jan 24, 2016 11:59 am

Hi Andrei

I think it's a good idea to enhance the plugin doing auto-commit if auto-commit is enabled. Especially if it has access to autosave, as you mention. This behavior would be logical in my opinion.

Andrei Costescu wrote:Now that I think of it more, the plugin API you are using to generate reports knows that it needs queries and that it should auto-commit if auto-commit is enabled. So maybe this can be enhanced in the plugin, not necessarily in solution code (plugins do have access to autosave as well).


Thanks and looking forward to the plugin version containing this enhancement.
Robert
Robert Huber
7r AG, Switzerland
SAN Developer
http://www.seven-r.ch
User avatar
huber
 
Posts: 288
Joined: Mon May 14, 2012 11:31 pm

Re: Autocommit and Buttons

Postby Andrei Costescu » Sun Jan 24, 2016 10:39 pm

Will you please create a case for this enhancement to be looked at/tracked better?
Andrei Costescu
Servoy
Andrei Costescu
 
Posts: 934
Joined: Tue Jun 26, 2007 3:14 pm


Return to Programming with Servoy

Who is online

Users browsing this forum: No registered users and 4 guests

cron