?

Log in

No account? Create an account
Semiformalishmaybe

JS Ugliness

I'm weirded out that standards for Javascript programming are so low. Having made a more-or-less a successful first project, where I really rushed to get it done, cut corners, and just did the first thing that came to mind (that worked) to solve problems, I'm going back and refactoring it now, in some cases trying to learn best practice with some good documentation.

I'm sad that it's not actually possible to make things clean, and one of the kludges I am least proud of seems to be standard practice.

Ordinarily with a form in a page, you have a bunch of form elements, and you have some way to submit the form, which causes your browser to scoop up the state of all those form elements, bring you to a few webpage, and give the webpage the state of that form in some fashion (I could explain, but let's gloss over those details).

One of the points in my demo is that I want to be able to do forms that talk to javascript that manipulate the currently loaded page and then reset themselves, rather than loading an entirely new page. This is fun because it doesn't take anything on the webserver end, and in fact doesn't even require a webserver; I'm doing development with a flat HTML file with all the javascript packed into it, using a file:/// url.

Still, forms are useful; the widgets they provide are really useful. So, how do I use those widgets but prevent the form from ever doing a submit?

My hackish solution was to cheat; if you view the source of my demo, you'll find that I hook "onSubmit" events, use it as the main entry point into my code, and then return false, using a mechanism normally used by form validation to back out of the submission. I also have code to clean up the entry box. Ugly, but ok for a proof of concept. Or so I thought. I was shocked to find that my ugly hack seems to be standard practice. WTF. It's not even that robust; if your javascript doesn't pass muster with the parser, a submission will happen anyhow, when it probably should never happen. Highly uncool. I'm looking for better solutions, but really bothered that the status quo sucks so much.

Tags:

Comments

Using an onsubmit attribute in the HTML is *not* standard practice; the on* attributes are considered hackish these days. Look up "unobtrusive javascript" -- the recommended practice is to attach listeners to element events in the Javascript, rather than in the HTML. And I think part of your dilemma will be resolved by omitting the FORM tag.
Just figured out how to do that; irritating how that gives a version of the document object that has fewer features (need to use document.getElementById() rather than document.Elements[]) and reorganise some other bits, but it does seem reasonably clean now; it at least feels less hackish.
Your element selection might be easier if you give in and use a library like jQuery. Besides making it much easier to select elements, the cross-browser advantages are enormous.
Also, have you read the book "Javascript: The Good Parts", by Douglas Crockford?
I have read no books on Javascript, but I'll look for different advice; the advice I saw seemed pretty solidly for onSubmit, and I actually tried omitting the form tag but that didn't give me anything left to hook for submits the way I was hooking. Hopefully I'll be able to find examples of what you're talking about somewhere.
I was thinking of replacing the FORM with just a DIV with an event handler attached either to the DIV or to an element inside. Though if you want it to work without Javascript too, keeping the FORM would be necessary. It may be best to stop thinking in terms of "submit" though, and just think in terms of getting the data to the server. This isn't HTML 2 anymore. :-)