With that said, I do think it's a nice idea worth considering.
Hey Jop, 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.
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'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.
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.
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.
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:
insert into table tablename (col1, col2)
values (value1, value2)
but this:
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.
For reference:
To emphasize the need for this feature I would like to show the following example taken from IAM in Universal:
This is very confusing in an end users perspective. Can you tell me the difference between de garbage bins? Or the edit pens? Users should (must) not see this kind of constructions.
We use also grid only in details. I woud be happy if I just could open the form in a popup.
All the votes have been transferred into this idea.
Unfortunately we haven't got around to this feature yet. It is still high on our backlog, but we don't have an expected date for it at this time.
All the votes have been transferred into this idea.
Updated idea status Working on it!→Next release
From 2022.2, it will be possible to utilize so-called Handlers. These Handler procedures will fully replace the Add, Edit or Delete action once used.
This logic concept can be used best for actions that need to be performed row-by-row, for instance, to delete child records before deleting a parent record. For set-based actions, it is best to use triggers.
These procedures are atomic by default, which means all code run by these procedures is run inside a transaction. This ensures that all mutations made by the procedures will be either run successfully in their entirety or fail and be rolled back to their original state. Just like with Tasks, there is space to weave in templates inside the catch part of the procedure.
Like other logic concepts, you can activate the handler logic per table and action (menu User interface > Subjects > tab Default > tab Settings > tab Performance):
In Functionality (menu Business logic), control procedures can use the code group HANDLERS to assign templates to the actions:
Assign code group HANDLERS to the control procedure
Assign a template to the program objects
As result, in this example, three procedures are created for the GUI to be used when the GUI actions are executed:
Whoohoo!!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.