En la programación Web Dynpro for ABAP cada controlador tiene un número de métodos predefinidos, que son llamados por el WD Runtime en un orden predefinido. Estos son los llamados métodos HOOK. En este artículo nos vamos a centrar solo en uno de ellos, el método WDDOBEFOREACTION.
Este método tan sólo se encuentra en los controladores de vistas, ya que son los únicos en los que se pueden implementar acciones. Este método se ejecuta siempre inmediatamente antes de que se ejecute una acción desencadenada por un evento (pulsar un botón, pulsar enter, seleccionar una fila…) y debe ser utilizado para hacer las comprobaciones necesarias para que la acción se ejecute correctamente.
La primera vez que se entra a implementar el código del método, aparecen comentadas las siguientes líneas de código:
DATA lo_api_controller TYPE REF TO if_wd_view_controller. DATA lo_action TYPE REF TO if_wd_action. lo_api_controller = wd_this->wd_get_api( ). lo_action = lo_api_controller->get_current_action( ). IF lo_action IS BOUND. CASE lo_action->name. WHEN '...'. ENDCASE. ENDIF.
Esta es una ayuda para saber en tiempo de ejecución que acción se va a ejecutar. En el atributo name del objeto lo_action se tiene el nombre de la acción siguiente. Así es posible implementar comprobaciones diferentes para distintas acciones. Por ejemplo, si se tiene un botón salir y un botón guardar asociados a acciones con el mismo nombre, antes de guardar se deben comprobar unos campos introducidos por el usuario, sin embargo al pulsar salir no. Por lo tanto, cuando el atributo name sea ‘GUARDAR’, se debe hacer la comprobación, pero cuando sea ‘SALIR’ no.
Cuando se estén haciendo las comprobaciones que se deseen, es posible que no se quiera que se ejecute la acción, si hay algo erróneo o vacío. Para parar la ejecución, se debe lanzar cualquier mensaje de error estando en el método WDDOBEFOREACTION. Con esto se consigue que las acciones de tipo estándar no se ejecuten. Es posible hace que una acción se ejecute igualmente aunque haya un error, indicando que su tipo sea independiente de validación.
En la pestaña de acciones es donde se indica el tipo de las mismas. En el ejemplo superior, se ha definido la acción GUARDAR como estándar, por lo que si hay algún error en la validación previa no se ejecutará aunque debiera de hacerlo. En cambio SALIR sí que se ejecutaría.
Una de las comprobaciones típicas es que el usuario introduzca todos los campos obligatorios. Para hacer que un campo se obligatorio, hay que indicarlo en el elemento UI del layout en su propiedad state.
Con esto se consigue que un pequeño asterisco rojo aparezca en el campo, indicando que es obligatorio rellenarlo, pero solo con eso no basta para que si no se rellena de un mensaje de error. Para ello, se debe escribir el siguiente código en el método WDDOBEFOREACTION.
DATA lo_view_controller TYPE REF TO if_wd_view_controller.
lo_view_controller ?= wd_this->wd_get_api( ).
cl_wd_dynamic_tool=>check_mandatory_attr_on_view(
EXPORTING
view_controller = lo_view_controller
display_messages = abap_true ).
La llamada a este método hará que todos los campos obligatorios que estén vacíos sean resaltados, y se escribirá un mensaje de error por cada campo en el área de mensajes.
Con la utilización de este método se puede conseguir un código más ordenado, haciendo que en las acciones no se tengan porque hacer validaciones, preocupándonos solo de lo que la acción debe realizar. Además, si debemos añadir alguna comprobación a posteriori, solo se debería tocar este método, y no todos donde sea necesario este nuevo chequeo.