Collapsed Tabular Form Heading when "No data found".

Question

The ' Collapsed Tabular Form Heading when "No data found" ' problem (speculated to be bug 9893564) is discussed here: {message:id=4419231}. Warning link is out of date. I'm still seeing it in APEX 4.2.
I support Kelly's comments "looks like something is broken" and "Now this header (which is sized smaller before data is retrieved) comes between the search items and the help message and looks clumsy.".{message:id=9185914}.
Any suggestion to get around it when no data is found?
1) Is there a way to hide the header when there is no data? Or,
2) Is there a way to adjust the width of the columns if the header must display? I'd like them to be about what they are when data is displayed. I know those lengths but not how to affect the header width for a tabular report with no data.
Example:
WS APEX_EXAMPLES_01
demo
demo
Appl 78329 Tabular Form - page 1. (I forced query not to find any data for demo purposes.)
Thanks,
Howard

Answer 1

Howard (... in Training) wrote:
Paul --
Great! So many new techniques here -- new to me. Generally, I much prefer positive logic as well. But this solution seems to have more pieces than the other.There is method in that.
Firstly, with Aljaz's approach you can see a flicker as the tabular form is actually rendered and then hidden when the script in the footer is eventually run. This will be more apparent with a longer or more complicated page where it takes longer to reach the script and more content needs to be adjusted following removal of the form. Reversing the logic and hiding the form using CSS in the page header prevents this as the form elements are initially created as hidden nodes in the DOM before any of the page is rendered.
More important is that this approach applies the principles of the separation of concerns and unobtrusive JavaScript. At some point when developing in APEX you're going to find yourself seriously losing your cool in a situation where you know the app is executing some JavaScript, but you can't find where that script is defined (maybe you've already been there). Look at the page 2 definition using the tree view: where's the JavaScript that is going to run? Now look at page 1: ah, there are a couple of dynamic actions...
APEX now includes a lot of containers specifically for JavaScript: File URLs, Function and Global Variable Declaration and Execute when Page Loads in page templates and page headers, and declarative and custom Execute JS Code Dynamic Actions. These provide for good separation of concerns: we should use these locations for JS code, and avoid the exasperation of hunting through templates, page/region headers/footers, page 0 regions, pre-/post-element text or wherever to find the script we can see in the page source or JS debugger.
Aljaz's solution also depends on detecting the presence of the No Data Found message with class <tt>nodatafound</tt>, and on modifying the Add Row button.
What if someone changes the class of the No Data Found message in the report attributes? The Exists... condition on the dynamic action performs this check in a more direct way (although it's not ideal: DRY is violated by having both 2 copies and 2 executions of the report SQL; nor is it reusable on other form regions).
Modifying the Add Row button JavaScript directly is intrusive. Like footers and templates, it's another non-obvious location for JS customisation. By using a dynamic action to bind another click handler to the button we're making the modification more obvious, and more importantly we don't have to modify what it's already doing&mdash;or in this instance, even care what that is (in other circumstances we might need to change the order or propagation of events, or suppress the original behaviour).
As for reusability, my original solution didn't really consider this (as it wasn't mentioned in the OP). Since the subject has been raised, and in accordance with my comments above, I'd approach it in a different way.
As discussed, I suggest not squirrelling JavaScript away in region templates. I'd create a reusable report template for tabular forms rather than a region one. A <tt>class</tt> defined on the report container there will provide a more direct selector for hide/show behaviour. I'd stick to initially hiding this report via CSS, and use dynamic actions defined on the global page to conditionally show it on page load and bind show behaviour to the Add Row button click. To make these DAs reusable I'd remove the Exists... condition from the first one and replace it with a JS condition that checks to see if the tabular form report contains any visible data rows (the class on the report template will help there as well). Binding the show behaviour to the Add Row button would use the <tt>onclick</tt> attribute as a selector (rather than an ID selector that requires an intrusive edit of the button) so that all Add Row buttons would be affected: <tt>$('button[onclick^="apex.widget.tabular.addRow"]')</tt>.
And about the style code:
#report_tabular-form,
#report_tabular-form .report-standard {
min-width: 90%;
} That is an improvement. I had read about it but not considered it for this. I tried the technique used to adjust column width on other reports but when I use "div," it makes the data in that column display only. I really want to adjust the width of the individual column header. Is there a way to do that?I'm not really clear what you're asking here. (Use "div"? Where? How?)
To control the width of individual report column headers, use the following CSS:
th#COLUMN_ALIAS {
  width: 10em;
}Where <tt>COLUMN_ALIAS</tt> is the alias of the column in the query: APEX uses this as the HTML <tt>id</tt> attribute for the column table header element. (Note that <tt>id</tt> attributes must be unique within a document, so it the same column appears in multiple reports/forms, ensure each column alias is unique.)