> S. Isaac Dealey wrote: >> Well I'm always hopeful. :P Trying to create something >> that can _potentially_ scale back to CF5 without >> changing the implementation
> i'd rather have a sharp stick in my eye than deal w/a > lot fo java in cf5. porting geoLocator from mx to cf5 > took 3 times as long as it did to write the thing in > the first place. Well I'm not actually planning to use this stuff with CF5. :) Just wanted to try and create something that would allow someone to "hook into" CF5 if they needed it for what reason I have no idea. It would also (in theory) allow someone to use an application which has been designed to be Java i18n compatible in a single locale by supplanting the i18n functions with the stock/native coldfusion functions. If they later upgrade to CFMX and need the i18n functionality it would then be easy to remove the functions they'd used under the backend to revert to the java features without modifying any of the framework's core code. >> code for an application and never wanting to require >> someone to have access to the WEB-INF directory so >> that it supports shared-hosting. > you can get at most core java dependent classes via > reflection. I was hoping to implement something like the java class you provided with the general-purpose i18n CFC (the one that includes general number/date functions) as a jar which could be attached to via a relative file path (like the geoLocator jar) instead of requiring access to the WEB-INF. >> easily swap out their own implementation of number >> formatting for any given locale or for all locales >> application-wide simply by creating the >> appropriately named function. > i think we've been over that ground before. having > somebody override core java or icu4j locale formatting > resources is not a good idea. quite a bit of thought & > research goes into these things (especially icu4j 3.2 > and beyond now that it's based on the CLDR) & i'm willing > to bet a beer something's going to go badly (think about > the parsing issues you'll have). me, i'd rather be > standard than right ;-) I generally agree. :) At least I generally agree when it comes to CF/Java and i18n. Though asside from the above (temporarily downgrading away from i18n if needed), supplanting the core implementation also doesn't necessarily mean moving away from Java - it may only mean moving to ICU4J or simply their own implementation of the Java features if they felt that my implementation wasn't correct or wasn't efficient enough, etc. Even without checking for these functions it's possible to replace the stock implementation in the framework core by replacing the cached function after the application initializes the function libraries, although that approach is slightly more involved. s. isaac dealey 954.927.5117 new epoch : isn't it time for a change? add features without fixtures with the onTap open source framework http://macromedia.breezecentral.com/p49777853/ http://www.sys-con.com/story/?storyid=44477&DE=1 http://www.sys-con.com/story/?storyid=45569&DE=1 http://www.fusiontap.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware: a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:191119 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
