When doing web programming there seem to be two different ways of handling a form and its action. Is there a reason to prefer one method over the other?
Method 1: One page that displays a form or handles a submitted form. This seems simple, in that there's one form for everything. But it also means the if/else cases can become rather large.
if [form has not been submitted] {
// display form for user input
} else {
// handle submitted form
}
Method 2: Handle user input on one page with a form, with the form submitting to a second page.
page 1 (input.html):
<form action="./submit.html">
// display form for user input
</form>
page 2 (submit.html): Handles the input from the form.
I've seen both of these methods used. The upside of the first method is that there's only one page and one set of variables to worry about, but the page can get large. In the second method, each file is simpler and shorter, but now you have twice as many files to worry about and maintain.
I typically submit back to the same page, as you will often need to redisplay the initial page if there are validation errors.
Once the record has been successfully saved, I typically use the Post/Redirect/Get method to avoid the common multiple submit issue.
I think it depends on what kind of form it is. If it has too much validation I would go with two pages.
I always use to pages though because I like my code to be clean, but I use AJAX whenever possible e.g. contact forms since they are short, and I just post the response back to a div in the form.
Caching.
If the server has a series of static HTML pages livened maybe only by AJAX (and even these requests cached, server side, per user), it reduces its load and traffic significantly. Then confining the dynamic content of targets of forms to a relatively small area is a boon, because a page that is a target of POST can't be retrieved from the cache, it has to be regenerated from scratch no matter how heavily loaded it is.
Of course this doesn't solve the question of n static pages + 1 CGI vs n static pages + m CGI.
But once you don't need to spit out sophisticated HTML, just a simple redirect, keeping things in one place may be profitable - error checking and handling, authentication, session management and so on.
OTOH if every your page is a CGI script that creates a new page on each visit, there is no reason why it can't accept form data and handle it at the same time.
Related
If I want to send data back to the server from user input I know I need to use the form tag.
But why do I need the form tag, what does a form tag do behind the scenes?
I've only been in web development for less than a year, so please forgive me if my question is beginner question.
Edit: I know a form is used to denote a part of the page that is interactive and data between the from tags will be sent back to the server.
So, is the tag, just a tag, is there another piece of technology that takes the data from the page and returns the data to the server?
Edit 2: From comments and more specific web searches, I found out that the form tag is just that. A tag. It defines something on a page and does not do anything. All is okay now.
The form tag validates and with html 5 it means it doesn't call the server immediately. It can do a quick check before it attempts to post. E.g. does the email box look like an email address.
The advantage of this is it reduces costs as you're not unnecessarily calling the server. When the form thinks it looks good it will send the info to the back end.
Get and post messages are sent either getting information (reading) or it might be posting (writing).
I think that's what you're after.
I am writing a program for managing an inventory. It serves up html based on records from a postresql database, or writes to the database using html forms.
Different functions (adding records, searching, etc.) are accessible using <a></a> tags or form submits, which in turn call functions using http.HandleFunc(), functions then generate queries, parse results and render these to html templates.
The search function renders query results to an html table. To keep the search results page ideally usable and uncluttered I intent to provide only the most relevant information there. However, since there are many more details stored in the database, I need a way to access that information too. In order to do that I wanted to have each table row clickable, displaying the details of the selected record in a status area at the bottom or side of the page for instance.
I could try to follow the pattern that works for running the other functions, that is use <a></a> tags and http.HandleFunc() to render new content but this isn't exactly what I want for a couple of reasons.
First: There should be no need to navigate away from the search result page to view the additional details; there are not so many details that a single record's full data should not be able to be rendered on the same page as the search results.
Second: I want the whole row clickable, not merely the text within a table cell, which is what the <a></a> tags get me.
Using the id returned from the database in an attribute, as in <div id="search-result-row-id-{{.ID}}"></div> I am able to work with individual records but I have yet to find a way to then capture a click in Go.
Before I run off and write this in javascript, does anyone know of a way to do this strictly in Go? I am not particularly adverse to using the tried-and-true js methods but I am curious to see if it could be done without it.
does anyone know of a way to do this strictly in Go?
As others have indicated in the comments, no, Go cannot capture the event in the browser.
For that you will need to use some JavaScript to send to the server (where Go runs) the web request for more information.
You could also push all the required information to the browser when you first serve the page and hide/show it based on CSS/JavaScript event but again, that's just regular web development and nothing to do with Go.
I am volunteering on a website-based project that is trying to make all pages fully operable JavaScript free before adding any JavaScript for enhancements, and I was asked to investigate whether or not a particular scenario could be handled purely through HTML/CSS.
What we have is a form that is populated to help us filter a list of tickets that are displayed on the screen after a page update through a GET action, which itself works fine, but the concern with the current implementation is that the URL cannot be made into a permanent link. The request, however, to keep the permanent link as minimal as possible, is to only send GET parameters for fields that are populated with something (so, suppressing GET parameters for fields that are blank) instead of having a different GET parameter for each form field on the page.
I have thought of several ways that could be done, most including JavaScript (example: create fields with ids but no names and a hidden field w/ name that uses JS to grab the data from the fields), but also one that would be a POST action with a redirect back to the GET with a human readable string that could be permanently used. The lead dev, however would prefer not to go through the POST/redirect method if at all possible.
That being said, I'm trying to make sure I cover all my bases and ask experts their thoughts on this before I strongly push for the POST/redirect solution: Is there a way using only HTML & CSS to directly suppress GET parameters of a form for fields that are blank without using a POST/redirect?
No, suppressing fields from being submitted in an HTML form with method of "GET" is not possible without using JavaScript, or instead submitting the form with a POST method and using a server side function to minimize the form.
What fields are submitted are defined by the HTML specification and HTML and CSS alone cannot modify this behavior and still have the browser be compliant with the standards.
No, you cannot programmatically suppress any default browser behavior without using some kind of client scripting language, like JavaScript.
As a side note, you say "JavaScript for enhancements", but JavaScript is not used for enhancements these days. And no one in the real world would except a decent front-end without the use of JavaScript. I would suggest you simply use JavaScript.
I do not think you can avoid Javascript here to pre process before submission to eliminate unchanged /empty form fields.
I'm running a content-based website, and I usually used ajax to dynamically add items to the content list. Every time I updated my item structure I have to change my javascript to fit the new structure. I wonder whether there was any solution to keep script stable regardless of the changing of HTML?
Simple, instead of using the DOM to handle your data, process everything upon completion of the ajax request and only then call a function that has all of your data display functionality. Obviously you can't get away from having to change some code somewhere when you for instance rename HTML elements but you can separate concerns so that you only have to touch code in one place.
I do quite a bit of this in my app, and I follow the same pattern every time:
View page fires an ajax function to another page, which I call the "dispatcher" I use this pattern because I want a plain text output without header, footer, other JS, etc, so the dispatcher is a simple page that gets the request from the Ajax, fires appropriate PHP functions, and echos the results. In some cases it will return JSON strings while in others it will return HTML or plain text. For your example, return HTML from your server-side language.
Back in the AJAX success callback, inner html (.html()) an element with the returned html content. Have your server side language do the work of assembling the HTML (or even text if you're so inclined) because it is far less work and less overhead to accomplish.
Not too bad, huh?
I read some AJAX-Form tutorial like this. The tag form is used in HTML code. However, I believed that it is not necessary. Since we send HTTP request through XmlHttpRequest, the sent data can be anything, not necessary input in form.
So, is there any reason to have form tag in HTML for AJAX application?
Apart from progressive enhancement as already discussed (don't make your site require JavaScript until it really has to), a <form> with onsubmit would be necessary to reliably catch an Enter keypress submission.
(Sure, you can try trapping keypresses on separate form fields, but it's fiddly, fragile and will never 100% reproduce the browser's native behaviour over what constitutes a form submission.)
Sometimes, web apps using ajax to transform their data either use forms as a fallback when the user has no JavaScript enabled (a sometimes expensive but very good thing to do).
Otherwise, if an application builds and sends an AJAX request, there is no compelling reason to use a form except in rare special cases when you actually need a form element. Off the top of my head:
when using jQuery's form serialize function
when monitoring all fields in a form for changes
when there is need to make use of the reset form button (that to my knowledge is available in a proper <form> only).
I see at least two possible reasons :
Graceful degradation (see also Unobtrusive JavaScript) : if a user doesn't have Javascript enabled in his browser, your website should still work, with plain-old HTML.
Behavior of the browser : users know what forms look like and how they behave (auto-completion, error-correction, ...) ; it's best not going too far away from that
And I would add that, if you want the user to input some data, that's why <form> and <input> tags exist ;-)
Using the right tags also helps users -- as an example, think about blind users who are navigating with some specific software : those software will probably have a specific behavior for forms an input fields.
It really depends what you're doing. If you're wanting to take form content submitted by the user and use AJAX to send that somewhere then you're going to want to use the form tag so your user can enter their data somewhere.
There will be other times when you're not sending data from a form and in that case, you wont have a form to be concerned about :)