My jQuery reaction to the language's flexible "selectors" is probably rooted in this experience:
I once had managed a project where a developer constructed a web page that was used by users to provide very flexible search parameters for a search screen using dynamic sql string building based on the user's specified search parameter. The resulting queries were usually very complicated and involved joins to many tables. One of the options that the user had was to choose from one of 3 an options. Depending on the user's choice for this option, the resulting SQL would need to query a different set of database columns. For example, if choice option "A" were selected, the resulting database columns queried would be prefixed with "A_"; if option "B" were selected, he resulting database columns queried would be prefixed with "B_" and so on.
The developer choice to write all the complete SQL assuming that the user selected, for example, option "A" and therefore first constructed SQLs of this type:
SQL = "SELECT A_COL1, A_COL2, A_COL3 FROM TABLE ..."
and then after constructing one of a million possible variations on the Query From Hell, did something like this:
If UserOption = "B" then
SQL = SQL.Replace("A_","B_") 'replace everywhere
End if
He insisted that this was the easiest was to code it, and while I understood that, I was concerned about maintenance of this code. You see, this worked for a while, but as the search options grew and the database columns evolved, the various "REPLACE small substring" with another small substring had unexpected consequences when applied to an evolving database and new search options. My feeling is that code should be written as much as possible such that you can add to it without fear of breaking what is already there.
I feel a better approach, though a bit more work, would have been to write a function to return the appropriate target column based on a common set name and the user selected option.
OK, so what does this have to do with jQuery selectors?
Are the ultra flexible JQuery selectors kind of like perform a "replace all" on a SQL string? Handy as hell but potentially creating a maintenance nightmare?
