If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

Switching between js and jquery mid script?

Hello, I have some simple form validation and I have an input field which needs to check a field in a database for a match, otherwise it's an invalid reference number. The check_form_values() function is called in the onclick event handler of the submit button.

Just after the check_email() function, I want to check for a value in the 'product id' input field and if it exists, I want to make an ajax call to the database to check that certain field in every row. I believe it would be easier to do this using jQuery.

I am wondering if I am able to switch to jQuery mid script and is it considered good or bad practice??

I was thinking of creating another function so my code is a bit easier to read, then as soon as I get inside the function start the jQuery ajax call

Having said that.. If the only reason you will use jQuery on the page is for this one AJAX call... Why? AJAX can be done in just a few lines of vanilla JavaScript. Why drag in the entire jQuery library for something so simple?

Oh, and in any case, your email test is virtually worthless. I could type in .@@@@@@....and your code would be perfectly happy.

Email validation has been discussed in this forum dozens if not hundreds of times. Do a simple search in the forum for *good* examples.

***********

Also, your method of telling the user about errors is really bad.

You go to all the trouble of creating an array of errors, but then you *STILL* output the errors via alert( ) one at a time!

However, as many here will be happy to tell you, alert( ) is very badly out of style. Some browsers allow users to turn off ALL alerts. And likely most all browsers will do so soon.

The two that don't offer the opportunity to turn off alerts when the second one displays are IE and Opera - Opera offers the opportunity to turn off JavaScript when it displays the first alert.

So the only browser currently where anyone need ever see a third alert is IE. That's assuming that Microsoft haven't duplicated the alert functionality from other browsers into IE10 - I haven't got access to check that version at the moment. If it isn't in IE10 I'd expect it to be in IE11.

That's assuming that Microsoft haven't duplicated the alert functionality from other browsers into IE10 - I haven't got access to check that version at the moment. If it isn't in IE10 I'd expect it to be in IE11.

IE10 shows only a close button, the title "Message from webpage" and the [X] close window button. There's no checkbox, secondary text, or other buttons...

that said, IE10 is not set in stone; it can be live-patched at any time, and new features are expected to appear independent of version numbers.

also, just to be contrary, i would point out that sometimes jQuery is faster than vanilla javascript. not really for a lowly ajax call, though it's not slower, but certain manipulations are common enough that chrome has targeted V8 to optimize jQuery code more than a hand-coded for-loop would be. it's like that fact that JS can outperform C++, depending on the compiler. GCC-compiled C++ is about 15% faster than V8 in tight loops, but V8 would outperform a naive college-project compiler by a substantial margin. The same principle go for large chunks of repetitive high-level routines, the very kind jQuery uses...

my point isn't that jQuery is great, but that in this day and age, where browsers accelerate jQuery and the google CDN hosted copy is >80% 304s , it's not as objectionable as it was a few years ago.

Last edited by rnd me; 12-20-2012 at 02:48 AM.

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com

i would point out that sometimes jQuery is faster than vanilla javascript.

But jQuery is just vanilla JavaScript that just happens to have been written by someone who knows a lot about writing JavaScript.

There would be nothing to stop you from discarding 95%+ of the code in the jQuery file and just using the small part that you actually are calling - of course if you know enough JavaScript to actually identify the parts of jQuery you are using then you probably know enough to actually write those parts yourself anyway.

The biggest problem with jQuery is all the novice programmers trying to use it where to use it properly requires an intermediate level of JavaScript knowledge.

Of course by the time you really know jQuery well enough to use it to its best advantage you will know enough JavaScript that you could have written jQuery yourself. Most people with that level of JavaScript knowledge will likely have already written their own efficient equivalents to those parts of jQuery that they would actually use.

There would be nothing to stop you from discarding 95%+ of the code in the jQuery file and just using the small part that you actually are calling - of course if you know enough JavaScript to actually identify the parts of jQuery you are using then you probably know enough to actually write those parts yourself anyway.

Of course by the time you really know jQuery well enough to use it to its best advantage you will know enough JavaScript that you could have written jQuery yourself.

i think you're on the mark but there's two sides to jQuery's intervention.

the first and obvious one is the browser api unification it provides. In the age of IE6, even 7, this was a very compelling feature; after all, why should we as developers need to type both innerText and textContent ?

in short, jQuery consolidated the DOM mess and offered what could arguably be called "missing" features to bare dom/js/css stack; mainly reliable "css selectors". I have no doubt that this is why it became #1.

dom unification, or "IE7 support" or what have you, is less compelling by the day. XMLHttpRequest() went "native" in IE7, and even way back in IE8 they added the single biggest jQuery killer-blow: querySelelctorAll(). Most of jQuery's "Greatest Hits" are now available pretty consistently from the natural environment, especially on mobile, which is where the growth is.

the 2nd half is a much tougher foot to push out of the door jam: plugins.

If anything keeps jQuery alive, it will be it's plugins. There is HUGE momentum for many of these in the CMS and design community. Some of them are not half-bad. They more recently and now continue serve the same role that jQuery did initially: a survey of "what's missing".

Now, we have html5 form validation specs, css reflections and transitions, native smooth scrolling, onhashchange(), history.pushState(), <script defer/async>, CSS animation, <input type=email|url|search|date>, Drag and Drop, and many more emerging in the wild. These capabilities first became mainstreamed as plugins.

personally, i think a lot of plugins are poorly coded and slow, but the concepts they implement and the problems they attempt to address are of note.

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com

Just my 2 cents, if this is for a signup page, email validation has spawned large debates and Regex's. The simple thing to do to validate someone's email is just to send them an email with a validation link during signup. Make it such that they can't login if they haven't been validated. Of course check for '@' and '.' .

If its just a form for checking whether an email address exists, well if the email isn't there in the database, it isn't there.

Having said that.. If the only reason you will use jQuery on the page is for this one AJAX call... Why? AJAX can be done in just a few lines of vanilla JavaScript. Why drag in the entire jQuery library for something so simple?

I didn't realize it was as easy as you say because my JS book tells me that I have to check for ActiveXObjects or something then do two different things depending on what it returns. I thought it would be a lot easier with jQ.

Originally Posted by OldPedant

Oh, and in any case, your email test is virtually worthless. I could type in .@@@@@@....and your code would be perfectly happy.

Email validation has been discussed in this forum dozens if not hundreds of times. Do a simple search in the forum for *good* examples.

I know it isn't the best but I just wanted to add at least some js validation to prevent a certain submit to the server. It's a real difficult subject if you aren't familiar with RegExps. I'm not too worried though because if it does pass my JS validation, I have some PHP email validation which should catch it.

Originally Posted by OldPedant

Also, your method of telling the user about errors is really bad.

You go to all the trouble of creating an array of errors, but then you *STILL* output the errors via alert( ) one at a time!

However, as many here will be happy to tell you, alert( ) is very badly out of style. Some browsers allow users to turn off ALL alerts. And likely most all browsers will do so soon.

Thank you very much that seems a much better way rather than alerting one at a time. If alert() is old and not used to much anymore, what is the other alternative? Do you just innerHTML anything you need to directly to the page? Is there a new way to show an alert() or should we not be using any alert type messages altogether?

Thank you very much, I think that code just answered my question above! I'll start editing the code as soon as I can sort my other issue out. Can't get onto my contact page because it connects to mysql and it doesn't seem to be loaded as an extension in my version of php :s I've got mysqlnd?