July 2007

Exclude Certain Message-Resource Keys From Struts Localization

While Struts isn't the latest, coolest Java web framework, it certainly is one of the most widely used ones. And it has proven to be solid and reliable in many, many projects. However, once in a while you need some feature that even a framework with some years of history does not offer out-of-the-box. Fortunately, Struts can be extended easily.

For a Struts & Common Controls project I needed the possibility to exclude some message-resource keys from localization, because the "key" strings were loaded from a database and had to be used literally. Most of the keys had to be looked up (i.e. localized) from the resource bundle, still.

In the end I decided to write my own, small MessageResourcesFactory that simply does not localize keys that start with the prefix "nokey!". Instead, such key strings are returned literally (without the "nokey!" prefix).

If you happen to need something similar, download the small archive here (provided "as is" without any warranties, use it at your own risk!) and activate the new MessageResourcesFactory in your struts-config.xml as follows:

<message-resources factory="de.snailshell.struts.MessageResourcesFactory" parameter="MyResources" null="false" />

[Update] Not really well documented... But from Common Controls 1.6 on you can exclude any resource key from localization by simply adding a "#" prefix. I'm not sure if I like the "#", though, because it might get in conflict with EL variables from the Unified Expression Language. So I think I'll stick with the "nokey!" prefix.

iCab 3.0.3 Beta 457

Yesterday Alexander released yet another iCab beta version:

• In HTML Image maps the attribute shape="default" was not processed correctly. Only if the "COORDS" attribut was present this was handled correctly, though the "COORDS" attibute is not used in this case.
• Under MacOS 8/9 (native, not in the "classic" environent of MacOSX) oversized popup menus in web pages with many thousands of menu items could crash iCab because of an internal size limit of 32K for menu structures in the MacOS. That means native MacOS 8/9 can not handle menus which needs more than 32 KB of memory internally. iCab did try to clalculate the approx. memory usage of a menu, but this didn't always work, probably because of the usage of Unicode which may require twice as much memory for the menus as well. iCab will therefore will limit the number menu items under MacOS 8/9 even more so such large menus won't crash anymore.
• Under MacOSX the OpenTransport call OTIdle() won't be used anymore because this call is probably responsible for some of the crashes.

iCab 3.0.3 Beta 455

Today, Alexander released iCab beta 455. The latest betas are available for registered users only, but let's hope that there will be a new public version before the current public version becomes one year old at the end of August...

The new beta version contains bug fixes as usual - and lots of compatibility fixes for other browsers' quirks:

• Unknown HTML attributes in the EMBED tag are no longer reported as error, because these attributes are treated as parameters for the plugin.
• If JS code tries to split text nodes at a location that lies beyond the text boundaries iCab doesn't always return an index error anymore. Some web sites don't work anymore if iCab would return an error in this error condition.
• iCab now supports the "onscroll" and "onmousewheel" events (JavaScript).
• IFRAMEs do now always get an HTML document assigned to, even if the web site defines the IFRAME without an document (the "SRC" attribute is not defined). Some web pages don't work anymore if an empty IFRAME element doesn't have a complete HTML document, because they try to access the non-existing document before(!) they define the document for the IFRAME (and other browsers do allow this).
• iCab internal threads are no longer connected so closely, hopefully this will fix some of the crashes.
• In "Quirks" mode iCab ignores that the CLASS attribute in HTML has to be treated as case-sensitive, because some web pages also don't case about this and won't look right if iCab would follow the web standards here.
• In general a <input type="image"> without NAME attribut can not be a "successful control", which means that the value of this button is never included in the form data when the form is submitted ("successful controls" must have a NAME attribut). But there're web pages which nevertheless require that for this special case (<input type="image">) the value is included using the names "x" and "y" (which can be a problem if these parameters would be used in other elements of the form. But other browsers are doing this as well, so iCab mimics the (wrong) behaviour of the other browsers as well.
• "list-item" elements which are declared as "float" using CSS are no longer treated as "list-item" element.
• Added a workaround for web pages, which try to open an URL which conatins characters that are not allowed in URLs.
• Atom feeds will be now also listed in the RSS Icon popup of the staus bar.
• If iCab was launched the very first time on the Mac and no other web browser was launched before on this Mac, iCab would hang. iCab looked for bookmark files of other browsers to offer that these bookmarks can be imported in iCab. But this didn't work correctly, if no other bookmarks were found.
• For "hover" effects using CSS rules iCab has always tested if the "hover" effect does require to layout the document again (if the size of an element changes) or if it is enough to redraw a certain element (for example if only the color changes). But sometimes iCab did even layout the page again, even if this was not really necessary.
• Added a workaround for a bug in MRJ (Java for "Classic" MacOS). If a Java applet opens a web page in a certain target frame or window, iCab did use a certain "unicode-aware" MRJ function to ask for the target. Unfortunately MRJ only returns garbage when it should return Unicode text. Now iCab uses the non-unicode functions to ask for the target.
• Added a workaround for badly written JavaScript menu libraries, which assume that the Browser would never use the actual visibility state of HTML elements if the state is changed within an event handler.
  The problem: Hovering over an area "A" will open another area "M" the menu. Then the user would normally move the mouse over the menu "M" so select a certain menu item. To programm this, one would write code for onmouseover and onmouseout event handlers. When moving the mouse over "A" "M" must be made visible. When leaving "A" without moving the mouse over "M" the menu "M" must be closed again. And also while the mouse is over "M" the menu "M" must be kept open.
  There's a menu library in the web, which only defines the following rules.
  • mouse over "A": make "M" visible
  • mouse leaves "A": hide "M"
  • mouse over "M": make "M" visible
  • mouse leaves "M": hide "M"
  But must not be working (even it does in other Browsers) because of the follwoing situation: The user moves the mouse from "A" to "M" (which is what the user will do to use the menu). Here one my thing that two events will occur: "A is left" and "the mouse is over M". But this is not always true. It depends on the order the events will be generated and delivered.
  In case the event "A is left" is generated first, this will close the menu "M" and then the mouse can no longer be over "M" and the second event will never occur. The menu will close as soon as the mouse leaves "A". In case the event "mouse is over M" is created first, the menu will stay open until the event "A is left" is delivered (which will be directly after the first event was delivered), and because this event will close the menu, the result is the same: The menu will close as soon as the use moves the mouse from "A" to "M". the menu won't work at all.
  In other browsers the menu stays open, though this is wrong (see above). iCab now follows the bahaviour of the other browsers, even this doesn't really make sense.