why the "actions" layer?

Question

I'm pretty sure I'm overlooking something, but in my couple days of formspider testing all my actions are of the kind

Name:  XXXXX
Proc:  My_Pck.XXXXX

Hence it would help a lot if one could attach a package name to a formspider application. Then every event's action name would be identical to the very procedure of said app-package.

tease: The action oobject has almost no properties and is just a tedious typing overhead.

Answer 1

Hi Paul,

I was wondering why anyone asked this question until now. :-)

You are correct that actions are not critical objects. We could loose them (and stick its only attribute somewhere else). It would probably make typing a little easier too.

The value of actions become more obvious when you start maintaining your application. Actions make refactoring easier. Without actions, if you call a procedure in X number of places and rename/move your procedure, you'd have to update X number of places in the application. Now with actions, it's just one place. And if you rename your action, everything is automatically renamed behind the scenes it is all stored in a relational model. Granted, this could be done without having actions but having them makes it easier.

Impact analysis is also easier. (then again, it could be done without actions)

Also without actions, you'd have to create at least the stubs for procedures so that you can use them. Now you can prototype an entire application without creating a single package or procedure.

It is also nice to have the definition of your application without any implementation details in it. Nothing about a Formspider application is related to PL/SQL. The entire code base could be implemented in any other language and the app would not notice the difference. That doesn't have any practical benefit immediately but it sure is nice. Our only implementation dependent part is SQL. SQL is so universal at this point that I don't think it matters.

Now the question is: Would we create the concept of actions if we knew what we know now about action, when we started building Formspider?

My answer is still yes. There is something not nice about Panels pointing to PL/SQL procedures. :-) We really try hard not to put code into the UI definitions. That is not a great practice.

Hope this helps.

Kind Regards, Yalim

Answer 2

Good points, so let me present a mere developer comfort enhancement suggestion:

application property specifies a default package's name
event action=xxx accepts any text typed, even w/o action
"save" or "save all" discoveres new action names and auto-creates actions for that names using the package name specified in step one, PLUS it pops up a dialog about the autocreated actions, together with a warning(!) where the package currently lacks the procedure.

While keeping all advantages of the action layer one only needs to A) specify the action-name inside the <event> and add B) a procedure to The Package.

=> much less typing (and clicking and cutting and pasting) w/o sacrificing the action layer.

(I'm just trying to point out possible ways to reduce the infrastructure typing (bracket, xml keywords..) needed in formspider. I will refrain from requesting an IDE-side PL/SQL editor, no worries ;) )

why the "actions" layer?

Follow this question

Related questions