Monday, May 5, 2014

The actions API needs a show_record method

(Sorry, the following isn’t very clear even to me. Don’t worry if you can’t seen to follow.)

This weekend I tried to solve the following issue:

  • Summary panels don’t get refreshed, e.g. when I add a new upload then I must click the Refresh button in order to have the summary panel updated.

Which turned out to be surprisingly hard, maybe even impossible with the current actions API. I started to understand more about the actions API. The first implementation of the (customizable) SubmitInsert method is still too specific, we need to get it more abstract. For example it is not the SubmitInsert action who should decide whether we can send a full data_record or must reduce the answer to a record_id. Functionally these two responses mean the same: they ask the client to “show this record in a detail window”. But in certain AJAX contexts (when uploading files) it is not possible to encode a whole record. There is a technical reason, some encoding problem, I don’t even remember the details. So this decision should clearly not be responsibility of any application code. We need a show_record method for ActionRequest to encapsulate this.

Another thing that I tried to introduce is the “editing mode”. Meanwhile I think that this is also too technical for application code. An “editing mode” is technical stuff. Action code should never worry about such things.

We then have the stay_in_grid option. This is clearly application responsibility. It is the application developper who says whether a given table (which has a detail layout) prefers to open that detail after inserting a new record or not. stay_in_grid is rather exceptional. One use case is the MedicalUploadsByClient table. This table does have a detail_layout but does not want to display a detail of each new upload. The detail window should open only “when explicitely asked”. The concrete implementation of this option must remain up to the user interface.

So our API needs another change…

Yes, a SubmitInsert action should return detailed information about the record that has been created.

When i click the “+” button in a MedicalUploadsByClient summary, this will run the JavaScript implementation of the insert action, which opens the MedicalUploadsByClient.insertPanel. When the user then clicks OK in that window, the current SubmitInsert action returns a data_record, yes, but in that context we don’t want to use that information.

Another challenge: The SubmitAction knows that it is to be called from an InsertRow action. InsertRow is a windowed action (opens_a_window is True): it opens the Insert window. And “of course” this window should get closed when SubmitAction returns successfully. Question: should SubmitAction explicitely set close_window or not? Let’s say yes. But then how to handle the special case which happens when the user presses F2 on the phantom record of a grid (and then confirms cell editing)? Lino.GridPanel currently translates this to a call to SubmitInsert. But it is a special context since here we have no insert window opened.

Checkin at 15:05 : the new vision seems usable…

… there are still some details to fix. For example:

  • open a GridPanel –> Double-click on a row –> change some value and save –> close the detail window

  • Now I must click twice on the close button of the GridPanel in order to have it disappear

But before tidying up these details I decided to do another dirty work: make the DeleteSelected action customizable.

This wasn’t so hard. And now the confirmation message before deleting records is more clear because it lists the records to be deleted.

I am rather satisfied because these were some dirty works that had been waiting since a long time. And funny but true: the summary panels still don’t get refreshed…

Checkin wegen Feierabend.