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 >
