Open

CRUD tasks

  • 7 March 2019
  • 8 replies
  • 187 views

Userlevel 6
Badge +5
If I have a lot of details in one screen, I mainly use grids instead of grid and form. But if I want to add a record I have to use add in grid or make a task to add a record. It would be really nice to have generated CRUD tasks, this would prevent modelling the same thing multiple times.

8 replies

Userlevel 4
Badge +2
Modeling the same thing multiple times can already be avoided by using the Dynamic Model and dynamically assigned control procedures in the Software Factory. If we would offer generated CRUD tasks as a standard feature in the SF, then we would also use the Dynamic Model and dynamically assigned control procedures to implement this feature.

With that said, I do think it's a nice idea worth considering.
Userlevel 5
Badge +3
Hey Job, I'd like to propose to take your idea a step further. When you have made these C(r)UD tasks, I think you should be able to connect them to the existing add/delete/update buttons in the toolribbon. Otherwise you'd have to disable those buttons and add an extra set of buttons in the task area.

I think this'd be really cool. You could for instance develop a delete task that performs some kind of cascade-delete, where child records are also being deleted.
Userlevel 4
Badge +1
Very interesting suggestions. It would be like having instead-of-tasks for inserts, updates and deletes. Form buttons and shortcut keys would work too.

I'm curious about your opinion on these questions:

a) How do process flows tie into this? Do they still recognize instead-of-tasks as actual tasks?
b) What if an instead-of-task is also a drag-drop task? What if it's asynchronous? Could we do reports as well?
c) There's potential for conflicts between authorization for instead-of-tasks and for CRUD operations. Do we keep them synchronized somehow? Or maybe take the greatest common denominator? How about context vs. layout stored procedures?
d) Are instead-of-tasks still usable as normal tasks when linked to other subjects - if that's even possible?
Userlevel 6
Badge +5
Very interesting suggestions. It would be like having instead-of-tasks for inserts, updates and deletes. Form buttons and shortcut keys would work too.

I'm curious about your opinion on these questions:

a) How do process flows tie into this? Do they still recognize instead-of-tasks as actual tasks?
b) What if an instead-of-task is also a drag-drop task? What if it's asynchronous? Could we do reports as well?
c) There's potential for conflicts between authorization for instead-of-tasks and for CRUD operations. Do we keep them synchronized somehow? Or maybe take the greatest common denominator? How about context vs. layout stored procedures?
d) Are instead-of-tasks still usable as normal tasks when linked to other subjects - if that's even possible?


I think it would be nice if they behave as normal tasks for as much as possible. Just generated ones. Synchronizing them with CRUD operations would be a nice touch, but not a must have I think. Also I would enable them to be linked to other subjects, also for using with drag and drop, but I don't have a specific use case for that now.
Userlevel 5
Badge +3
Very interesting suggestions. It would be like having instead-of-tasks for inserts, updates and deletes. Form buttons and shortcut keys would work too.

I'm curious about your opinion on these questions:

a) How do process flows tie into this? Do they still recognize instead-of-tasks as actual tasks?
b) What if an instead-of-task is also a drag-drop task? What if it's asynchronous? Could we do reports as well?
c) There's potential for conflicts between authorization for instead-of-tasks and for CRUD operations. Do we keep them synchronized somehow? Or maybe take the greatest common denominator? How about context vs. layout stored procedures?
d) Are instead-of-tasks still usable as normal tasks when linked to other subjects - if that's even possible?


a. I think they should look at the instead-of-tasks
b. drag/drop and asynchronicity (is that a word?) must be disabled, i think. Reports would be weird as well.
c. Layout and context procedures should ideally not be a different thing. Why not one big layout/context procedure concept?
d. Yeah, why not?

You could also implement add/update/delete as a procedure by default and have the possibility to weave in additional bits of code template or replace the default insert/update/delete template altogether.
Userlevel 4
Badge +1

......
I'm curious about your opinion on these questions:
......
d) Are instead-of-tasks still usable as normal tasks when linked to other subjects - if that's even possible?
......
d. Yeah, why not?


The short answer is that parameters of such tasks are completely determined by the columns of the subject they're connected to. This makes it harder to use them anywhere else. But agreed, I can imagine use cases in which linking such tasks to other subjects makes sense.

The deeper reason I asked all those questions is that I was trying to assess this looming dichotomy between tasks and regular CRUD. This applies to both application logic and model settings.

Easy example: consider an instead-of-update task. Which default procedure do we use? The subject's default procedure? Or the task's default procedure?

Harder example: we're doing a mass update from Excel. Which rows can we update? Do we:
a) Call the subject's context procedure and check if the instead-of-update task is legal for the Excel row?
b) Call the task's layout procedure and use its 'confirm_button_type' result?
c) Call the subject's layout procedure and use its 'confirm_button_type' result?
d) Combinations of the above?

These examples are far too detailed and technical to require an answer right now. And why should application developers have to worry about those things anyway? It should just work in the most obvious way, with the least amount of cognitive overhead. But, if there are conflicting opinions about what's obvious, things are not that simple.

My personal preference is that CRUD works as normal, the only difference being that a stored procedure is called instead of an insert/update/delete statement. This ignores all the 'task'-ness of such stored procedures. Easy to implement, almost zero cognitive overhead, no duplication of code in application logic procedures, almost no extra testing, no extra documentation to write and maintain, no extra training required, etcetera etcetera. It's transparent, and it's cheap.

So I'm leaving this one out in the open, and I wonder how this idea will further develop.
Userlevel 5
Badge +3
My personal preference is that CRUD works as normal, the only difference being that a stored procedure is called instead of an insert/update/delete statement. This ignores all the 'task'-ness of such stored procedures. Easy to implement, almost zero cognitive overhead, no duplication of code in application logic procedures, almost no extra testing, no extra documentation to write and maintain, no extra training required, etcetera etcetera. It's transparent, and it's cheap.

Henk, to me it is just this. Have procedures handle inserts/updates/deletes instead of direct database interactions. And aditionnaly, be able to add your own code before/after/instead of the default code provided by the tooling.

So not this:
code:
insert into table tablename (col1, col2) 
values (value1, value2)

but this:
code:
exec insert_tablename value1, value2


This also means you no longer have to grant access to insert/update/delete on a specific table. This in turn makes it much more easy to control what interactions a specific user can do for a specific table. For example, only update or delete data the user is authorised to.
Userlevel 6
Badge +8

For reference: 

 

Reply