I'm just in the process of studying jquery. And I have the following question. I have a page that relies on js for ajax and reporting to user.
So basically I have created a file with $(function() {}) construct. Inside of that construct I'm using standard jquery functionality to work with my modal windows, smth. like
$('.text-danger').hide();
$(".btnajax").click(function() {})
But now I want to work with another modal window at the same page, not at the same time. What would be a better way:
Continue inside the same anonymous function construct and keep working with IDs and Classes when referencing the specific buttons and form actions?
OR
Create new anonymous function construct? OR
Create named functions and call them when needed?
I would like to build correctly from the scratch, so I don't have to redo everything later when I'm better with JS.
Thank you in advance.
Continue inside the same anonymous function construct and keep working
with IDs and Classes when referencing the specific buttons and form
actions?
This is not a good idea as every time you would do something with the buttons or the form it would access the DOM which is unnecessarily expensive.
Create new anonymous function construct?
Actually, anonymous functions are rarely a good idea as they make your code hard to read. Imagine there are no named functions and everything is anonymous. That would require the reader to always get the context in order to quickly understand what the function is doing
Create named functions and call them when needed?
Especially when reusing that functionality, it's a good idea. But also in terms of readability it is good because the name of the function describes what is happening so when someone (you) read the code again after some time, will know hat is happening without studying the body of the functions.
Apart from that:
I would like to build correctly from the scratch, so I don't have to redo everything later when I'm better with JS.
I can tell you: you will not avoid rewriting parts of your code once the requirements change. That is just what coding is about. You can not foresee every required change to your application. If you try to then you end up having an over engineered code. Instead, you should follow YAGNI.
Generally speaking, for everything that's more than just 5 buttons and a form, a JS file with jQuery is not the way to go. Those times are over. Switch to something that gives you a separation of concerns between model, (model)view and controller.
Related
Good day all.
I would like to count the js functions present on a given page, and then send this number via ajax (the ajax part is the simple part) do you think is it possible to achieve that in javascript? what should be the best way to do it?
thanks in advance.
explanation:
I'm trying to figure out how to counter measure some fraud attempts on some subscription pages, I suspect that some javascript is injected on the page before the user click, so having the number of functions present at the load event, and then the number of those present on the submit event, should lead me in the right direction.
Well, if someone is injecting code to your site, they could just as easily use that code to turn off your code counting functions. You can never trust anything that happens on the client side and must validate everything on the server.
As for the technical side, you'd use a tool like acorn to traverse the syntax tree and find all FunctionDeclaration and FunctionExpressions (and arrows, concise method definitions and methods). That would not find all functions, but it would find all statically created ones.
Once the code started executing it's impossible since it's easily reducable to the halting problem. You don't know if a code will create a function at some point in the future.
I am learning jquery and started my first attempt at building a form validation script based on what I know so far (which isnt much).
This is really only the Radio button portion of the validation script, but I thought I get on the right track -coding wise- before I went too far. There are some fundamental issues that I know need addressing.
The Script (jsFiddle): http://jsfiddle.net/pkdsleeper/xNt5n/
The Questions:
a. How best to remove the global variables using
b. jsLint recommends "use strict", so I added it, but im not sure what it does.
c. any good refs?
d. Generally, feel free to rip this code apart (cuz I AM trying to learn) but
please explain my errors in noob-speak :)
Thanks In advance
sleeper
a. How best to remove the global variables using
Wrap it in an anonymous function and assign it to the form as a submit listener.
b. jsLint recommends "use strict", so I added it, but im not sure what it does. any good ref's?
Don't bother. It's just a buzz-word for those trying to be hip. You can't use strict mode features on the general web because way too many browsers don't support them. You can use it with otherwise compliant ES 3 code, but it's only useful as a debugging tool for errors that should have been found during testing anyway (e.g. calling constructors without new).
No c?
d. Generally, feel free to rip this code apart (cuz I AM trying to learn) but please explain my errors in noob-speak :)
> $rdoGroup = [], // an empty array which will be used to hold
You seem to be using $ to indicate a variable that references a jQuery object, but $rdoGroup is just an array. That may be confusing later.
> $rdoGroup.push($(this).attr("name"));
The $ function is very expensive, don't use it if you don't need to. Standard HTML attributes are available in all browsers as DOM properties, so:
$rdoGroup.push(this.name);
Is up to 100 times more efficient, depending on the browser.
> for (i = 0; i < $rdoGroup.length; i++) {
> if ($rdoGroup[c].toString() !== $(this).attr("name").toString()) {
The values assigned to $rdoGroup are strings, calling their toString method is redundant.
As above, use this.name. The name property is a string, so no need for toString.
I think the exercise would be easier without jQuery, which seems to be getting in the way far more than helping. If you are trying to learn javascript, I'd suggest that you learn javascript without using any library.
Once you are reasonably confident with using javascript, then you are far better equipped to use a library for the things the library is good with, and not using it for the things it isn't good at.
a. Well, you got rid of the globals pretty well. But as your code looks right now, you can wrap the entire thing in (function(){ ... all your current code in here ... }()) and leave nothing behind in global scope.
b. For "use strict" see this question
c. typeof questions['c'] === "undefined"...
d. Currently, your js is too tied to the markup (html) and vice-versa. If you add or remove something in the form, you'll have to edit your js. If you want to use the validation for another form, you'll have to start the whole thing over again.
Validators are prime candidates for "unobtrusive javascript"/progressive enhancement (here's some material: A List Apart & Wikipedia). Basically, your markup (the html), your styling (the css), and your "behaviors" (the javascript) should all be separate, so they can be changed independently. Here's something you can try:
Add a class name to your form(s) (e.g. "validate")
Set up your js to look for form.validate when the page has loaded
For each form it finds, add a submit event handler
When the handler fires, you search the given form for inputs with various other class names you specify (e.g. "required" or "phone-number" or whatever). The class names tell your code, what kinds of validations should be done. For instance, <input type="text" class="required zip-code"> would mean that a) it's a zip-code, and b) it's a required field.
If there are any validation errors, cancel the submit and alert the user somehow. Otherwise, let the submit proceed.
That's obviously a very rough outline, but I'm not gonna write your code for you :)
The point is, that if you ever need more forms or different forms or something like that you have a generic validation script, and all you need to do is "mark" the inputs with the appropriate class names.
All that being said: There are tons of jQuery plugins out there that do form validation. It's definitely still a good exercise to write one yourself, but it's also a good idea to look at what's already there, and how it works. Don't look at the code right away, but read up on how those validators are used (e.g. do they use class names or something else?) and try to figure out how they work.
I've started using the Sencha Touch / ExtJS JavaScript framework and have am noticing a wide use of nested, anonymous functions. For example, this is a common way to start your app:
Ext.setup({
blah: blah,
onReady: function() {
my
fairly
long
startup
code }
});
It's been a while since I've done JavaScript programming; to me, defining a nested anonymous function like this--inside of a function call--is not as easy to read as the following:
Ext.namespace('myvars');
myvars.onReadyFcn = function() {
my
fairly
long
startup
code
};
Ext.setup({
blah: blah,
onReady: myvars.onReadyFcn
});
I understand there are some real benefits to using anonymous functions in certain situations (e.g., maybe it's one-time code, maybe you don't want to add another function to the global namespace, etc.). That said, is there anything technically wrong/detrimental to using this latter (perhaps more verbose) method if you find it easier to read?
Thanks!
I use both ways all the time without thinking too much about what is better. And I believe that in terms of performance if you are worried about a mobile device download time or parsing time then you will end up using some JS Minifier (or maybe Google's Closure Compiler).
Anyway, I do have a criteria that seems helpful to me to decide whether the function should be anonymous or not:
If I had a really good name for the function then it shouldn't be anonymous
What I mean is if your function will be named onSetupReady then the function is not explaining what it does, instead, its name is defining where it should be used (and that would usually be one only place which will call that function). So if that is the case then you can choose to make the function anonymous or not. I usually choose anonymous.
But, if your functions does one just one thing, and that thing in not really obvious, and you are tempted to put a single line comment in the first line of the function (or whatever) to explain what it does. then I won't do that, and I would choose a good name for this function. And I emphasize this rule, even more, when the event which triggers this function is not obvious for that function. Examples:
Anonymous OK
Ext.Window({
listernes: {
beforeclose: function() { // This function has only one purpose and
Ext.Msg.show({ // can be named, but I think it's OK. Because
title:'Close?', // it is really easy to see what it does.
msg: 'Are you sure?',
fn: function(btn) {
if (btn === 'cancel') {
return false;
}
},
animEl: 'elId',
icon: Ext.MessageBox.QUESTION
});
}
}
}).show();
Anonymous NOT Recommended
var insertExtraToolbar = function() {
var containerNbar = theGrid.getBottomToolbar().getEl().parent().dom;
theGrid.elements += ',nbar';
theGrid.createElement('nbar', containerNbar);
};
theGrid.on('render', insertExtraToolbar);
I don't think there is anything wrong using separate functions, depending on the purpose. For a setup function or onReady functions I will like anonymous functions, for callback functions that are really small piece of code like 1 or 2 simple line I will use anonymous functions. For callbacks I often like to use a separate function however, I find it easier to read and especially with most frameworks giving an easy way to pass parameters to the callbacks when making XHR.
However, one advantage nested anonymous functions gives you is the closures around variables that sometimes you might end up needing to pass as parameters if you separate the function.
It is a very tough question to answer because it will be a question of style, performance, purpose that will be different depending what is the purpose of the code you're writing.
I used to have the same feelings you did when I first started encountering nested anonymous functions.
Now that I've gotten much more used to them I actually find nested anonymous functions much easier to read as long as they're only used in one spot. When code is written that way, all the code I'm interested in is in a single spot and I don't have to jump around the file nearly as much to figure out what the code is trying to do.
Keep in mind, though, that my opinion only applies if the code is only used in one location. If you keep repeating the same anonymous function in multiple places...I still prefer to break it out like your second example.
In a way, you may have answered your own question. The OnReady function is only run once. for maintainability, it might be a good idea to separate out your code so that you have a section for layout, a section for events, and a section for business logic in your code.
One thing to consider perhaps is that Sencha Touch is geared towards mobile devices that may sometimes have limited resources for you to work with. With that in mind, it might be necessary to structure your code to make it as small and efficient as possible. Your proposed code snippet may be ignoring those constraints that mobile platforms have to deal with.
You know what I liked best about obtrusive javascript? You always knew what it was going to do when you triggered an event.
<a onclick="thisHappens()" />
Now that everybody's drinking the unobtrusive kool-aid it's not so obvious. Calls to bind events can happen on any line of any number of javascript file that get included on your page. This might not be a problem if you're the only developer, or if your team has some kind of convention for binding eventhandlers like always using a certain format of CSS class. In the real world though, it makes it hard to understand your code.
DOM browsers like Firebug seem like they could help, but it's still time consuming to browse all of an element's event handler properties just to find one that executes the code you're looking for. Even then it usually just tells you it's an anonymous function() with no line number.
The technique I've found for discovering what JS code gets executed when events are triggered is to use Safari's Profiling tool which can tell you what JS gets executed in a certain period of time, but that can sometimes be a lot of JS to hunt through.
There's got to be a faster way to find out what's happening when I click an element. Can someone please enlighten me?
Check out Visual Event... it's a bookmarklet you can use to expose events on a page.
If you're using jQuery you can take advantage of its advanced event system and inspect the function bodies of event handlers attached:
$('body').click(function(){ alert('test' )})
var foo = $('body').data('events');
// you can query $.data( object, 'events' ) and get an object back, then see what events are attached to it.
$.each( foo.click, function(i,o) {
alert(i) // guid of the event
alert(o) // the function definition of the event handler
});
Or you could implement your own event system.
To answer your question, try using the Firebug command line. This will let you use JavaScript to quickly grab an element by an ID, and then iterate through its listeners. Often, if used with console.log, you'll even be able to get the function definitions.
Now, to defend the unobtrusive:
The benefit I find in unobtrusive JavaScript is that it is a lot easier for me to see the DOM for what it is. That said, I feel that it is generally bad practice to create anonymous functions (with only few exceptions). (The biggest fault I find with JQuery is actually in their documentation. Anonymous functions can exist in a nether-world where failure does not lead to useful output, yet JQuery has made them standard.) I generally have the policy of only using anonymous functions if I need to use something like bindAsListener from Prototype.
Further, if the JS files are properly divided, they will only be addressing one sub-set of the DOM at a time. I have an "ordered checkbox" library, it is in only one JS file which then gets re-used in other projects. I'll also generally have all of the methods of a given sub-library as member methods of either a JSON object or a class and I have one object/class per js file (just as if I were doing everything in a more formalized language). If I have a question about my "form validation code", I will look at the formValidation object in formvalidation.js.
At the same time, I'll agree that sometimes things can become obtuse this way, especially when dealing with others. But disorganized code is disorganized code, and it is impossible to avoid unless you are working by yourself and are a good programmer.
In the end, though, I would rather deal with using /* */ to comment out most of two or three js files to find misbehaving code, then go through the HTML and remove the onclick attributes.
Calling it "kool-aid" seems unfair. DOM Level 2 events solve specific problems with inline event handling, like the conflicts that always result. I don't look back to writing code to use window.onload that has to check whether someone else has assigned it before, and sometimes having it overriden by accident or out of sloppiness. It also ensures a better separation of the structure (HTML) and behaviour (JS) layers. All in all, it's a good thing.
Regarding debugging, I don't think there's any way to solve the event handlers being anonymous functions, other than nagging the authors to use named functions where possible. If you can, tell them that it produces more meaningful call stacks and makes the code more maintainable.
One thing: you shouldn't be able to see what will happen in JavaScript by looking at the HTML code. What nuisance is that? HTML is for structure.
If you want to check what events are bound to certain elements, there's a bookmarklet called visual event for now, and firebug 1.6 (IIRC) will have some sort of event inspector.
The problem: I have a jQuery heavy page that has a built in admin interface. The admin functions only trigger when an admin variable is set. These functions require a second library to work properly and the second file is only included if the user is an admin when the page is first created. The functions will never trigger for normal users and normal users do not get the include for the second library.
Is it bad to reference a function does not exist in the files currently included even if that function can never be called? (does that make sense :)
Pseudocode:
header: (notice that admin.js is not included)
<script type="text/javascript" src="script.js"></script>
<script type="text/javascript" src="user.js"></script>
script.js: (admin functions referenced but can't be executed)
admin = false; // Assume this
$(".something").dblclick(function(){
if(admin)
adminstuff(); // Implemented in admin.js (not included)
else
userstuff();
});
Ideas:
I suppose two separate files for users and admins could be used but I feel that would be an overly complicated solution (don't want to maintain two large files with only a few lines of difference). The only reason I include a reference to the admin function in this file is I need to attach it to page elements that get refreshed as a part of the script. When jQuery refreshes the page I need to reattach function to interactive elements.
The Question:
I want to keep things very simple and not have to include file I don't have to if they will not be used by the user. Is this a good way to do this or should I be going another route?
The code should operate without error, since the admin functions without implementation will not be called. The only thing that is really being wasted is bandwidth to transmit the admin code that is not used.
However, let me caution against security through obscurity. If the user were to view this code and see that there are admin functions that they cannot access, they might get curious and try to download the "admin.js" file and see what these functions do. If your only block to keeping admin functions from being performed is to stop including the file, then some crafty user will probably quickly find a way to call the admin functions when they should not be able to.
If you already do server side authentication/permissions checking for the admin function calls just ignore my previous paragraph :-)
Personally, I would bind (or re-bind) the event in admin.js:
$(function() {
$(".something").dblclick(function(){
adminstuff();
});
});
function adminstuff()
{
// ...
}
That way, the adminstuff() call and the function will not be visible to "normal" users.
Good question. It shouldn't cause any JavaScript problems.
Other things to consider: you are potentially exposing your admin capabilities to the world when you do this, which might be useful to hackers. That's probably not much of a concern, but it is something to be aware of.
See also:
Why can I use a function before it’s defined in Javascript?
I don't think it matters. If it makes you feel better, you can make an empty stub function.
I don't think there's a dogmatic answer to this in my opinion. What you're doing is...creative. If you're not comfortable with it, that could be a sign to consider other options. But if you're even less comfortable with those then that could be a sign this is the right thing (or maybe the least wrong thing) to do. Ultimately you could mitigate the confusion by commenting the heck out of that line. I wouldn't let yourself get religious over best practices. Just be willing to stand by your choice. You've justified it to me, anyway.
Javascript is dynamic - it shouldn't care if the functions aren't defined.
If you put your admin functions in a namespace object (probably a good practice anyway), you have a couple of options.
Check for the existence of the function in the admin object
Check for the existence of the admin object (possibly replacing your flag)
Have an operations object instead, where the admin file replaces select functions when it loads. (Even better, use prototypical inheritance to hide them.)
I think you should be wary that you are setting yourself up for massive security issues. It is pretty trivial in firebug to change a variable such as admin to "true", and seeing as admin.js is publically accessible, its not enough to simple not include it on the page, as it is also simple to add another script tag to the page with firebug. A moderately knowledgeable user could easily give themselves admin rights in this scenario. I don't think you should ever rely on a purely client side security model.