Developing UI

Improve this page


GUI components

abapGit UI is based on HTML and CL_GUI_HTML_VIEWER. Main parts are:

Rendering content

An example of RENDER_CONTENT (or any other helper method with HTML output)

METHOD render_content.

    CREATE OBJECT ro_html.

    ro_html->add( '<div>' ).
    ro_html->add( '<h1>My content</h1>' ).
    ro_html->add_icon( 'star/error' ).
        iv_txt = 'click me'
        iv_act = 'some_event_handled_in_abap' ).
    ro_html->add( render_some_complex_stuff( ) ).
    ro_html->add( '</div>' ).


Html helper

ro_html which is the instance of ZCL_ABAPGIT_HTML is helper tool for html rendering. It accumulates html content and then can output it with render method. It has a couple of important methods:


Sub-classing ZCL_ABAPGIT_GUI_PAGE is not the only way to render the content. You may want to separate some visual component which is not a page e.g. ZCL_ABAPGIT_GUI_VIEW_REPO is a class like that. In essence you have to implement ZIF_ABAPGIT_GUI_RENDERABLE and it’s method - render. Then you can reuse it or even pass directly to GUI class as a page to render.

Router and event handlers

To process sapevents in abap the component (page) must implement ZIF_ABAPGIT_GUI_EVENT_HANDLER=>on_event. It has the same importing params as sapevent handler of cl_gui_html_viewer, please refer SAP official documentation for param meaning and detail. For the exporting params see below.

Events can be processed on 2 levels - in page or in the router. If an event occures, the GUI checks if the current page implements ZIF_ABAPGIT_GUI_EVENT_HANDLER and if so calls it. If the event was not handled by the page (see below how this is indicated) the event is passed to the router.

Router (ZCL_ABAPGIT_GUI_ROUTER) is the class which handle global abapGit commands like opening specific pages and actions like repo installation/deletion.

In order to indicate the result of event handling an on_event implementation must return ev_state (element of zcl_abapgit_gui=>c_event_state) and, optionally, ei_page:

Asset manager

ZCL_ABAPGIT_GUI_ASSET_MANAGER class is responsible for managing static assets. Very briefly: relevant assets must be registered in the asset manager instance during GUI initiation so that they can be used in the browser UI. The registration happens in ZCL_ABAPGIT_UI_FACTORY=>INIT_ASSET_MANAGER. Here is an abstract from the method for example:

DEFINE _inline.

DATA lt_inline TYPE string_table.

CLEAR lt_inline.
" @@abapmerge include > _inline '$$'.
    iv_url       = 'css/common.css'         " <<< PATH TO THE ASSET FROM HTML, WHICH IS ALSO IT'S UNIQUE NAME
    iv_type      = 'text/css'               " <<< CONTENT TYPE OF THE ASSET
    iv_mime_name = 'ZABAPGIT_CSS_COMMON'    " <<< MIME OBJECT NAME
    iv_inline    = concat_lines_of( table = lt_inline sep = cl_abap_char_utilities=>newline ) ).

CLEAR lt_inline.
" @@abapmerge include-base64 > _inline '$$'. " <<< THE FILE BINARY !!!
    iv_url       = 'font/ag-icons.woff'
    iv_type      = 'font/woff'
    iv_mime_name = 'ZABAPGIT_ICON_FONT'
    iv_base64    = concat_lines_of( table = lt_inline ) ).

" see for source SVG
    iv_url       = 'img/logo'
    iv_type      = 'image/png'
    iv_base64    =

There are several ways to store content of a static asset in abapGit.

  1. Pass the asset inline. e.g. the logo at the end is a PNG image. It is encoded as BASE64 and passed as iv_base64 param
  2. Inline can be also a text then should be passed with iv_inline
  3. Read from a MIME object - if inline is not passed, the assets falls back to the MIME

The tricky thing is that abapGit can be either installed as a development version, deploying all the MIME objects in particular or as a single file. This single file must contain all the assets (images, css, js and fonts) in-code. This is enabled by abapmerge tool. Consider the css/common.css registration above.

Note: for the binary files, like fonts, use @@abapmerge include-base64 pragma.