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: [email protected] [mailto:[EMAIL PROTECTED] On Behalf
Of Andrew Scott
Sent: Monday, January 07, 2008 5:58 PM
To: [email protected]
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 this
tag, until a few weeks ago.
But let's look at the CF8 Ajax stuff.
If it was me and I knew that this tag had to exist why could it not have
been designed to do this.
<cfhtmlhead language="Javascript">
...Some JS Code
</cfhtmlhead>
Or even
<cfhtmlhead language="vbScript">
...Some JS Code
</cfhtmlhead>
Or
<cfhtmlhead style="CSS">
...Some CSS styles
</cfhtmlhead>
Can you understand how a little more though would make something like this
tag, appear to have not been thrown in at the last minute?
Andrew Scott
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"cfaussie" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
