I'm using MarkItup to turn my form textarea into a WYSIWYG editor:
http://markitup.jaysalvat.com/home/
The textarea is configured as follows:
<script type="text/javascript" >
$(document).ready(function() {
$("#markItUp").markItUp(mySettings);
});
</script>
The textarea works well and I can format my input into HTML mark-up. However when I submit my form the POST data is not present for the textarea. If I remove the initialisation above and resubmit the textarea input is in the POST data.
I know this is a Jquery plugin which might rely on serializing the form input, but how can I POST my form without jQuery? I seems a bit short sighted and lazy to not allow this feature.
Anyone know?
The short answer is to use a proper mark up tool, TinyMCE posts the marked-up input enabling it to be processed via a regular server form submit.
Related
I have an HTML form which a user may have filled in or partially filled in. I want to snapshot that state and render it as a PDF document. I've been using wkhtmltopdf.
I've tried this from both the client side and the server side, and the rendered result is always the original form, never the filled-in one.
I notice if I reload the filled-in form page I get back the filled-in form, but if I cut and paste the form's URL into a new window, I get the initial, non-filled-in form.
So I've convinced myself that, if I could use CGI::Session properly, I could successfully open a session identical to the filled-in session. I tried using CGI::Session::Plugin::Redirect with no joy. I think the key is that window.open() has to use the SID of the filled-in form window.
I don't have a lot of experience with CGI session management, so this has been a four-day quest to nowhere. Any advice is appreciated, even if it's to abandon this approach and go back to the more common post->render a new form in a new window, and generate the PDF from that. I'd like to avoid all of that if I can.
Say you have the following HTML document on your web server:
/var/www/html/index.html
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<form action="/process.cgi">
<input type="text" name="foo">
</form>
</body>
</html>
When you navigate to http://hostname/index.html in your browser, the webserver returns this document and the browser displays it.
When you fill in the text field in your browser, the document on the webserver doesn't change. So anybody who navigates to http://hostname/index.html will get the original, unmodified form. This is why you can't simply copy and paste the URL into another browser tab and get the filled-in form.
Most browsers use caching by default. When you fill in some fields in a form, the browser caches what you entered. When you reload the page, the webserver sends the exact same document as before* (i.e. the unmodified form), but the browser uses the cached data to fill in the form fields the way you had them. If you override the cache when you reload the page (Ctrl+F5 in Firefox), the form fields will not be filled in. Note that neither the URL nor the document on the server have changed. This is why you can't copy and paste the URL into another browser tab after reloading the page and get the filled-in form.
wkhtmltopdf takes a URL, renders the corresponding page, and generates a PDF based on what is rendered. Based on the explanation above, it should now be clear why wkhtmltopdf always generates an image of the unmodified form.
The solution
If filling in form fields doesn't change anything on the webserver, what does it change? It changes the DOM, a structure describing the document in your browser that you can access using JavaScript.
One approach would be to use a client-side JavaScript PDF generator like jsPDF; since it runs on the client, it has access to the DOM that the user is interacting with, so it can "see" the values the user enters into the form fields.
* Actually, the webserver will typically send a 304 Unmodified response to save bandwidth, but form caching works the same either way.
The explanation from ThisSuitIsBlackNot is accurate about why your design is failing. Typing characters into form fields in a browser changes only your screen and the data in the memory allocated to the browser.
I suggest a different solution. The WWW::Mechanize::Firefox module is a variant of WWW::Mechanize that uses a real browser application to retrieve and render web pages. It is mostly chosen when a site requires JavaScript support, but it is useful here because it has a content_as_png method which returns a PNG image of the current page. Hopefully that is enough for you to build a PDF file with the required content
If I have a SELECT tag that will filter a table based on a user choice, does the SELECT tag need to be in a FORM tag (to be valid HTML5), if the resulting functionality will not work if JS disabled (i.e. we'll show the entire table or a 'more' link instead of doing a server-side filter on select of the form action/submit option (We may write the select in JS so it disappears from the markup if JS disabled.
Or do all form elements need to be in a form tag regardless of usage (and therefore a null 'action' attribute value).
I know HTML5 allows almost anything, I just couldn't find a definitive answer on W3, so thought I'd get your thoughts. Hope that makes sense.
Cheers.
All the form controls can be used anywhere where phrasing content is expected, which means they can appear just about anywhere in the body of the document. If you don't need to have them submitted back to a server then there's no need for them to be associated with a form, however I've noticed that in some browsers you can't take advantage of the form validation features unless the elements can potentially be submitted.
One feature new to HTML5 is that form controls no longer need to be the direct child of a form element in order to be submitted with that form, the form attribute allows you to specify the id of the form the element should be submitted with.
It would appear that in HTML5 form elements can be outside of a <form> tag and still be valid;
<!DOCTYPE html>
<html>
<head>
<title>Just making this valid</title>
</head>
<body>
<select>
<option value="1">One</option>
<option value="2">Two</option>
<option value="3">Three</option>
</select>
</body>
</html>
The above code validates successfully (minus the obvious character encoding errors).
I haven't read the entire HTML5 Spec, however the validator is usually correct on these sorts of matters.
The HTML5 spec specifically allows <input>s (and other form-associated elements) not to have a <form>:
A form-associated element can have a relationship with a <form> element, which is called the element’s form owner. If a form-associated element is not associated with a <form> element, its form owner is said to be null.
So feel free to use them wherever your heart desires!
I would like to change the default behavior of Zend_Form, so that whenever the submit button is clicked, form submission is prevented and an arbitrary JavaScript function is called. This would be done for all forms on the site, however the actual JS function to call may change from form to form.
What would be the most proper way to do this? Through a custom decorator on the submit element? Could you provide some tips?
Thanks.
In my opinion, Zend_Form shouldn't need or desire any knowledge of the JavaScript. I would add a class to the form and use that class name as your hook for applying javascript.
Imagine a form:
<form class="validate-me">
<!-- //elements -->
<input type="submit">
</form>
You can then apply your JavaScript to forms with a given class name (pseudo JS, use a library)
var el = document.getElementsByClassName('validate-me')[0];
el.on('submit', function(e){
//validate the form, stop the event if invalid
});
If you want to add extra markup or attributes instead of this approach then you will certainly need to look at decorators.
due to security and implementation reasons that are out of the scope of this post, I need to submit multiple forms in a single page to different iFrames (one iFrame for each form). I can't use jQuery nor AJAX, it has to be done via:
<script>
document.Form1.submit();
</script>
The problem is, after I submit the first form (everything goes well), I can't submit the other three forms. I'm guessing only one form.submit() call is allowed per page. Is there a way around this?? I have no problem with submitting all the forms at the same time.
Ps: I'm forwarding the post request to the iframe using the target param of the form. Like this:
<form id='Form1' name='Form1' action='https://www.xxx.com/index.php' method='post' target='iFrame1'>
Thanks a lot in advance for your time and help. Best regards,
You can also have multiple forms and have each form submit to a separate iFrame.
I have a form which submits to an iframe, This works fine if you are on a page with the iframe.
I want to be able to have the form on any page and when submit is pressed load a page and send the submit to the iframe
e.g.
On page "article.php" and press submit
Open page "results.php" and
Send post data from form clicked in "article.php" to iframe "DataHere" on "results.php"
Thanks in advance
You could try detecting if the frame exists when the form is submitted and if it does not, reload the whole page and generate the iFrame.
If you need a hand checkout http://www.java-scripts.net/javascripts/Check-Frames-Page-Script.phtml
If you are able to comfortably sanitize your initial POST data to avoid XSS, you could create an intermediate page for your iframe destination that does your POST for you:
On page article.php with <form action="results.php">, press submit.
results.php validates that the input isn't XSS, and renders with a <iframe src="negotiator.php?my=form&data=here"></iframe>
negotiator.php takes the query string arguments (and runs the same sanitizing as results.php) and POSTs them to your intended url.
Your results will load in the iframe.
It's pretty important that you make sure your input isn't insane. If your form requires arbitrary text, punctuation, and special characters, this is not safe for you.