===================
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.