MVC-style application with command pattern

[Former Member]

Hello,

I am building a small MVC application using the (GoF-)command pattern. I tried to pretty much follow the way struts does it: a front controller maintains a map of specific action objects and decides which action to use based on some hint in the request. So far I was using the IDs of htmlb (button-)events to determine the appropriate action object - e.g. pressing a 'save'-button (i.e. a button having the ID-attribute set to the string 'save') would cause the controller to use his save-action. Data exchange is realized via data binding.

This all works fine provided there is only one button of a 'type' - in the sense of 'same ID', e.g. save-button, delete-button etc. which in turn trigger the according actions - per page.

Now I have a case where several buttons of the same type (i.e. same action required) are needed: a table with several entries each containing an itemnr. and a 'details'-button. Obviously I have to know which particular details-button was pressed, that is which item's details the user wants to see - in other words: I have to parameterize the the event/action.

Since with htmlb-style events there is no easy way to manipulate the request, the query string (i.e. form fields) is not an option. Currently I am using the value of the 'onClick' attribute wich is available in the htmlb-event to transfer the parameter (here the itemnr.). However this is most certainly not its intended usage

As a sap/abap newbie I would be grateful if someone could comment on the following questions:

1. What do you think about the overall architecture, is this actually bsp-style?

2. How would you solve the parameter/'onClick'-issue in a cleaner way?

Regards,

Sebastian Kamp

[former_member181879]

Sebastian,

I will not comment on your pattern aspects. Do what it takes to get the job done.

As for the fact that you have several buttons that you for some reason have wired onto the same ID, there one of two ideas you can use to multiplex additional information.

Let us assume that you use the ID to carry your command, such as PRINT, SAVE, etc. Then you can use the onClick string to contain any string that has a meaning to you. This string is transparently transported back and forth. Just write the sub-id information you require in there.

Alternatively, render out one hidden field with an empty value that will be returned to the server. Set the onClientClick to fill this hiddenfield with the subId stuff you need. Pick it up in the controller again with a request->get_form_field.

++bcm

[Former Member]

Hello Brian,

thanks for your answer. The first alternative your are proposing is what I am using currently. I thought however this was not the intended usage of an 'onClick' attribute and I fear that this misuse (which I feel is a design flaw in my application) might lead to problems sometime in the future.

The second proposal does not really fit into the overall architecture since the data is not bound to its event. The nice aspect of events in this context is the fact that only the target controller's get_handle_event() method is called - the framework makes sure all other (super-)controllers ignore it. This does not hold for form-data and a call to get_form_field() in some other method.

Regards,

Sebastian

[former_member181879]

This is fine. Meaning of onClick will <b>not</b> be changed anymore.

One nice thing you can consider to do, is use method names in the onClick strings. For example:

onClick="PRINT"

onClick="SAVE"

etc.

Then you make create methods like this on some class.

And then when you have the event, you can just dispatch them dynamically. In ABAP the code sequence would be:

DATA: event_string TYPE STRING.

event_string = ...

TRANSLATE event_string TO UPPER CASE.

CALL METHOD myObjRef->(event_string).

That translate is important! Also, you must use the CALL METHOD way of calling, and not the short form.

++bcm

[Former Member]

hmm.. interesting hint. Actually I think what you propose here is an alternative to the command pattern:

Instead of administering a bunch of objects which each represent a single like-named command (and implement a common interface) you use one (fairly large) object and just dynamically invoke the appropriate method. This would probably simplify communication between action(s) and controller(s).

I am going to think about this

Regards,

Sebastian

[former_member181879]

If you should like the idea, and make it to work, why not write a short article/weblog on it? It are these good ideas which people think about, make perfect, and come up with good answers, that really make for good reading.

++bcm