4 Replies Latest reply on May 17, 2018 1:17 AM by VANJ

    Static LOV template - Use in IR column

    VANJ

      https://apex.oracle.com/pls/apex/f?p=134181:14

       

      I don't recall where I saw this nifty technique demonstrated but when displaying a LOV-based page item, the Globalization Template on the Shared Component > List of Values > Static Values can be used to use Font APEX icons to render the display values.

       

      This works very well for page items but when the same LOV with the same data is used in an IR column with type Plain Text based on List of Values, the globalization template appears to be ignored and the display value is shown on the report instead.

       

      I like this technique because it has a very clean separation of content and presentation instead of embedding styling in the report SQL and constructing the markup with #COL# substitutions in the column HTML Expression

       

      Am I missing something? Is there a way to make this work in an IR column?

       

      Thanks

        • 1. Re: Static LOV template - Use in IR column
          fac586

          VANJ wrote:

           

          https://apex.oracle.com/pls/apex/f?p=134181:14

           

          I don't recall where I saw this nifty technique demonstrated but when displaying a LOV-based page item, the Globalization Template on the Shared Component > List of Values > Static Values can be used to use Font APEX icons to render the display values.

          Would you care to provide an explanation as well as a demonstration? The help text for that attribute appears to have been written by the person responsible for those on the classic report break formatting options...

          • 2. Re: Static LOV template - Use in IR column
            VANJ

            The demonstration link on apex.oracle.com was already in my original post. The Shared Components > LOV definition is here

             

            As the help text for the Globalization Template attribute says (sic), Use this optional template when developing list of values entries that need to be translated, and you wish to simplify the translation text. Use the #DISPLAY_VALUE# substitution string. The display value will be this attribute with the display value substituted for all occurences of the substitution string #DISPLAY_VALUE#.

             

            So it would appear that the attribute has been (cleverly IMHO) been used for a purpose other than what it was designed for (translation) which probably explains why it is not quite working as expected in an IR column.

            • 3. Re: Static LOV template - Use in IR column
              fac586

              VANJ wrote:

               

              The demonstration link on apex.oracle.com was already in my original post. The Shared Components > LOV definition is here

              That's what I was trying following your first post, but I was just getting escaped HTML source displayed, until I set the Escape special characters security attribute on the form controls to No. I am of the opinion that the latter has more to do with what's going on than the LOV Globalization Template does...

              As the help text for the Globalization Template attribute says (sic), Use this optional template when developing list of values entries that need to be translated, and you wish to simplify the translation text. Use the #DISPLAY_VALUE# substitution string. The display value will be this attribute with the display value substituted for all occurences of the substitution string #DISPLAY_VALUE#.

               

              So it would appear that the attribute has been (cleverly IMHO) been used for a purpose other than what it was designed for (translation) which probably explains why it is not quite working as expected in an IR column.

              I have read the help about 25 times and I still don't see how it would be used to simplify translation. Like the infamous report break formatting help, including some examples would make this infinitely more instructive. Maybe I just don't have enough experience of the translation process. Do you have any idea of how it would be used for its intended purpose?

              This works very well for page items but when the same LOV with the same data is used in an IR column with type Plain Text based on List of Values, the globalization template appears to be ignored and the display value is shown on the report instead.

               

              I like this technique because it has a very clean separation of content and presentation instead of embedding styling in the report SQL and constructing the markup with #COL# substitutions in the column HTML Expression

               

              Am I missing something? Is there a way to make this work in an IR column?

              After the idea was proposed in this thread, I drove myself daft for a month trying to get LOV generated Font Awesome/APEX icons to display in IR Plain Text based on List of Values columns. Those efforts obviously pre-dated the introduction of the Globalization Template attribute, so the icon HTML was generated as the display value of the LOV entries. This worked fine in classic reports, but it was always escaped in IR columns. I tried static and dynamic LOV definitions, strange undocumented hacks (completely ineffective in my experience), column substitutions into HTML Expressions, and got nowhere.

               

              Months later while doing something else, I had a sudden moment of insight, and realised I had found a working approach, by which time the original discussion was archived.

               

              The solution is frustratingly simple: set the HTML Expression on the LOV report to #COL!RAW#, where "COL" is the column alias.

               

              Unfortunately that results in HTML code appearing in filter values in the column headers and report control panel. If the clever person you allude was more interested in the possibilities of including icons in form controls than they were in reports, they may have chosen to use the Globalization Template rather than the display value because it is not subject to this problem? However, that begs another question. If the Globalization Template is intended to be used as an aid to translation, why wouldn't it be used in IR LOV columns? I think that might be a bug.

               

              It's also still subject to the bête noir of all LOV hacks: select lists are based on LOVs and select list values cannot contain HTML elements.

              • 4. Re: Static LOV template - Use in IR column
                VANJ

                I am of the opinion that the latter has more to do with what's going on than the LOV Globalization Template does...

                 

                You may be right. After a lot of searching, this would appear to be the blog post I had in mind that demonstrates this technique but I don't see any screenshots and neither is the phrase Globalization Template mentioned which makes me think the feature has changed from then until now and that the clever person was indeed demonstrating the technique in the context of a page item/form control and not a report column.

                 

                Maybe I just don't have enough experience of the translation process. Do you have any idea of how it would be used for its intended purpose?

                 

                Nope, I have exactly zero knowledge or experience of translation in APEX. All I know is that it is supported, as evidenced by the various language links at the bottom of the APEX Builder landing page which seem to add  &p_lang=XX to the f?p= URL to trigger the translated version of the application.

                 

                Your insight of using the (new in 5.0) extended syntax for substitution strings is a good idea, need to play with it some more.  Yes, I agree that regardless of its intended usage, the fact that the Globalization Template attribute for a Static LOV is ignored when used in a IR column displayed as Plain Text (based on list of values) is clearly a bug.

                 

                Regarding column filters, I guess we could either a) Use Defined List of Values to filter exact match and use select val1 from dual union all select val2 from dual ... so that the column header filter LOV shows the return values and not the HTML tags or b) punt and disable the column filter (Type = None). I chose (b) because (a), while it looks good, doesn't work because, as you put it, the bane of our existence for LOV-based items is that the user sees the display value but the underlying data contains the return value. Using Actions > Filter > Column contains xxx (which is what I did in my example) is probably an acceptable compromise as long as the HTML markup really contains some fragment of the value the user would search for.

                 

                Even with all these limitations, I still find myself attracted to this technique because the alternative (embedding CSS classes in hidden columns in the report SQL and using them to construct appropriate HTML Expressions) leads to bloated SQL, violates separation of presentation and content and is just plain ugly code. Disclaimer: I have not considered the performance aspect of the Plain Text (based on list of values) column type, it seems to be mapping the return value to the display value pretty efficiently.

                 

                joelkallman-Oracle would you mind reviewing this discussion?