boen_robot

Are you using an XSLT 1.0 processor or an XSLT 2.0 processor?This is not possible with XSLT 1.0 for sure... I'm not entirely positive about XSLT 2.0.

When both columns of the JOIN are indexes (I mean index for the same value; like a primary key in one column being joined with a table where the column you'll be joining is a foreign key of that table), the indexes (which are ints) get checked for equality, not the (VAR)CHARs. This is possible since both indexes are based on the same set of values. The result set is of course formed from the VARCHARs which are extracted from the index after the JOIN.I'm not sure if this is applicable to MySQL (like I said, I haven't made benchmarks)... I learned this at a DB class at uni, which is based on MSSQL, not MySQL.But yeah, justomeguy's point about space remains valid - indexes take space, and an index for INT values will more often than not be less than the index for (VAR)CHAR values.

mysql_escape_string() has issues with that. Not mysql(i)_real_escape(), because these check the charset of the connection, and act accordingly.

AFAIK, when the (VAR)CHAR field is a primary key, or any index, on both sides of the JOIN, this penalty is eliminated. I could be wrong on that one though (I haven't made enough benchmarks).

I was wondering what happens when users reach their PM limit (as I'm very close to it...). Thank you for demonstrating .If thescientist bothers to delete a few old PMs, he'll be able to receive yours.

How do you want the language to appear in the URL? As a query string parameter, before the main path, after the main path?It's easiest if you want it in the query string: RewriteRule ^([A-Za-z0-9_-]+)$ webs.php?id=$1 [NC,QSA]

Using saveHTML() can be problematic if what you're outputting is XML, although in your case, it doesn't seem like it.In case you do need to use XML (for the sake of, let's say nesting SVG), you can have the output you want by passing an option to saveXML(), like: $DOM->saveXML(null, LIBXML_NOEMPTYTAG);

What if two users want to use the same password? You want to allow users with the same username in, as long as they have different passwords? You wouldn't allow registrations because a password someone chose matches that of an existing user?All that sounds like something a hacker might use to figure out passwords... create a bunch of accounts with the same name, but a different password, and do that until declined because of a password conflict, in which case they can safely assume another user has that password, after which they can try every user that they can see.No, this sounds like a terrible idea. A primary key needs to be something that isn't allowed to repeat in any circumstances. Like the username or an email for example.

An element (any element; a div will do) using absolute or fixed positioning (if you have other elements using absolute or fixed positioning: also add a z-index with a high value) should do the trick just fine. I mean, that's what absolute/fixed positioning is for - to escape the normal positioning flow.

Sounds like a problem in MySQL's ODBC driver. You may want to report that to them.

There is a difference between "Java" and "JavaScript".JavaScript is pretty much the only game in town when it comes to client side scripting. If you want something to happen when the mouse is moved, when a key is pressed, when the window is resized, when a form field is filled (without the press of a submit button that is), JavaScript is pretty much the only way to do that.When it comes to server scripting - the thing that happens between the click of a link or form submission (or refresh of a page; basically, anything that leaves your browser screen blank for a moment) and the display of the new page - you can use Java, Python, PHP, ASP.NET, ColdFusion, Ruby or whatever else your server is configured for.

Try it with a single apply-templates: <xsl:template match="CAEXFile"><xsl:copy> <xsl:apply-templates select="@* | node() | document('my2ndFile.xml')/CAEXFile/SystemUnitClassLib/node()" /></xsl:copy></xsl:template>

Your XPath on the document() line is wrong... it should start with the file's root element, i.e. "CAEXFile". Try it like: <xsl:template match="CAEXFile"><xsl:copy> <xsl:apply-templates select="@* | node()" /> <xsl:apply-templates match="document('my2ndFile.xml')/CAEXFile/SystemUnitClassLib/node()" /></xsl:copy></xsl:template>

The CHAR type is for data which is of a constant length. Like a sha1 hash for example - it's always 40 characters (or 20 if you're storing a binary string). Not more, not less.In contrast, VARCHAR is for data which is not always of a certain length, but is less than or equal to a specified limit. User names fit this category (so you are correct indeed) - you could have a user with a name as short as "jimfog", or a longer one, like "boen_robot".If you use CHAR for data which is of variable length, the extra bytes will also be filled into the DB. With spaces, but still - they'll take space.

I see.Well, that doesn't invalidate anything I said then. I mean, it's as if you're saying "Yeah, algorithm X is faster than Y, but Y is still magnitudes faster than Z, and also accounts for stuff X doesn't account for!". Sure, if you need that power, use it. If you don't need the power, having it is pointless. Amen to that!

Who said using uncompressed images (and multiple ones too), and/or using tables for layout is a good thing? I sure didn't, and I don't think that's OK either.You're lumping those together as if you can't create a table-less, image-compressed site without jQuery, which we all know is false. Who's that?Saying "not everything is a nail" is not the same thing as saying "you should never use a hammer".

If it's a very little CSS/JavaScript, it's fine to include it in a file that's downloaded always. But including a whole library, alongside all of your CSS/JavaScript, if most of your pages don't even use it, is just a waste of your users' bandwidth.Yes, jQuery can create leaner, unobtrusive code, if used right, but the same can be said about JavaScript itself when it comes to non-fancy scenarios.

Indeed, I find most sites make ads that are using Flash, and/or they have jQuery included, but the point is that most sites don't need to do that with the way their ads are structured. To put this in another way, even though they use jQuery or Flash, they don't have a slideshow or something like that.Those who use Flash use it for the sake of audio or video ("animation" in general, really), which is OK (doing audio or video with HTML5 is still somewhat tricky with all the formats). Those who use jQuery typically have jQuery there because of something else. Something that they use on just one or a few pages (like if they have an interactive form of some sort on one page), and something which uses just one not-so-fancy feature (like making ajax requests on change), but include the library everywhere anyway - the very practice that Ingolme and I consider "bad".There are of course some who actually do use jQuery for the sake of making their ads fancy with stuff like slideshows, in which case they've made the right decision, but those are the exception, not the rule.

Well, if you want a fancy thing like a slideshow effect, I suppose that's warranted too. I haven't seen many sites that do this for ads... instead, most sites typically show a random ad chosen by the server, and for THAT, using jQuery is not needed.I'm sure you can think of other "fancy" stuff too... and if you want to be fancy, jQuery is a good way to be fancy. The point Ingolme and I are making is that if you don't need the fancy stuff, but just use jQuery for the sake of using jQuery "in case you decide you want the fancy stuff" is... I think the right word is "pointless".

What? For every site/application? If you're using several features, and not just a single simple feature like an "ajax" function... sure. It's prudent indeed.

If you know from the start that you'll most probably use JavaScript somewhere on every page, your application is probably complex enough to warrant the use of jQuery from the start.And as for growing applications that only start with needing JavaScript at one place, and then another, etc... if you find yourself replicating several jQuery features, you probably need jQuery. Otherwise, you don't.

The PHP reference on W3Schools is a little outdated (no wonder, PHP develops rapidly). In the latest PHP versions, setcookie() has 7 parameters. See setcookie() in the official PHP manual.For a moment there, I saw what I thought is an error in the W3Schools example, but after seeing Mozilla's docs on document.cookie, it seems the example is correct, although the explanation is somewhat poor - instead of writing to the whole file, you just write one cookie as a string, and the browser automatically merges the cookie's name and value to the cookie file. The string itself follows a format that, in the end, makes setting a cookie similar to setting a cookie with PHP's setcookie().

Note: That's what I have in mind when I say "PHP file" - a file that has a ".php" extension. At least in a typical context, that's what this means.So with that in mind... ... try it! Try to name a file with ".html" extension, have that file contain some PHP code (like "<?php phpinfo(); ?>" for example), place it into a server that supports PHP, and just open it up in your browser, and see if any of the PHP executes. Rename that file to ".php" and see if the results are different.

The more important thing to keep in mind is "one cookie file" vs. "multiple cookies stored within one cookie file". JavaScript lets you read the file, and doesn't give you anything for the cookies themselves, while PHP does the opposite - gives you means to read/write individual cookies within the file, while eliminating access to the file (because why would you want that when you have the individual cookies?). Essentially... yes.

How can you even talk about "better" if only one of the options works to begin with?If there's any PHP executed in the file (and this also means if the PHP in question contains only a one or more "include" statements), this file must be a PHP file. Period.There's no other way. An "HTML file that include php code and html code" will simply not have the PHP code execute.If you don't have any PHP code in a file, that file may be PHP or an HTML file.