The underscore is valid in ids and classnames. Why don't you just preface all of your JS related classnames with a standard header,
class="moo_input2" or even id="input2_js" (Though my personal habit is to always use classnames for javascript related conventions, so the ID bit wouldn't happen.) This way, your coworkers can know which names are (also) being used for javascript purposes, while keeping whatever name they are familiar with. If you have too much legacy code to update variable names, you can have Mootools rename the elements once they are put to use, or use other libraries to rename them at runtime. On Jan 26, 3:13 pm, Pete Duncanson <[email protected]> wrote: > Thanks for the support guys and the constructive feedback. > > Just had "the call" from the client and it went really well considering and > because we've already done a lot to stop it happening again (like email you > guys!). > > I think I'm going to try a few different things to fix this: > > * I like the idea of flagging elements that are "special" be this because of > CSS or JS needs. If we mark an element via a class as "special" (somehow) > then it at least will give a warning to coders/designers a like to think > twice. > * I also like the App.selectors idea but thats site wide, some of our code > only runs an certain pages and I'm pondering on using something to detect > that. Similar to my ElementRegister but with a bit more logic on it. I'm > keen on that as we can quick knock up a new smoke test to run on our build > server and check that all the elements on a page exist that should be there > for a given page. But that needs a bit more thought and I don't want it to > be a 4 day hack-o-rama to put it together but its a possibility. Could be a > simple as listing elements of note at the top of the file and have a unit > test check for the existance when we build or it could be done via Mootools. > Would need a way to scope it to, eg "if this element exists that we must be > on this template so check all these other elements exist". > * Visual checks are good and I'll be getting our designer to do a folder > search of our JS files as well as the CSS file as he was doing. > > I still think the lack of any way to show a relationship between the JS and > HTML is a sticky problem, hope the above can at least eleviate it somewhat. > > Pete > > On Tue, Jan 26, 2010 at 12:12 AM, Ryan Florence <[email protected]>wrote: > > > > > clearly not enough, where do you stop though... > > > I hear you! You do have to draw a line eventually, and it's often > > irritating to spend 20 hrs on tests and 20 hrs on the actual code. > > > But my question was not intended to get me hit with the testing stick, > > > Sorry :( I'm a bit ticked off at some who aren't allowing me to write > > tests at work due to time budgets so I'm quick to sling it around. Forgive > > me. > > > The question was more about how could we flag up JS bound HTML elements > >> during the development process > > > I do a project search (textmate) for the string. I know that sounds overly > > simplistic but it has kept me from breaking things too often to count. > > > This doesn't solve any of your legacy code problems but I've gotten our > > crew so hooked on mootools that all of our js logic is tucked away nicely in > > classes, the only time there's a string for an element's id in our js is > > when we construct the objects, so it's a pretty easy thing to check / fix. > > > I've even started making a class to control the whole page and stick all > > the selectors in a property of the class: > > > var App = new Class({ > > > selectors: { > > nav: 'top-nav', > > header: 'header', > > awesomes: 'li.awesome' > > }, > > > // other code > > > }); > > > So it's as easy as just checking where the main app was constructed. > > > Ryan Florence > >http://ryanflorence.com > >
