August 26, 2003

resourceBundleCFC

i've been using resourceBundles in one form or another for some time now. while my idea of resourceBundles is not always confined to file based resources, i have had a UDF--now CFC--resourceBundle file function for a time now. mainly because getProfileString's never properly handled unicode--cf really needs a native resourceBundle-like function. on the off chance somebody's wondering, a resourceBundle is a file holding text label key/value pairs seperated into locale files--the reason for this is to completely seperate text from code and text presentation. for instance: testMsg_th_TH.properties (thai locale) contains welcomeMSG=สวัสดีคะ while testMsg_en_US.properties (american locale) contains welcomeMSG=Well hello there. the application would determine which locale was required (session or application based depending on how you rolled out your application) and then load the relevant resourceBundle. the welcomeMsg text label would then show up in the proper language. simple, easy, scalable. in any case, i've put the resource file CFC in the devnet gallery (should be available sooner or later). you can see an example and download it here if you're in a hurry to trash it. again wandering off-topic, i've been trying to make use of native java resourceBundle (getBundle, etc.) functionality with cf, no dice so far. getBundle never seems able to find the resourceBundle. no idea if this would function any better than the way i'm doing it now but i' sure like to find out. any ideas?

posted by Paul Hastings @ 9:45 PM 0 comments

OT: warren zevon still has sand

a full year after being told he had 3 months to live (terminal lung cancer), warren zevon's released another album. the man has sand.

posted by Paul Hastings @ 1:15 AM 0 comments

August 22, 2003

aw, shucks.

rob brooks-bilson been telling tall tales about me over on cfcZone.org though i think perhaps rob's just being facetious ;-)

posted by Paul Hastings @ 12:53 PM 0 comments

the devil's in the i18n details

when i start into making an application i18n, the normal course of discussion opens with a statement from the client on they had done such a [insert adjective here] job concerning seperation of text from code and from text presentation. the reality's usually nowhere near as good or bad as they make it out to be. i recently got involved in a "port and improve" project where the same sort of claims had been made but to my surprise the original developers had actually done a super-terrific, bang-up job completely seperating text from code and presentation. they had moved all the app's text into an include file, just ripe for localization. and in case you're wondering yes it scales pretty good--while this is an admin application and speed/loading's not such a big deal, it did handle the modest load tests i tossed at it. swell. but the fly in this ointment was the way they had chosen to handle this--rather than human understandable labels they used array locations (this is a straight port to CF from the original JSP): <input type="button" name="startButton" value="#textList[59]#" onclick="startChecked()"> ok, you can probably guess that this label has something to do with starting something or other but at 2:00 am that kind of detective work gets old real fast. also imagine re-visiting this app in 2 years time--its the sort of thing that makes you want to put your forehead thru the monitor. a real maintainence nightmare. so, i'm in the process of retro-fitting these into something more "sustainable" using a structure to hold the text labels (say from textList[59] to textLabels.startMapServiceButton, yes i like verbose labels). the devil is in the details after all.

posted by Paul Hastings @ 12:24 AM 0 comments

August 07, 2003

tengwar is no joke

JD has blogged an article where he sort of jokingly refers to support for tengwar as the next item on the flash wishlist. i will take mild exception to that here ;-) in fact tengwar's been in the unicode pipeline since 1997. there is indeed a real proposal for tengwar and since its not yet been rejected, i'd say its not such a joke ;-) on the other hand, klingon (yes, really) was proposed around the same time and was however rejected (which i hear still rankles the klingons no end, they keep trying to stage WTO-like demonstrations at unicode conventions but fortunately they get too drunk to ever find the meetings).

posted by Paul Hastings @ 12:30 AM 0 comments

August 06, 2003

man bites dog...

nigel's updated the geoLocator IP database and i've tweaked the CFC code a bit (you no longer have to explicitly init the geoLocator component, it should be handled automatically now internal to the CFC). nigel's also updated the sourceforge site. the updated geoLocator CFC will be available "soon" from the mm devnet gallery. if you're in a rush, you can grab it from here. note that the InetAddressLocator class name has changed to "net.sf.javainetlocator.InetAddressLocator". if you don't know what the geoLocator's all about try this example. for those still using cf5, Uwe Degenhardt's maintaining cftools.sdsolutions.de which has this CFC as a cflib style file. interestingly, nigel's moved some of the CF functionality over into java--thats functionality that wasn't originally present in the java version, which is what i find interesting in a kind of "man bites dog" sort of way.

posted by Paul Hastings @ 9:27 PM 0 comments