Sisyphus is a plugin that deals with auto saving of forms in local storage.
It works pretty well on first look. What I want to know, is it possible to use with a dynamic page driven by an ID.
eg: MyPage/1 and MyPage/2 (MVC url's but could equally be querystrings), such that the page is rendered, maybe bringing some value back from a database, rendering some unique controls.
In other words, can Sisyphus deal with a parameterised page?
Turns out it's actually really easy.
We can use the locationBased option as per documentation
$("form").sisyphus({
locationBased: true
});
I am working on an old legacy application which used document.forms[index] approach to access elements in the form and to submit the form. My task is to add a new top panel with few textboxes and buttons. I am using a form for this. This top panel is to be included in all the pages in the application. Now, all the pages stop working since form[index] needs to be updated in all the pages. I know using the form name is the best approach. I have around 1000 places to change. What is the best approach to avoid this problem? I still want to use form for my top panel since I am using spring forms to get the data. Any valuable advice will be appreciated. Thanks.
If you looked up the definition of "unmaintainable", that would be a good example.
One trick might be to leave one set of forms, hidden, with the legacy stuff in them, then make another set, lower in the HTML, that the user sees. Then use some JavaScript to map the data back into the original forms in order to continue to work with the expectations of the legacy code. This keeps everything in the same index-order.
I'm building a budget webapp, mostly for my personal needs and for the sake of self training. I may release it later at some point.
The interface will feature a table of operations (credit / debit). I was planning to use Ajax to make the table "editable" by clicking in a cell (Excel-like).
I therefore need to:
diplay operations
add new ones
modify existing ones
I fail to see how to make "modify" degrade nicely, as if you remove JS, this will be a plain old table without the possibility to modify an existing entry.
Turning the table into a giant form would be ugly, adding links to edit each operation then hide them using JS seems fairly complex...
One possible solution would be to add links that go to other forms that allow the modify operations to take place. This is much less fluid than in-place edits for accounts, but it still remains accessible without being burdensome (like a huge page of form inputs would be).
You can then override the links with javascript to give the ajaxy, web-app functionality you are looking for.
Philosophical question:
Say I've got a web app that requires javascript and a modern browser, so progressive enhancement is not an issue. If my form is being built via javascript, and my data updates are all being done via ajax POSTs & PUTs, is there really any reason to wrap my controls in a form tag? If I'm still going to use the tag, say for semantic or structural reasons, is there any reason to have action and method params that I'm going to ignore? It kind of feels like a hold-over from an earlier era to me.
There is at least one important user-experience feature provided specifically by wrapping inputs inside a form tag:
The enter key will submit the form. In fact, in Mobile Safari, this is how you get the "Go" button to appear on the keyboard.
Without a form wrapping the inputs, there is nothing to submit.
You can of course provide enter-key behavior through a keypress event, but I don't know about if this works for mobile devices. I don't know about you, but I'd rather work with the semantics provided by the browser than have to imitate them with events.
In your case, you would simply provide an onsubmit event handler for the form, which would do your AJAX submit, then return false, canceling the actual submit.
You can simply provide action="" (which means "self"), and method is not required — it defaults to GET.
If you do not need progressive enhancement, you theoretically don't need them.
On the other hand, forms have some cool grouping and semantic effects. Using them, you can group your form elements logically, and make it easier for your scripts to gather the values of certain elements.
For example if you want to ajax-submit some user input, it is always easier to say: "let's take all elements in this form and submit them" than saying "let's take this input, these two selects and these three textareas and submit them". In my experience, it actually helps the developer if form tags are present.
AJAX is great but as JamWaffles (+1 to him) said, using form tags provides a fallback method.
Personally I use form tags, even for things I submit with AJAX because it is syntactically clear and makes it easy to grab all inputs within a specific form. Yes you could do this with a div or whatever too but as I said, using a form is syntactically nice.
Incidentally, screen readers treat the content inside a form differently so there are accessibility issues to be considered whichever way you choose to go. Note that anecdotal evidence suggests that Google considers accessibility in its rankings so if SEO is a concern for you, use a form and do it right.
Summary:
forms OK for MVC, simple web apps, bad for component oriented, rich web apps.
Reason:
forms cannot nest other forms: big limitation for a component-oriented architecture.
Details:
For typical MVC applications, forms are great. In rich, complex web applications using a lot of javascript and AJAX and with a lot of components here and there, I don't like forms. Reason: forms cannot nest another forms. Then if each component renders a form, components cannot nest each other. Too bad. By changing all forms to divs, I can nest them, and whenever I want to grab all parameters in order to pass them to ajax, I just do (with jQuery):
$("#id_of_my_div").find("[name]").serialize();
(or some other filtering)
instead of:
$("#id_of_my_form").serialize();
Though, for sentimental and semantic reasons, I keep naming my divs something_form when they are acting as forms.
Not that I can see. I'm currently building a web application that uses <form>s, but I'm using them so I have a fallback method if the user has JavaScript disabled (an e.preventDefault stops the form posting normally). For your situation, where you're saying the user MUST have JavaScript, a <form> tag isn't necessary, but it might be an idea to keep it anyway in case browser need to do anything with it, or to access it as a sort of class.
In short, no, you don't need to use <form> if you're doing pure AJAX, although leaving it in might an idea if you suddenly decide to create fallback code in the future.
In my opinion: If you use it for semantic reasons, then use it as intended. The action attribute is required (also can be left empty) to be well-formed, also you can separate your URI-s from your js logic, by setting the action attribute, and reading it before the ajax call.
I don't see why you would need to use the form tag here. The only reason to use a form tag (other than to get your markup to validate) is if you are going to have the user "submit" the data using a sumbit input or button tag. If you don't need to do that, then there is no need for the form. However, not sure if it will be considered "valid" markup. If you do use it you can just do <form action=""> as action is the only required attribute of the form tag. However, you do bring up a good point, the future of web applications probably will no longer need the form and traditional submit methodology. Very interesting, and makes me happy. hehe :)
I am in the process of converting a Silverlight app into a standard Web app (ie all HTML, CSS and JavaScript via jQuery 1.4.4). I'm not the most experienced when it comes to web development, so I am wondering what would be the best way to convert this custom Silverlight control into a web equivalent?
It boils down to just being a fancy radio button group. The user can click on any type, and only one type can be selected at a time. For the web equivalent, it needs to set a value that will get POSTed to the server.
For now I am just using a standard <select> tag which is of course functional and doesn't require JavaScript (which is nice), but ultimately is not going to fly. I will place a <select> inside of a <noscript> tag to allow non-js people to still be functional.
Can anyone recommend a good approach for tackling this? Any existing plugins/controls out in the wild I could take advantage of?
(I am using ASP.NET MVC 3, but I don't think that's very relevant here)
I would use a <ul> and make the selections a <li>. Styling is easy enough to apply to that, and there are tons of samples online.
Place a click on the li using jQuery to disable. If you are going to disable other selections, you should also include a reset/clear type function to they can choose again in case they made a mistake.
Think of them as an array of buttons. When one is clicked, all others are unselected. Draw a rectangle around the one that was clicked and set a hidden form field equal to the value you expect when the form is submitted.