Skip to Content

In my previous blog about form iterator (Form Iterator and How It Should Be Cooked ) I’ve provided couple use cases. However, since then I’ve seen some more common requirements on SCN. Which sometimes end with suggestions like ‘Build the form completely yourself’ or ‘Take xml_config and modify it with ABAP’ or ‘It’s not possible’.

My previous blog may confuse someone. It’s because ‘wrapping’ solution (which was taken as an example and not as ‘fits-all’ solution) doesn’t always work. For example, it won’t work for input fields in edit mode etc. Due to some reasons unfortunately, I’ve missed those discussions and caught them too late or participated in them not enough to provide a complete solution.

Now I’m trying to correct myself. And here is what I’d like to propose.

Starting from Ehp1 SAP CRM allows defining CSS files easily. Please refer CSS Files and JS Files – User Interface Personalization – SAP Library

IMG entry for this is:

SPRO -> Customer Relationship Management -> UI Framework -> UI Framework Definition -> Skins and Icons -> Define Path for CSS Files.

Please read the help document for this IMG entry before uploading CSS file to MIME repository to make it clear where we need to upload a file depending on a path type used: absolute, relative or local.

Why not to take such an opportunity and use it?

Let’s assume we create a CSS file with the content:


.zth-greencolor {
    background-color: rgb(122, 255, 122); /* green */
    border-color: rgb(0, 176, 23);
    color: rgb(0, 0, 255); /* blue */
}


Here we define a class with background color, border color and font color.

Then following the help topic mentioned above, we upload it to the appropriate place in MIME repository and define it in SPRO.

css file place in MIME repos and settings.png

After that, it’s good to refresh server cache and local workstation cache.

Then we come again into our form iterator defined and set in some WebUI form (which is represented by chtmlb:config element).

Right now we set newly created CSS class for input field.


DATA: lr_inputfield TYPE REF TO cl_thtmlb_inputfield.
   IF iv_binding_string = '//HEADER/STRUCT.FIRSTNAME'
     AND iv_element_name = 'inputfield'.
     TRY .
         lr_inputfield ?= iv_element_bee.
         lr_inputfield->cssclass = 'zth-greencolor'.
         ev_replacement_bee ?= lr_inputfield.
       CATCH cx_sy_move_cast_error.
     ENDTRY.
ENDIF.


And we can see the result.

screenshot result1.png

Additionally we can define other entries in our CSS file to meet some special requirements.


/* works for non-mandatory input fields or error-free mandatory input fields */
.zth-greencolor {
    background-color: rgb(122, 255, 122); /* green */
    border-color: rgb(0, 176, 23);
    color: rgb(0, 0, 255); /* blue */
}
/* works only for mandatory input fields with errors */
.th-onerror .th-if.zth-yellowcolor {
    background-color: rgb(255, 255, 122) !important; /* yellow */
    border-color: rgb(0, 176, 23) !important;
    color: rgb(0, 0, 255) !important;
}
/* with and without error in mandatory inputfields */
.th-if.zth-pinkcolor {
    background-color: rgb(255, 122, 255) !important; /* pink */
    border-color: rgb(0, 176, 23) !important;
    color: rgb(0, 0, 255) !important;
}
/* enlarge label and text view */
.zth-lb-enlarge {
    font-size: 24px;
}


The result:

tripple result.png

Luckily, SAP provides ‘cssclass’ attribute for input field tag (thtmlb:inputfield). But it’s missed in such elements as labels (thtmlb:label) and text views (thtmlb:textview). The last one represents input fields in view mode. In standard, we can influence the style of these tags only using ‘design’ attribute. Which is then converted to certain CSS classes. There is also ‘size’ attribute available for text view tag. But I didn’t manage to find any footprints that it’s handled in the tag. Certainly, we can use ‘wrapping’ mechanism in this case. But there are some restrictions. Because of the fact that BSP elements may actually be represented as a couple of nested html tags. For example increasing font size with wrapping mechanism works only for text views (e.g. input fields in view mode) and doesn’t work for labels. Therefore, I personally prefer the same approach as for input field described above. The solution is to create two z-BSP elements, which are enhanced with the appropriate functionality.

The steps for this are below:

We need to have already created BSP extension. Let’s say ZZTHTMLB (we create it in se80 and provide ZZTHTMLB as a name and as a default prefix here; give the Short text as you like).

Then we go to BSP extension THTMLB and copy ‘label’ BSP element into our own BSP extension (keeping the name of the tag the same). Activate everything (I assume below that you know when you need to save and activate your work, so I will not repeat it each time).

We receive such a tag.

screenshot tag1.png

Go to Attributes tab and add a new attribute:

screenshot attribute zcssclass.png

Then in se24 create a new element handler class. I choose ZCL_ZZTHTMLB_LABEL as a name. It’s a simple class, which inherited from CL_THTMLB_LABEL.

Add an attribute:

screenshot class attribute zcssclass.png

Then redefine IF_BSP_ELEMENT~DO_AT_BEGINNING method and adjust it with the following statement (in my current system Ehp2 SP9 it’s a line number 107)


  IF me->mc_accessibility IS INITIAL AND me->wrapping IS INITIAL.
    CONCATENATE out_string ' th-ellipsis'    INTO out_string.
  ENDIF.
* Z-enhancement: add css style if provided
  IF me->zzcssclass IS NOT INITIAL.
    DATA lv_cssclass TYPE string.
    lv_cssclass = cl_thtmlb_util=>escape_xss_xml_html( me->zzcssclass ).
    CONCATENATE out_string lv_cssclass INTO out_string SEPARATED BY space.
  ENDIF.
* end of Z-enhancement
  IF me->width IS NOT INITIAL OR me->wrapping IS INITIAL.


Change element handler class in ZZTHTMLB:label tag to this newly created class.

screenshot tag2.png

We can do the same for text view. It’s obvious that it should be a different element handler class (inherited from CL_THTMLB_TEXTVIEW). The only difference is that you need to concatenate your CSS class into html variable instead of out_string.


  IF me->wrapping IS INITIAL.
    CONCATENATE html ` th-tx-nowrap` INTO html.
  ENDIF.
* Z-enhancement: add css style if provided
  IF me->zzcssclass IS NOT INITIAL.
    DATA lv_cssclass TYPE string.
    lv_cssclass = cl_thtmlb_util=>escape_xss_xml_html( me->zzcssclass ).
    CONCATENATE html lv_cssclass INTO html SEPARATED BY space.
  ENDIF.
* end of Z-enhancement
  CONCATENATE html `" ` INTO html.
* Taking care of the WIDTH parameter through inline styling:
  IF me->width IS NOT INITIAL.


Now we’re ready. Let’s go to our form iterator and put the below coding for appropriate fields.


DATA: lr_label TYPE REF TO cl_thtmlb_label,
         lr_zlabel TYPE REF TO zcl_zzthtmlb_label,
         lr_textview TYPE REF TO cl_thtmlb_textview,
         lr_ztextview TYPE REF TO zcl_zzthtmlb_textview.
   IF iv_binding_string = '//HEADER/STRUCT.FIRSTNAME'
     OR iv_binding_string = '//HEADER/STRUCT.LASTNAME'.
     IF iv_element_name EQ 'label'.
       TRY .
           lr_label ?= iv_element_bee.
           lr_zlabel = zclg_zzthtmlb_label=>factory(
               design        = lr_label->design
               encode        = lr_label->encode
               for           = lr_label->for
               id            = lr_label->id
               labeltype     = lr_label->labeltype
               required      = lr_label->required
               switchid      = lr_label->switchid
               text          = lr_label->text
               textdirection = lr_label->textdirection
               tooltip       = lr_label->tooltip
               width         = lr_label->width
               wrapping      = lr_label->wrapping
               _text         = lr_label->_text ).
           lr_zlabel->zzcssclass = 'zth-lb-enlarge'.
           ev_replacement_bee = lr_zlabel.
         CATCH cx_sy_move_cast_error.
       ENDTRY.
     ELSEIF iv_element_name = 'inputfield'.
       TRY .
           lr_textview ?= iv_element_bee.
           lr_ztextview = zclg_zzthtmlb_textview=>factory(
             align         = lr_textview->align
             design        = lr_textview->design
             encode        = lr_textview->encode
             id            = lr_textview->id
             layout        = lr_textview->layout
             size          = lr_textview->size
             switchid      = lr_textview->switchid
             text          = lr_textview->text
             textdirection = lr_textview->textdirection
             tooltip       = lr_textview->tooltip
             type          = lr_textview->type
             width         = lr_textview->width
             wrapping      = lr_textview->wrapping
             _text         = lr_textview->_text
             _tooltip      = lr_textview->_tooltip
             _type         = lr_textview->_type ).
           lr_ztextview->zzcssclass = 'zth-lb-enlarge'.
           ev_replacement_bee = lr_ztextview.
         CATCH cx_sy_move_cast_error.
       ENDTRY.
     ENDIF.
ENDIF.


And here is the result:

screenshot result2.png

Hope this will help SCN members satisfy their requirements. Do not stop exploring for good!

Reference materials:

CSS Files and JS Files – User Interface Personalization – SAP Library

CSS Tutorial on W3Schools

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Jean-Yves Guyomarc'h

    Again, very impressive and useful 😉

    Now you know the ins and outs of the WEBCUIF framework. I was wondering, did you ever compiled a list of the features or changes that you would like to see in WEBCUIF? I would really be interested in that.

    Regards,

    JYves

    (0) 
    1. Andrey Vishnevskiy Post author

      Hello, JYves!

      Thank you for the feedback 🙂

      It’s a good question. Should think of such a list. What to come to my mind right now are: personally I’d prefer to have more flexibility. I mean it’d be great to apply custom css easier then I’ve described it in the blog post. For example, I only covered labels and text views. But doing the same for dropdowns is more complicated.

      Also I hope SAP provides hovercard framework ‘out-of-the-box’ in the future.

      Another one: I’ve seen in the recent UI roadmap that in Ehp3 there is “Conditional formatting for Tables” (see page 24) available. But I didn’t find any news in help.sap.com on this topic. Neither in release notes. I will deal with a system on Ehp3 level in a couple weeks. Will see.

      UI Theme Designer theming support for WebClient UIF will be nice too.

      Definitely, it should be a list… 🙂

      (0) 

Leave a Reply