views:

263

answers:

2

Too often I find myself building selectors with string manipulation (split, search, replace, concat, +, join).

Good or bad?

+1  A: 

What's wrong with that? What are the alternatives — just hardcoding them as single strings? But you may use conventions on your site for how the layout is organized. If you just define the selector components in one place, and use it to build a selector, sounds like this would be less hassle than going through all the code and doing search-replace everywhere it shows up.

I'd say it's good assuming you have the strings otherwise organized (defined in one place, used in several places).

Jaanus
A: 

This is somewhat unrelated to your question, but:

One thing I would recommend is to be cautious with descendant-based or child selectors (e.g.: 'div.product > span.price'). Often, UI parts are being reorganized, moved around or wrapped with something else. When it happens, descendant-based selectors break.

Another thing to keep in mind is that attribute-based selectors (e.g.: 'input[value="Login"]') are often fragile when dealing with localized content (if attribute values are localized).

kangax
Out of curiosity, what do you mean by "UI parts are being reorganized, moved around or wrapped with something else"? When and why is this reorganization happening? Do you mean that you need to keep track of the affects of mutations you're making in the course of a complicated sequence of chained operations?
Tim Down
I mean that element can no longer be a child of another element, but rather a grand-child (if it was wrapped with something else). An element could also "change" its parent — either after being moved into another place, or if parent tag/class/id was changed. All these changes in markup affect selectors that rely on document structure.
kangax