Gone for this in the end:
<div class="curvy_box isJS"></div>
Any element flagged with isJS should be treated with care.
We added a dummy class definition in our global css too:
.isJS {
/*
This class is used to highlight elements that are using in our
javascript, be VERY careful when modifying them, their ids,
removing classes adding inline styles etc.
*/
}
So future developers might find this while searching. A plus point of doing
it this way is we can actually add styles to this class in our debug.css
file to highlight all the javascript bound elments on a page. Which is
proving handing in highlighting any we might have missed. Plan now is to do
a short stint on the main templates just to go through and try to flag the
main culprits in a 30 minute one hit wonder.
Client has given us the go ahead for end to end testing at last too, just
need a dummy hotel/flight to booking with.
Pete
On Wed, Jan 27, 2010 at 9:44 AM, SamGoody <[email protected]> wrote:
> 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
> >
> >
>
