I’m trying to determine the best approach, but am struggling with the following:
By “UI component” I’m assuming this is supposed to be done using jQuery UI? In that case, dialogue box seems like a viable option, but maybe I’ve overlooked something?
If needing to exist in multiple locations on a site and/or two instances on the same page, should I take this as a cue to avoid IDs and only use classes, or are there larger implications beyond the CSS?
This is a demo/test login page, so the site itself doesn’t actually exist. How can I go about testing various logins without hard-coding in some fake user IDs and passwords? Is that even possible?
I’m confused by the URL provided: api.yoursite.com/login. Is it assumed that /login is tied to a PHP file?
I don’t see how this can’t involve a server-side language, but the requirements only permit me to use jQuery, HTML and CSS. Is cross-domain Ajax the answer?
var loginOne = new My.UI.LoginBox( '#loginOne' );
var loginTwo = new My.UI.LoginBox( '#loginTwo' );
NOTE: an HTML element can have both a class and an id attribute.
You don’t have to code everything from scratch, you’re using jQuery. But not jQuery UI. You should use HTML5 API (I’m guessing web sockets) and latest CSS, CSS3. You don’t need to test for IE8 and below or iOS 5 and below.
Just plain form submit rules, no server side response handling requested.
Thanks for the feedback. I have some follow-up questions:
Could you explain how this works in more detail? var loginOne = new My.UI.LoginBox( ‘#loginOne’ ); var loginTwo = new My.UI.LoginBox( ‘#loginTwo’ );
If one of the requirements is that the login box can have 2 instances on 1 page, then shouldn’t’ I avoid using IDs? (this also applies to the previous question)
What about web sockets I should know / be incorporating that I’m currently not?
Is there anything significant about accounting for iOS 6 and up? Anything important that iOS 6 introduced that would be easy to overlook? This is when iPhone 5 launched…
Let’s say there’s www.yoursite.com and api.yoursite.com, isn’t the latter technically in a different domain than the former? Am I making this more complicated than it needs to be?
HTML: both login boxes have the same class, yet each one has it’s own unique id
JS: the programming logic behind the login box component needs to account for more than one User ID, Password or Submit button, i.e. be login box id specific (see HTML above)
The way your fiddle is right now, when you have two login forms on the page, with one submit button $(“.loginSubmit”) you are targeting both forms.
iOS 6 is a big step forward supporting HTML5 and CSS3. It actually makes you job easier by not asking you to be backward compatible.
And finally, forget about web sockets, I now see you have to AJAX. Maybe look for some other HTML5 stuff, like local storage for login details. http://code.google.com/p/sessionstorage/
How do I go about checking the login credentials if no server side response handling is requested? I know how to validate the ID and password fields for correct formatting, but need to factor in username/password combos to test this out, no?
I’ve updated the fiddle with my latest attempt. Does the JSON object I’m attempting to create come close to what you’re describing? And how would I go about simulating the AJAX response? Getting down to the wire, and would really appreciate any additional insights. Thanks for your help!
Stop making this about server-side, you are only required to build the front-end UI component that is independent of what the server-side is. So get rid of that /scripts/login.php and use what they asked you: api.yoursite.com/login
You don’t have a reusable component yet. So you can’t use two instances on the same page yet. Focus on that. Objects, anyone?
So I’m assuming I’ll need to use Ink.js for the job? I guess I could do so and still satisfy the requirements, but wanted to make sure that’s what you were getting at.
I’ve looked into Ink.js and tried to figure out a workable solution for my login boxes. Here’s what I’m thinking:
Each login box should be treated as a separate <form> instance, which means each will need an ID. I’m thinking an .each() function to dynamically assign the IDs would do the trick. (Although, if I only need to account for a max of 2 instances per page, this could make the ID assignment much simpler)
I’ll be able to treat each as a separate UI component once there’s a unique identifier. I can then worry about loading a separate script for each component, which is how Ink.js handles multiple.
After #s 1 and 2, the code you gave me earlier will be more applicable (i.e., var loginOne = new My.UI.LoginBox( ‘#loginOne’ ); var loginTwo = new My.UI.LoginBox( ‘#loginTwo’ );
Does this sound like a logical approach to you, or is there something I’m overlooking? Am I crazy?
Assign ID to <div> container of each separate form instance (using .each())
Once each form has a unique ID, I can treat them as separate UI components and worry bout loading a different script file for each, which is what Ink.js does
After #1 and #2, your code from earlier will be more applicable (i.e., var loginOne = new My.UI.LoginBox( ‘#loginOne’ ); var loginTwo = new My.UI.LoginBox( ‘#loginTwo’ )
You have a single script. The script receives different HTML elements as parameters and manages separate state and common behavior for each of them. That’s what new is about, with different login boxes parameters. That’s what the requirement of having two instances of login boxes on the same page is about.
Alright, two separate <form> instances are now tied to a single script. I’ve changed a number of things, but I think my latest attempt encapsulates more and is easy to re-purpose. Do you see any issues with this approach?
I’m not looking to burst your bubble or anything, but if this is for a job interview, I believe they expect a whole lot more from you. They gave you a deceivingly simple task and maybe I’m wrong here, but I think that they expect much more from you than a simple function and I think that they expect much more from you than a simple jQuery widget.
While any of the simpler approach would be enough to complete the task, I believe they expect you to be familiar with more advanced topics and techniques. Personally, I think that that’s why they mentioned jQuery together with IE9+. jQuery starting with v2 has dropped support for IE8- and is also supporting a modular approach.
They will asses your level depending on your approach. You seem to have trouble coping with terms like component, instances, domain. When you mix together OO, AMD and modular jQuery, for a JS newbie things start to get real crazy real fast. There’s a lot of ground to cover. Let me know how it goes, and, after New Year, if you still want, we could get into this.