Earlier today I emailed the grades for the last homework. Most of you did not do as well as usual. Things to get complicated once we start to try to put all these topics together into a nice app. Below is my partial solution to the homework (also here, just view-source). It's in the form of a jsfiddle so you can open it on its own window and start playing around with it to make sure you understand how its doing its magic, just press the '+' on the top right. I might be upgrading it as you provide me with bug reports.
A few tips:
- As mentioned in class, the
.livejQuery function comes in really handy when you want to register events to elements that (dis)appear dynamically. With it, you don't have to remember to re-register events on each creation (and delete on deletion to avoid memory leaks). - The
.each()function is also very useful. - You don't need to have
ids for everything. The jQuery selectors are very powerful: use them.
Posts
the requirements state that the input field must have a save and cancel button, including these buttons would cause your focusout to fail, as clicking on the button would cause a focuout event and the field would disappear, you could add a timeout to pause the function before leaving focus, but in one of the many rewrites I had to do, it was less than graceful. And I had to completely remove the focus out events from my code.
ReplyDeleteYes. I did not add the save and cancel buttons because I wanted to keep the example as short as possible: short code is easier to understand.
ReplyDeleteGetting the save and cancel buttons to work requires a couple more functions: see http://jsfiddle.net/jmvidal/zwAQF/
I think one must do either focusout or 'save button', but not both. If the focusout saves the text then having a 'save' button is redundant (actually, the button would be useless then because before you hit it you Have to focusout of the textbox anyway).
In a production application, wouldn't it be better from a user experience standpoint to have an explicit way of saving the new text(making the change)? In other words, from a user interface standpoint, just wondering if a focus out should actually save the information? If instead, it reverted back to the original state, this would prevent accidental field changes... I have seen both in play in apps I support at work, what is your take on this?
ReplyDeleteOh, and yes, there is a bug in that previous fiddle: if the user clicks on a second choice before hitting 'save' on the first one the code will get confused. Hopefully our user will never do that!
ReplyDeleteMaybe, someone can a solution for that problem?
Well, in flickr the changes a user makes on the textbox are not saved until he clicks on 'save'. That is, focusout on flickr does nothing, like in my second solution.
ReplyDeleteI think that does help prevent accidental field changes.
OTOH, the focusout is really nice when the user has to fill out a LOT of textboxes, just type-tab-type-tab etc.
So, I think it depends on how many textboxes the user will be changing in a row.
how would you limit the number of choices to >=2 but <=5?
ReplyDeleteProbably by counting children and refusing to add/delete if at the borderline.
ReplyDelete