I know, but it's there, so... I just use it. It's a matter of being consistent with the existing codebase. There would be too much to change otherwise.
Also, sometimes it can be helpful to know what the *intended* purpose of a variable is. I know it has helped me... Don't forget that our code needs to be readable by future devs!
I didn't say using any form of hungarian notation was wrong. Using "userTitle" for user input and "title" for internal makes sense. Mozilla uses a convention of "aTitle" for arguments.
But, even for a strictly typed language, type-based hungarian notation seems silly and wrong to me. All the more for a loosely typed one.
But, just IMHO. I know there's tons of programmers out there with different opinions.
You mean like <base href>...?
(man this auto strip quotes thing is kinda confusing.)
No, just a:
var smf_base_url = "http://wedge.org/";
In my experience, Google doesn't read bare links after that, e.g.:
var smf_theme_url = smf_base_url + "/Themes/default";
Obviously, it becomes more complex when those urls aren't always in the base - as with SMF, and as with some of my stuff. I think I tried separating with + without any luck, and ended up using a htaccess forbidden rule or something (because I didn't want the separate content url indexed.)
There are issues with base href in some browsers iirc. It generally works and I've used it before, but I know sometimes it doesn't work like you'd expect.
I don't even remember seeing a ready-made function for that in ECMAScript...
In TOX-G:
var x = <tpl:json value="{$x}" />;
Note that you have to wrap that in CDATA (e.g. around the whole script, as often done in SMF for XHTML compat) or use <tpl:container doctype="html5"> if you want it to be escaped right in <script> (which has text semantics.) In attributes (e.g. onclick="blah(<tpl:json value="{$x}" />);") it will escape the html entities as well, which is necessary to avoid security holes.
It seems to be the case for me... In which case, why did JSE ever begin to escape them...?
I don't know, that function was created after I left. There are valid reasons for escaping js in many ways to avoid security holes, but it seems like it does too much.
Gzip doesn't really matter here, you'd be surprised with the strange results I've been getting. (There's a recent discussion somewhere about the effort I went into converting some variable names to be one char instead of long stuff, and in the end the resulting gzipped file was actually longer by a few bytes... I just couldn't believe it.)
Keep in mind that
repetition is what's key to compression. Consider the following:
function show()
{
var should_i_really_show_it = !this.is_showing();
if (should_i_really_show_it)
this.really_show_it();
}
function hide()
{
var maybe_really_hide_it = this.is_showing();
if (maybe_really_hide_it)
this.really_hide_it();
}
It might seem like the variable names are way too long, and they are (from a this-code-is-ugly perspective.) But really, the biggest problem for compression is that it isn't very repetitive. Consider instead:
function show()
{
var is_it_showing_now = this.is_showing();
if (!is_it_showing_now)
this.really_show_it();
}
function hide()
{
var is_it_showing_now = this.is_showing();
if (is_it_showing_now)
this.really_hide_it();
}
Yes, the variables are shorter. But, the more common pattern may compress better.
One of the important things minifiers do is create patterns. For example, doing "if (x) {} else y();" may actually be better than "if (!x) y();" in a long document that uses "if (x) {" a lot and uses "} else" a lot.
Potentially, but not necessarily. Without actually testing, the cases can always be strange, and small scale experiments are rarely accurate.
Anyway, I was guessing that using \ns might gzip better, at least because the pattern
after the \n and including it may be more likely to match (such as "\n <div".) Obviously, the \ does muck this up and so it might not really compress better after all. Certainly it's the same number of bytes whether a newline or n is escaped.
Ah, would be swell if Apache added support for 7z or even RAR... :lol:
Well, recall that the iPhone 3GS was able to load pages much faster than the 3G. This wasn't because they gimped the network for the 3G, but because the processor was more capable to deal with it. Engines like 7z, rar, and bzip2 achieve better compression ratios but at the cost of more cpu, which can be a problem (if dynamic) on the server side, and can of course be a problem on the client side (e.g. for mobile.)
Anyway:
https://bugzilla.mozilla.org/show_bug.cgi?id=173044https://bugzilla.mozilla.org/show_bug.cgi?id=366559AFAIK rar is encumbered so I wouldn't hold my breath for it.
Just Google it ;)
I suppose strtr() isn't that slow anyway...
Actually, it is. On long strings, str_replace can take only 15% the time, and on short ones 30%. The situation was reversed in PHP 4, which is why I used strtr a lot in SMF (I also prefer its syntax.) In fact, in some cases preg_replace may beat strtr, I suppose, based on my benchmarks.
I think that in that PHP fork that was posted here, the guy sped up strtr. Clearly there's room for improvement.
By the way, json_encode, on my setup, is in fact even faster than addcslashes (which by the way, is usually faster than addslashes, even with the same character list.) Haven't checked its memory impact, though, would probably need to xhprof that.
I'm getting very annoyed by the constant changes in my CSS. I'd really like to call it quits and commit it, but I'm scared most people will think it doesn't look as good as a stock SMF2, ah ah...
Heck, I made many changes to the visuals this week really. Even the windowbg divs have finally lost their border... (I'm not kidding. I was adamant this border would be in the final design... Until I decided it wasn't needed.)
Ehh... I suck at design which is why I left the HTML and CSS stuff mostly alone in SMF. The nice thing about a versioning system like svn is you can always svn merge -c -123 and undo a commit.
-[Unknown]
