Skip to main content

Cloning your Corporate UI with HTML DB - Part VI (Re-Post)

The following is a re-post of the "Cloning your Corporate UI with HTML DB" series that I blogged about back in 2005 on the now-defunct Orablogs site. Most of the content and advise is still the same today, and has been reposted here exactly as it was on the old site.

July 12, 2005

What's the best way to ensure that you have more work to do? Use a statement like "That about wraps up this series" in your "final" posting in a series!

As Earl Lewis pointed out, things are not 100% correct when using MSIE. Now, there's a very simple cut-and-dry solution to this problem: Don't use MSIE. However, for those who have not yet made the switch to Firefox yet (which, according to traffic on HTML DB Studio is still about 80% of you), you will also see this error. Thus, it is critical that you test your site in both - if not more - browsers. This is something which I simply forgot to do.

It's as simple as this: the same HTML can and often will look different in MSIE & FireFox (and other browsers). It is time very well spent running through each and every page in each browser which you expect your users to use, in order to ensure that all pages render correctly. Nothing infuriates me more than a site which only renders correctly on MSIE!

The core problem here is some abandoned JavaScript calls & references, left over from when I gave up on the Dynamic OTN Menus. I took a few minutes to remove all of them, and MSIE is once again, quite happy. Ironically, I had to the use the JavaScript debugger in FireFox to determine which reference was still hiding in the source, as the messages generated by MSIE are very vague. I encourage you to check out the FireFox JavaScript debugger - it's quite nice for a browser add-in.

Looking around some more, I noticed that the titles on the Application Detail pages are not rendering correctly in MSIE either:

Let's take a look at the Report Template to see what HTML is being generated. Here is the relevant snippet:

<table width="100%" class="bodycopy">
<tr>
<td colspan="3" class="OTNHeadline">#NAME#</td>
</tr>

Looks like the table has a class called bodycopy associated with it, and the title has a class called OTNHeadline associated with it. The class bodycopy will be applied to all items in the table, as it is defined at the table level. When the #NAME# token is rendered, it will first have the bodycopy class associated with it, but it will override any directive set by bodycopy with those set in OTNHeadline. Those attributes not mentioned in OTNHeadline will retain their values as per their definition in bodycopy.

Let's take a look at bodycopy first, as that is what gets applied to the text first:

.bodycopy { color: #000000; font-size: 12px; font-family: Arial, Helvetica, sans-serif; line-height: 14px; text-decoration: none; visited: #000000 }

Looks like quite a few things are set here: color, font size, font, link style & color, and something called line-height. According to htmldog.com, line-height "Specifies the height of a line of text." So if it is set to 14px as per the above class, and then apply the OTNHeadline class:

.OTNHeadline { font-family: Arial Narrow, Arial; font-weight: bold; font-size: 30px; }

Since there is no definition for line-height, the value of 14px set by bodycopy is retained. This causes something to get chopped off at the top & bottom, as we're trying to render a 30px font in a 14px space. Thus, all I have to do to fix this is change the class definition of OTNHeadline to this:

.OTNHeadline { font-family: Arial Narrow, Arial; font-weight: bold; font-size: 30px; line-height: 30px; }

Reload in MSIE, and things look much better now:

This is just one of many examples of how different browsers render the same HTML. I can assure you that this is the norm, not an exception.

Once again (knocking on wood), that about wraps up this series...

Comments

Popular posts from this blog

Custom Export to CSV

It's been a while since I've updated my blog. I've been quite busy lately, and just have not had the time that I used to. We're expecting our 1st child in just a few short weeks now, so most of my free time has been spent learning Lamaze breathing, making the weekly run to Babies R Us, and relocating my office from the larger room upstairs to the smaller one downstairs - which I do happen to like MUCH more than I had anticipated. I have everything I need within a short walk - a bathroom, beer fridge, and 52" HD TV. I only need to go upstairs to eat and sleep now, but alas, this will all change soon... Recently, I was asked if you could change the way Export to CSV in ApEx works. The short answer is, of course, no. But it's not too difficult to "roll your own" CSV export procedure. Why would you want to do this? Well, the customer's requirement was to manipulate some data when the Export link was clicked, and then export it to CSV in a forma

Refreshing PL/SQL Regions in APEX

If you've been using APEX long enough, you've probably used a PL/SQL Region to render some sort of HTML that the APEX built-in components simply can't handle. Perhaps a complex chart or region that has a lot of custom content and/or layout. While best practices may be to use an APEX component, or if not, build a plugin, we all know that sometimes reality doesn't give us that kind of time or flexibility. While the PL/SQL Region is quite powerful, it still lacks a key feature: the ability to be refreshed by a Dynamic Action. This is true even in APEX 5. Fortunately, there's a simple workaround that only requires a small change to your code: change your procedure to a function and call it from a Classic Report region. In changing your procedure to a function, you'll likely only need to make one type of change: converting and htp.prn calls to instead populate and return a variable at the end of the function. Most, if not all of the rest of the code can rem

Logging APEX Report Downloads

A customer recently asked how APEX could track who clicked “download” from an Interactive Grid.  After some quick searching of the logs, I realized that APEX simply does not record this type of activity, aside from a simple page view type of “AJAX” entry.  This was not specific enough, and of course, led to the next question - can we prevent users from downloading data from a grid entirely? I knew that any Javascript-based solution would fall short of their security requirements, since it is trivial to reconstruct the URL pattern required to initiate a download, even if the Javascript had removed the option from the menu.  Thus, I had to consider a PL/SQL-based approach - one that could not be bypassed by a malicious end user. To solve this problem, I turned to APEX’s Initialization PL/SQL Code parameter.  Any PL/SQL code entered in this region will be executed before any other APEX-related process.  Thus, it is literally the first place that a developer can interact with an APEX p