Form iterator. Reviewing mistakes.
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.
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.
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:
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.
Go to Attributes tab and add a new attribute:
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:
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.
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:
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
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
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... 🙂