[cfaussie] liotta effect (Was RE: [cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?)
That was too funny, Geoffbest laugh we've had here at the old CFers retirement community since...why...since we listened to the 8 track of Don Rickles last week. Or was it last year? Oh, here comes the orderly to give me my Geritol. :-) Seriously, though, I do kind of miss Matt (Liotta) on the lists. As you say, for the flaws in his email style, he was indeed very nearly always right. I can report too that I've seen him on and off in recent years here in Atlanta and he's definitely mellowed with age. Married now, and quite happy in home and work, last I saw him. /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Bowers Sent: Saturday, January 12, 2008 11:34 PM To: cfaussie Subject: [cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())? ... what the Methuselah amongst us would recognise as a Liotta Complex. ... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Nobody was talking about i18n, you were the first to bring it up. As far as the 2 functions they do exactly the same thing, the only difference one works in other countries outside of the USA and the other doesn't. On 1/13/08, Geoff Bowers [EMAIL PROTECTED] wrote: On Jan 10, 8:00 am, Andrew Scott [EMAIL PROTECTED] wrote: Actually Date Masking worked a treat in C+/C++ Date masking is not i18n. (let me guess you are changing the subject *again*) And as thats all the function does Geoff, I am amazed you took the time to even try to debate it. Once again there is no debate. Your form of argument involves changing your subject every post. Fact: cf5 byte code is not cf8 byte code. Analysing cf8 java output and making assumptions about engineering decisions made years earlier in a completely different language is idiotic. Look at the end of the day pressure of a release is high, but implementation is not. You casually imply the CF dev team are morons, and that there decisions are more about release pressure than good development. Although they're certainly not infallible, they have created a product of enormous value and lasting appeal. You cast aspersions with the flimsiest of excuses -- its an ugly habit. You're persistent i'm more intelligent than thou approach to forum posts annoys everyone. You have what the Methuselah amongst us would recognise as a Liotta Complex. The only difference being Liotta was nearly always right, whereas you are invariably arguing a point most of us no longer recognise. Perhaps I'm being too kind. -- geoff http://www.daemon.com.au/ -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 8676 4223 Mobile: 0404 998 273 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Nobody was talking about i18n in a round-a-bout way, I was (as the person who initiated the thread). The point that I was trying to make is that there were existing functions that help bring i18n to an app (and just as importantly as Haikal pointed out, localisation) As far as the 2 functions they do exactly the same thing, the only difference one works in other countries outside of the USA and the other doesn't. and if the LS ones work in all cases, is the other needed at all (or is it a bad practice which seeing it labeled as deprecated might help cure)? and to be perfectly clear, not removed to break old code, but to put it out to pasture and let it slowly fade into history... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
LOL, Which brings me back too Why there was an LSDateFormat, when they could have made the DateFormat do the extra work and not introduce extra functions? On 1/13/08, Barry Beattie [EMAIL PROTECTED] wrote: Nobody was talking about i18n in a round-a-bout way, I was (as the person who initiated the thread). The point that I was trying to make is that there were existing functions that help bring i18n to an app (and just as importantly as Haikal pointed out, localisation) As far as the 2 functions they do exactly the same thing, the only difference one works in other countries outside of the USA and the other doesn't. and if the LS ones work in all cases, is the other needed at all (or is it a bad practice which seeing it labeled as deprecated might help cure)? and to be perfectly clear, not removed to break old code, but to put it out to pasture and let it slowly fade into history... -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 8676 4223 Mobile: 0404 998 273 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
This has all been an intelligent discussion, but nobody has responded to the idiot American reference. Do you mean the idiot Americans that invented CF? Greg On Jan 7, 2008 1:20 AM, Owen West [EMAIL PROTECTED] wrote: or, we could just make idiot American's use the same date formats as the rest of the English-speaking world! or is that too harsh (methinks not, having been burned by Allaire/Macromedia/Adobe/Microsoft/Borland/the list goes on and on with regards to storing, interpreting and using dates across international boundaries). The whole thing makes me see red!! Owen West MCP MCAD MCSD Computer Programmer Applications Development Team Information Technology Telecommunications Hunter New England Health Ph: (02) 4921 4194 Fax: (02) 4921 4191 Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
if you're referring to Owen's comments, I think that was a reaction to differing standards that seem to be supported in the writing of CF applications (not core language). standards, don't ya just love 'em? there's so many to choose from** I still find it surprising that non LS functions are still being used after all these years. Part of the reason in starting this thread was to see if there was any technical reason NOT to use the LS functions (or whether it was a case of old habits dying hard) but that gets back to the point about software being written with only one locale in mind and problems that have been caused when that hasn't been considered/implemented/tested. IMHO, more important for future customers than i18n is localisation, whether it's conversion of prices to various currencies, the year to a non Gregorian calendar or even support for different languages with R-L text ... (... all of which are noble causes, but lets start with easy stuff like dates and go from there, eh?) ** as soon as I take over the world, we'll all be using ISO dates natively... and speaking Esperanto ... On Jan 13, 2008 11:46 PM, Greg Luce [EMAIL PROTECTED] wrote: This has all been an intelligent discussion, but nobody has responded to the idiot American reference. Do you mean the idiot Americans that invented CF? Greg On Jan 7, 2008 1:20 AM, Owen West [EMAIL PROTECTED] wrote: or, we could just make idiot American's use the same date formats as the rest of the English-speaking world! or is that too harsh (methinks not, having been burned by Allaire/Macromedia/Adobe/Microsoft/Borland/the list goes on and on with regards to storing, interpreting and using dates across international boundaries). The whole thing makes me see red!! Owen West MCP MCAD MCSD Computer Programmer Applications Development Team Information Technology Telecommunications Hunter New England Health Ph: (02) 4921 4194 Fax: (02) 4921 4191 Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
On Jan 10, 8:00 am, Andrew Scott [EMAIL PROTECTED] wrote: Actually Date Masking worked a treat in C+/C++ Date masking is not i18n. (let me guess you are changing the subject *again*) And as thats all the function does Geoff, I am amazed you took the time to even try to debate it. Once again there is no debate. Your form of argument involves changing your subject every post. Fact: cf5 byte code is not cf8 byte code. Analysing cf8 java output and making assumptions about engineering decisions made years earlier in a completely different language is idiotic. Look at the end of the day pressure of a release is high, but implementation is not. You casually imply the CF dev team are morons, and that there decisions are more about release pressure than good development. Although they're certainly not infallible, they have created a product of enormous value and lasting appeal. You cast aspersions with the flimsiest of excuses -- its an ugly habit. You're persistent i'm more intelligent than thou approach to forum posts annoys everyone. You have what the Methuselah amongst us would recognise as a Liotta Complex. The only difference being Liotta was nearly always right, whereas you are invariably arguing a point most of us no longer recognise. Perhaps I'm being too kind. -- geoff http://www.daemon.com.au/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
I wouldn't assume there was a reason. It sounds like you want to know why Adobe did it, and you will probably never find out why. Shoot, the guys who did it were back in the Allaire days, and most of the old CF coders are gone now. Even me (I worked on the structSort function believe it or not). It _would_ be kind of cool if we could get a hold of one of the engineers who was around in the old days (like I said, only 1 or 2 still exist, like Tom Harwood) and interview them about some of the thought processes behind how stuff was done. On Jan 9, 2008 1:41 AM, Andrew Scott [EMAIL PROTECTED] wrote: I think a few of you are missing what I am trying to say. I am still trying to confirm this 100%, but so far I have looked at the code and found that the code is in fact identical in both DateFormat() LSDateFormat(). The only difference that I can see is that LSDateFormat has a wrapper to the main code to use local, then calles DateFormat(). -- === Raymond Camden, Camden Media Email: [EMAIL PROTECTED] Blog : www.coldfusionjedi.com AOL IM : cfjedimaster Keep up to date with the community: http://www.coldfusionbloggers.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Sorry - I meant Tom Jordhal, Harwood was another old timer who is long, long gone. On Jan 9, 2008 9:14 AM, Raymond Camden [EMAIL PROTECTED] wrote: I wouldn't assume there was a reason. It sounds like you want to know why Adobe did it, and you will probably never find out why. Shoot, the guys who did it were back in the Allaire days, and most of the old CF coders are gone now. Even me (I worked on the structSort function believe it or not). It _would_ be kind of cool if we could get a hold of one of the engineers who was around in the old days (like I said, only 1 or 2 still exist, like Tom Harwood) and interview them about some of the thought processes behind how stuff was done. On Jan 9, 2008 1:41 AM, Andrew Scott [EMAIL PROTECTED] wrote: I think a few of you are missing what I am trying to say. I am still trying to confirm this 100%, but so far I have looked at the code and found that the code is in fact identical in both DateFormat() LSDateFormat(). The only difference that I can see is that LSDateFormat has a wrapper to the main code to use local, then calles DateFormat(). -- === Raymond Camden, Camden Media Email: [EMAIL PROTECTED] Blog : www.coldfusionjedi.com AOL IM : cfjedimaster Keep up to date with the community: http://www.coldfusionbloggers.org -- === Raymond Camden, Camden Media Email: [EMAIL PROTECTED] Blog : www.coldfusionjedi.com AOL IM : cfjedimaster Keep up to date with the community: http://www.coldfusionbloggers.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Actually Date Masking worked a treat in C+/C++ And as thats all the function does Geoff, I am amazed you took the time to even try to debate it. Look at the end of the day pressure of a release is high, but implementation is not. On 1/10/08, Geoff Bowers [EMAIL PROTECTED] wrote: On Jan 9, 6:41 pm, Andrew Scott [EMAIL PROTECTED] wrote: I am still trying to confirm this 100%, but so far I have looked at the code and found that the code is in fact identical in both DateFormat() LSDateFormat(). The only difference that I can see is that LSDateFormat has a wrapper to the main code to use local, then calles DateFormat(). So what I am saying is why was it done that way, the code cleary shows it setting DateFormat() with a default Locale of US. Whoa! I'm impressed you have the time to decompile, and analyse the C+ + code of CF5.0. (Because if you are not analysing that release or earlier then your argument with respect to the code being identical is irrelevant. Both functions pre-date the move to Java. And if you are looking at CF8 byte code you might consider that the addition of locale for dateformat() may be the only reason lsdateformat() has been refactored. It might also help to understand that i18n was a *little* bit harder to implement in c++ for the nineties than it is in Java for the late naughties. I'm sure you're right though -- all the engineers I've met on the CF teams over the years have been thoughtless morons (NOT!)) -- geoff http://www.daemon.com.au/ -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 8676 4223 Mobile: 0404 998 273 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
On Jan 9, 6:41 pm, Andrew Scott [EMAIL PROTECTED] wrote: I am still trying to confirm this 100%, but so far I have looked at the code and found that the code is in fact identical in both DateFormat() LSDateFormat(). The only difference that I can see is that LSDateFormat has a wrapper to the main code to use local, then calles DateFormat(). So what I am saying is why was it done that way, the code cleary shows it setting DateFormat() with a default Locale of US. Whoa! I'm impressed you have the time to decompile, and analyse the C+ + code of CF5.0. (Because if you are not analysing that release or earlier then your argument with respect to the code being identical is irrelevant. Both functions pre-date the move to Java. And if you are looking at CF8 byte code you might consider that the addition of locale for dateformat() may be the only reason lsdateformat() has been refactored. It might also help to understand that i18n was a *little* bit harder to implement in c++ for the nineties than it is in Java for the late naughties. I'm sure you're right though -- all the engineers I've met on the CF teams over the years have been thoughtless morons (NOT!)) -- geoff http://www.daemon.com.au/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Andrew, please be sure to read ALL Charlies (or anyone else's for that matter) response before posting again. Yep...the whole thing! It will help us all :) On Jan 8, 6:10 pm, Charlie Arehart \(lists account\) [EMAIL PROTECTED] wrote: Andrew, I know people hate to see these kind of debates drawn out, and I've been warned before not to be pulled into the web you weave :-), but I can't let you stand on your assertions. You say The code behind LSDateFormat is identical to DateFormat, the only difference is that LSDateFormat has a wrapper to call DateFormat and guess what DateFormat returns the default Locale. So my question is this, why? I can see that with the new argument locale, that could be the only reason behind it. Again, the function came out several years ago, before the addition of the new argument locale. All the discussion here yesterday was about how it works with SetLocale. I was the first to bring up the new locale functionality in CF8. So all the other folks here are clearly discussing (as they should) how the LS functions can be manipulated based on the SetLocale. DateFormat, as an example, cannot. They're not the same, dude! I think your Software Engineer point of view is clouding your perspective. Or others jump in. Am I missing something? Again, I prefaced my first note here by admitting that I'm no expert on localization. Many of you are. Is Andrew on to something here? Or missing the boat? And what about Barry and others earlier in the thread who brought all this up: have any of my points helped you? As for CFHTMLHEAD, again, I find your argument pretty specious. But please read me carefully before responding. I'm not debating your suggested enhancement. You accuse it of appearing to have ... been thrown in at the last minute, but again it's one of the oldest tags in CFML. You can complain that it doesn't do what you want (that seems your beef), but you can't argue that it was thrown together at the last minute just because it doesn't meet a need you see. Again, you're accusing the engineers of being stupid, and not foreseeing what you see is clearly a superior approach. I daresay no one has reconsidered that tag and its uses in the several years since it came out. Should they? Perhaps. That's where you can file an enhancement request, so it's good to hear that you have. (So you see, I'm not arguing that your proposed suggestion is specious--just the assertion about the tag being so brain dead. It does serve the needs for which it was originally created.) I only pressed this because you threw out the off-hand comment at the conclusion of your earlier note that this was another example of things in CFML that have been added without any thinking at all. I just think those kind of comments are incendiary and inappropriate. Again, we don't have insight into the many decisions that go on in the engineering team, whether when creating a tag/function or when modifying it. Do I always agree with them? Heck no. But that's what the betas are for. Get in there early and make your case known, as it seems you have. Just think twice about casting the aspersions (as I now see someone else said in that other forum that cannot be named which you hinted at). Really, you can make your point without that. :-) /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Scott Sent: Monday, January 07, 2008 5:58 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())? Sure, First things first I did not read your post in its entirety so the context of disagreeing with you, goes right out the window:-) But to keep the subject in its context, I do wonder what was going through the developers minds when they created the LSDateFormat and for what purpose. But I can tell you this. The code behind LSDateFormat is identical to DateFormat, the only difference is that LSDateFormat has a wrapper to call DateFormat and guess what DateFormat returns the default Locale. So my question is this, why? I can see that with the new argument locale, that could be the only reason behind it. Anyway, I speak from a Software Engineer point of view and I do not see any reason for 2 functions that technically do the same thing. Now let's talk about cfhtmlhead. While converting some of my extJS code over to coldfusion 8, I found that a lot of it broke with JS code couldn't be found. Yet there they are in the view source, so when I went investigating and did some further tests, the JS HAS to be in the html HEAD tag. So with that in mind I got told that is why this tag exists. So let's now look at why this is a hack at its best. To use this as it currently is one has to do this. cfsavecontent variable=Test ... Some JS code. /cfsavecontent cfhtmlhead text=#Test# Now I can't
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Charlie, I never knew about the cfhtmlhead tag, and made the assumption that it was added. However in my defence, I got told to use that to get what I needed done for the new Ajax UI in cf8. This came from people who should know how it works, regardless of when this tag was introduced. I do see a lack of forsight on the developers. There are many tags that are thought off, but not thought of properly. Whether this is the fault of the developers, or the alpha testers. But at the end of the day I have seen many tags / functions that have been not thought of properly. the cfhtmlhead is a typical example, why could they have not thought of its use fully back then:-) As far as from a software engineer point of view, what is the point in duplicating code? Why not factor / refactor properlly in the first place? On 1/8/08, Charlie Arehart (lists account) [EMAIL PROTECTED] wrote: Andrew, I know people hate to see these kind of debates drawn out, and I've been warned before not to be pulled into the web you weave :-), but I can't let you stand on your assertions. You say The code behind LSDateFormat is identical to DateFormat, the only difference is that LSDateFormat has a wrapper to call DateFormat and guess what DateFormat returns the default Locale. So my question is this, why? I can see that with the new argument locale, that could be the only reason behind it. Again, the function came out several years ago, before the addition of the new argument locale. All the discussion here yesterday was about how it works with SetLocale. I was the first to bring up the new locale functionality in CF8. So all the other folks here are clearly discussing (as they should) how the LS functions can be manipulated based on the SetLocale. DateFormat, as an example, cannot. They're not the same, dude! I think your Software Engineer point of view is clouding your perspective. Or others jump in. Am I missing something? Again, I prefaced my first note here by admitting that I'm no expert on localization. Many of you are. Is Andrew on to something here? Or missing the boat? And what about Barry and others earlier in the thread who brought all this up: have any of my points helped you? As for CFHTMLHEAD, again, I find your argument pretty specious. But please read me carefully before responding. I'm not debating your suggested enhancement. You accuse it of appearing to have ... been thrown in at the last minute, but again it's one of the oldest tags in CFML. You can complain that it doesn't do what you want (that seems your beef), but you can't argue that it was thrown together at the last minute just because it doesn't meet a need you see. Again, you're accusing the engineers of being stupid, and not foreseeing what you see is clearly a superior approach. I daresay no one has reconsidered that tag and its uses in the several years since it came out. Should they? Perhaps. That's where you can file an enhancement request, so it's good to hear that you have. (So you see, I'm not arguing that your proposed suggestion is specious--just the assertion about the tag being so brain dead. It does serve the needs for which it was originally created.) I only pressed this because you threw out the off-hand comment at the conclusion of your earlier note that this was another example of things in CFML that have been added without any thinking at all. I just think those kind of comments are incendiary and inappropriate. Again, we don't have insight into the many decisions that go on in the engineering team, whether when creating a tag/function or when modifying it. Do I always agree with them? Heck no. But that's what the betas are for. Get in there early and make your case known, as it seems you have. Just think twice about casting the aspersions (as I now see someone else said in that other forum that cannot be named which you hinted at). Really, you can make your point without that. :-) /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Scott Sent: Monday, January 07, 2008 5:58 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())? Sure, First things first I did not read your post in its entirety so the context of disagreeing with you, goes right out the window:-) But to keep the subject in its context, I do wonder what was going through the developers minds when they created the LSDateFormat and for what purpose. But I can tell you this. The code behind LSDateFormat is identical to DateFormat, the only difference is that LSDateFormat has a wrapper to call DateFormat and guess what DateFormat returns the default Locale. So my question is this, why? I can see that with the new argument locale, that could be the only reason behind it. Anyway, I speak from a Software Engineer point of view and I do
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
cfsavecontent variable=Test ... Some JS code. /cfsavecontent I've never used cfsavecontent to use cfhtmlhead I simply just use cfhtmlhead and place my javascript within its text attribute. You do need to make some minor syntax changes to your JS as far as quotes go. does everyone else use cfsavecontent when giving head to the javascript --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
giving javascript to the head sorry sending probably would have been better M@ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Andrew, consider the fact that while you are a Software Engineer, you need to look at Adobe, and CFML, as a Vendor. They cannot afford to willy nilly break backwards compat. You have no idea how many lines of code out there use stuff like parameterExists. Yes - the language would be 'nicer' without deprecated tags, but you need to look at this from Adobe's view. On Jan 7, 2008 4:58 PM, Andrew Scott [EMAIL PROTECTED] wrote: Anyway, I speak from a Software Engineer point of view and I do not see any reason for 2 functions that technically do the same thing. -- === Raymond Camden, Camden Media Email: [EMAIL PROTECTED] Blog : www.coldfusionjedi.com AOL IM : cfjedimaster Keep up to date with the community: http://www.coldfusionbloggers.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Glad you clarified that, Mr. Buzzy. I was about to use your comment as nomination for a new CFEmmy category next year: most perverse coding practice. :-) /charlie _ From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of M@ Bourke Sent: Tuesday, January 08, 2008 8:17 AM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())? giving javascript to the head sorry sending probably would have been better M@ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Doh!.I was just so tickled by the Freudian slip that I wrote in haste. :-) It didn't help that Mr. B had also written 2 notes (on the cf admin issue thread) just before I read your notes. Sorry, [EMAIL PROTECTED] /charlie _ From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of M@ Bourke Sent: Tuesday, January 08, 2008 12:28 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())? I aint Mr Buzzy I'm M@ like on the floor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
I aint Mr Buzzy I'm M@ like on the floor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Ray, I agree with what you have stated, but it would have been better to enhance one function than create a separate one, just my opinion that's all and they have alpha and beta testers that can check for breakage. Andrew Scott Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Camden Sent: Wednesday, 9 January 2008 1:12 AM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())? Andrew, consider the fact that while you are a Software Engineer, you need to look at Adobe, and CFML, as a Vendor. They cannot afford to willy nilly break backwards compat. You have no idea how many lines of code out there use stuff like parameterExists. Yes - the language would be 'nicer' without deprecated tags, but you need to look at this from Adobe's view. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
I personally use cfsavecontent if I need to save more than a few words... or if there's quotes and punctuation involved. I think it makes for more readable code. M@ Bourke wrote: cfsavecontent variable=Test ... Some JS code. /cfsavecontent I've never used cfsavecontent to use cfhtmlhead I simply just use cfhtmlhead and place my javascript within its text attribute. You do need to make some minor syntax changes to your JS as far as quotes go. does everyone else use cfsavecontent when giving head to the javascript --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
On Jan 8, 2008 4:50 PM, Andrew Scott [EMAIL PROTECTED] wrote: I agree with what you have stated, but it would have been better to enhance one function than create a separate one, just my opinion that's all and they have alpha and beta testers that can check for breakage. Heh, they can have 1000 alpha testers, and that's still a drop in the bucket to the _millions_ of lines of code out there. Trust me - the backwards compat thing bugs me too, but I can definitely understand Adobe's position here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
I agree. But this is exactly why we *deprecate*: It's formal acknowledgement that there's a better way of doing something, an official statement saying the old functionality shouldn't be used. Raymond Camden wrote: On Jan 8, 2008 4:50 PM, Andrew Scott [EMAIL PROTECTED] wrote: I agree with what you have stated, but it would have been better to enhance one function than create a separate one, just my opinion that's all and they have alpha and beta testers that can check for breakage. Heh, they can have 1000 alpha testers, and that's still a drop in the bucket to the _millions_ of lines of code out there. Trust me - the backwards compat thing bugs me too, but I can definitely understand Adobe's position here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
IMHO there are three beasts - undocumented functionality (and therefore unsupported) - official features - deprecated functionality. Just as undocumented functionality may evolve into official features, I see nothing wrong with moving stuff to be deprecated. Not the same as dropping it completely (at least not yet). cfcough cfquery DSN querystrings anyone? /cfcough On Jan 9, 2008 12:55 PM, Haikal Saadh [EMAIL PROTECTED] wrote: I agree. But this is exactly why we *deprecate*: It's formal acknowledgement that there's a better way of doing something, an official statement saying the old functionality shouldn't be used. Raymond Camden wrote: On Jan 8, 2008 4:50 PM, Andrew Scott [EMAIL PROTECTED] wrote: I agree with what you have stated, but it would have been better to enhance one function than create a separate one, just my opinion that's all and they have alpha and beta testers that can check for breakage. Heh, they can have 1000 alpha testers, and that's still a drop in the bucket to the _millions_ of lines of code out there. Trust me - the backwards compat thing bugs me too, but I can definitely understand Adobe's position here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
I think a few of you are missing what I am trying to say. I am still trying to confirm this 100%, but so far I have looked at the code and found that the code is in fact identical in both DateFormat() LSDateFormat(). The only difference that I can see is that LSDateFormat has a wrapper to the main code to use local, then calles DateFormat(). So what I am saying is why was it done that way, the code cleary shows it setting DateFormat() with a default Locale of US. Like I stated I need to confirm it more, but that's what I see. I wasn't out for a war, a debate maybe. But wasn't trying to say DateFormat should be deprecated, instead of creating an extra function for LS[FunctionName] for localisation, why could they have checked the locale, and returned in that date. I mean as I stated the Code Clearly shows setting the locale to US and then calling the Java date functions passing the locale (Which is set to US). I know there must be a reason, but I just do not seem to see it. On 1/9/08, Barry Beattie [EMAIL PROTECTED] wrote: IMHO there are three beasts - undocumented functionality (and therefore unsupported) - official features - deprecated functionality. Just as undocumented functionality may evolve into official features, I see nothing wrong with moving stuff to be deprecated. Not the same as dropping it completely (at least not yet). cfcough cfquery DSN querystrings anyone? /cfcough --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
I step into these waters carefully, as I know that it's a serious issue for many here. As for the whole debate about DateFormat vs LSDateformat, etc., it really is just a remnant of history. I wouldn't say it's there for backward compatibility but rather it was there first. The LS functions were added back in CF4, if I recall correctly (or maybe 3.1), and of course by then thousands if not millions of lines of code would have been written using the older DateFormat. Also, since this was before the move to CFMX (and the standardization on Java locale processing), there may well have been issues that kept some from even moving to the LS functions if they wanted to. Then there's the point made about whether Americans (and software makers) pay enough attention to I18N. Surely we don't, and it's embarrassing, but this is similar to Owen's complaint: why don't we Americans just get with the program on using the dateformat used by many others. As above, I don't know who was first, but we could also debate driving on the left vs right, race tracks going clock-wise versus counter-, and using the metric system. :-) Honestly, having lived in both countries, I wouldn't argue against the latter (nor against the date formatting change). I was a child in school in the 70's when metric conversion was attempted. We kids were all for it. It was the older folks who fought it. Changes like that are really tough to make, what with folks clinging to old ways, fearing change, etc. I honestly see it the same with DateFormat. Could they deprecate it? Sure? Should they? Why not. Will they ever obsolete it (make it no longer work)? That will take some backbone, considering the millions of lines of code that would likely use it. I doubt it would happen. Just too painful. I'm just one voice, and not even an informed one on this subject. This is clearly something (internationalization) that affects some far more than others (and I might add, sadly for some, more than most.) That's probably the root of the problem: typical American ignoring of international matters. /charlie _ From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Owen West Sent: Monday, January 07, 2008 1:21 AM To: cfaussie@googlegroups.com Subject: [cfaussie] should DateFormat() be depricated (in favour ofLSDateFormat())? or, we could just make idiot American's use the same date formats as the rest of the English-speaking world! or is that too harsh (methinks not, having been burned by Allaire/Macromedia/Adobe/Microsoft/Borland/the list goes on and on with regards to storing, interpreting and using dates across international boundaries). The whole thing makes me see red!! Owen West MCP MCAD MCSD Computer Programmer Applications Development Team Information Technology Telecommunications Hunter New England Health Ph: (02) 4921 4194 Fax: (02) 4921 4191 Email: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Charlie, I will disagree with you, and this is why. If you look at the attributes / arguments that both functions take, the only difference is that LSDateFormat takes an option argument called locale. But if you do not set the Locale it is by default set to USA date format (I can't confirm this, I can only go by the fact if the local is not set it ends up that way). So in hindsight, instead of adding that extra argument to DateFormat the developers moved over to a set of LS functions... Why? To me that is a hack, or blindsighted. So, to overcome the problem of such things the rest of the world outside of the USA has to use the locale to get proper date formating, and instead of taking the servers locale / region settings Coldfusion went its own method that didn't work. So now we have something where we can use LS functions for locale, but we now have a function that is left behind because it can't be depricated and that is why I call it a hack. However, any developer worth their salary would design with locale in mind and allow for the application to switch to what ever the user of the application would want the date in and not what the Developer of the Application wants them to be. I guess it can be debated all you like, but at the end of the day LSDateformat is not the only function that was added as a hack, I can name so many of these functions that have been added without any thinking at all. CFHTMLHEAD, is just one of those tags. On 1/8/08, Charlie Arehart (lists account) [EMAIL PROTECTED] wrote: I step into these waters carefully, as I know that it's a serious issue for many here. As for the whole debate about DateFormat vs LSDateformat, etc., it really is just a remnant of history. I wouldn't say it's there for backward compatibility but rather it was there first. The LS functions were added back in CF4, if I recall correctly (or maybe 3.1), and of course by then thousands if not millions of lines of code would have been written using the older DateFormat. Also, since this was before the move to CFMX (and the standardization on Java locale processing), there may well have been issues that kept some from even moving to the LS functions if they wanted to. Then there's the point made about whether Americans (and software makers) pay enough attention to I18N. Surely we don't, and it's embarrassing, but this is similar to Owen's complaint: why don't we Americans just get with the program on using the dateformat used by many others. As above, I don't know who was first, but we could also debate driving on the left vs right, race tracks going clock-wise versus counter-, and using the metric system. :-) Honestly, having lived in both countries, I wouldn't argue against the latter (nor against the date formatting change). I was a child in school in the 70's when metric conversion was attempted. We kids were all for it. It was the older folks who fought it. Changes like that are really tough to make, what with folks clinging to old ways, fearing change, etc. I honestly see it the same with DateFormat. Could they deprecate it? Sure? Should they? Why not. Will they ever obsolete it (make it no longer work)? That will take some backbone, considering the millions of lines of code that would likely use it. I doubt it would happen. Just too painful. I'm just one voice, and not even an informed one on this subject. This is clearly something (internationalization) that affects some far more than others (and I might add, sadly for some, more than most.) That's probably the root of the problem: typical American ignoring of international matters. /charlie --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups cfaussie group. To post to this group, send email to cfaussie@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
I'm not sure I want to be dragged into this, but I'll offer at least one reply. Can you clarify what you mean to say you disagree with? It's not clear. Are you challenging why people used DateFormat historically over LSDateformat? Or debating that I've erred in how/why people have not moved to the latter? I didn't think it was debatable, just historical. But if you see it differently... As for your saying, the only difference is that LSDateFormat takes an option argument called locale, what do you mean? The locale argument is new in CF8, yet the LS functions have existed for nearly 10 years. They are certainly different. The LS functions are driven by SetLocale (if the locale argument is not specified) where the older ones (like DateFormat) are not. They have no notion of locales at all. You say, instead of taking the servers locale / region settings ColdFusion went its own method that didn't work--what method are you referring to? Just to be clear? Is it that you think that when they considered adding LSDateFormat, they should have instead just made DateFormat work based on selocale? I suppose they could have. You'd need to take it up with Allaire/MM/Adobe engineers to fully understand their motivation. Sure, sometimes it's faulty, but often we find (even in current discussions over things in 8/8.1) that there are debates where a choice seems obvious--until someone points up a compatibility or other issue. Just saying we ought to have a little grace when considering such things, rather than presume people were being stupid. Anyway, I have no investment in this either way. Please don't set me up as a strawman/punching bag. I was just offering another perspective. You're certainly free to disagree, but don't feel that I'm trying to pick a fight with you. I'm really not. Just want to help you (help everyone) get on the same page in the discussion. Finally, I hesitate to ask, but what's your beef with CFHTMLHEAD? If it's been debated before, feel free (someone, anyone) to point to a URL. I use it all the time in a site where the HTML head tags are written previously but later I want to set a specific title for a given page. That's the best way (and only way I know) to do that. Or are you complaining about some subtlety of it that doesn't work always? /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Scott Sent: Monday, January 07, 2008 1:32 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())? Charlie, I will disagree with you, and this is why. If you look at the attributes / arguments that both functions take, the only difference is that LSDateFormat takes an option argument called locale. But if you do not set the Locale it is by default set to USA date format (I can't confirm this, I can only go by the fact if the local is not set it ends up that way). So in hindsight, instead of adding that extra argument to DateFormat the developers moved over to a set of LS functions... Why? To me that is a hack, or blindsighted. So, to overcome the problem of such things the rest of the world outside of the USA has to use the locale to get proper date formating, and instead of taking the servers locale / region settings Coldfusion went its own method that didn't work. So now we have something where we can use LS functions for locale, but we now have a function that is left behind because it can't be depricated and that is why I call it a hack. However, any developer worth their salary would design with locale in mind and allow for the application to switch to what ever the user of the application would want the date in and not what the Developer of the Application wants them to be. I guess it can be debated all you like, but at the end of the day LSDateformat is not the only function that was added as a hack, I can name so many of these functions that have been added without any thinking at all. CFHTMLHEAD, is just one of those tags. On 1/8/08, Charlie Arehart (lists account) [EMAIL PROTECTED] wrote: I step into these waters carefully, as I know that it's a serious issue for many here. As for the whole debate about DateFormat vs LSDateformat, etc., it really is just a remnant of history. I wouldn't say it's there for backward compatibility but rather it was there first. The LS functions were added back in CF4, if I recall correctly (or maybe 3.1), and of course by then thousands if not millions of lines of code would have been written using the older DateFormat. Also, since this was before the move to CFMX (and the standardization on Java locale processing), there may well have been issues that kept some from even moving to the LS functions if they wanted to. Then there's the point made about whether Americans (and software makers) pay enough attention to I18N. Surely we don't, and it's embarrassing, but this is similar to Owen's complaint
[cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())?
Andrew, I know people hate to see these kind of debates drawn out, and I've been warned before not to be pulled into the web you weave :-), but I can't let you stand on your assertions. You say The code behind LSDateFormat is identical to DateFormat, the only difference is that LSDateFormat has a wrapper to call DateFormat and guess what DateFormat returns the default Locale. So my question is this, why? I can see that with the new argument locale, that could be the only reason behind it. Again, the function came out several years ago, before the addition of the new argument locale. All the discussion here yesterday was about how it works with SetLocale. I was the first to bring up the new locale functionality in CF8. So all the other folks here are clearly discussing (as they should) how the LS functions can be manipulated based on the SetLocale. DateFormat, as an example, cannot. They're not the same, dude! I think your Software Engineer point of view is clouding your perspective. Or others jump in. Am I missing something? Again, I prefaced my first note here by admitting that I'm no expert on localization. Many of you are. Is Andrew on to something here? Or missing the boat? And what about Barry and others earlier in the thread who brought all this up: have any of my points helped you? As for CFHTMLHEAD, again, I find your argument pretty specious. But please read me carefully before responding. I'm not debating your suggested enhancement. You accuse it of appearing to have ... been thrown in at the last minute, but again it's one of the oldest tags in CFML. You can complain that it doesn't do what you want (that seems your beef), but you can't argue that it was thrown together at the last minute just because it doesn't meet a need you see. Again, you're accusing the engineers of being stupid, and not foreseeing what you see is clearly a superior approach. I daresay no one has reconsidered that tag and its uses in the several years since it came out. Should they? Perhaps. That's where you can file an enhancement request, so it's good to hear that you have. (So you see, I'm not arguing that your proposed suggestion is specious--just the assertion about the tag being so brain dead. It does serve the needs for which it was originally created.) I only pressed this because you threw out the off-hand comment at the conclusion of your earlier note that this was another example of things in CFML that have been added without any thinking at all. I just think those kind of comments are incendiary and inappropriate. Again, we don't have insight into the many decisions that go on in the engineering team, whether when creating a tag/function or when modifying it. Do I always agree with them? Heck no. But that's what the betas are for. Get in there early and make your case known, as it seems you have. Just think twice about casting the aspersions (as I now see someone else said in that other forum that cannot be named which you hinted at). Really, you can make your point without that. :-) /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Scott Sent: Monday, January 07, 2008 5:58 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: should DateFormat() be depricated (in favour ofLSDateFormat())? Sure, First things first I did not read your post in its entirety so the context of disagreeing with you, goes right out the window:-) But to keep the subject in its context, I do wonder what was going through the developers minds when they created the LSDateFormat and for what purpose. But I can tell you this. The code behind LSDateFormat is identical to DateFormat, the only difference is that LSDateFormat has a wrapper to call DateFormat and guess what DateFormat returns the default Locale. So my question is this, why? I can see that with the new argument locale, that could be the only reason behind it. Anyway, I speak from a Software Engineer point of view and I do not see any reason for 2 functions that technically do the same thing. Now let's talk about cfhtmlhead. While converting some of my extJS code over to coldfusion 8, I found that a lot of it broke with JS code couldn't be found. Yet there they are in the view source, so when I went investigating and did some further tests, the JS HAS to be in the html HEAD tag. So with that in mind I got told that is why this tag exists. So let's now look at why this is a hack at its best. To use this as it currently is one has to do this. cfsavecontent variable=Test ... Some JS code. /cfsavecontent cfhtmlhead text=#Test# Now I can't discuss where I am talking about this, but I can tell you that I have full support on some recommendations from suggested by Sean Corfield and it has been filed as an ER. My reasoning is simple, the one thing I hate is messy code, JS all over the place code not where it should be etc. And I didn't even know about
