On a webpage we have the following system of server side form validation. For example, if the user is adding date-details for an event (and an event can contain many such date-details), we call a javascript function on click of the 'Add' button like below.
validateForm('frmName','codelibrary/classes/myclass.php','validationArrName')
where:
#frmName = form name
#codelibrary/classes/myclass.php = location of class file, that contains classes and functions for server side validation
#validationArrName = Type of validation we apply
In the php script, validationArrName is defined as a list of keys (representing form fields) and values (representing the functions we will call to validate that form field).
validationArrName = array ('fieldName1'=>validationFun1,'fieldName2'=>validationFun2);
eg:
fieldName1 = email_address
validationFun1 = validateEmail()
On the html page, we call the server side validation through ajax as follows.
$.post(className,$("form[name="+formName+"]").serialize()+"&isValidate=1&validateArrayName="+validateArrayName,function(data){ ... });
If the validation function reports an error, we display an appropriate error message back on the html page.
The problem is that when we do this for the very first time (eg: after a hard refresh of the page), submitting this date-details form for validation takes a lot of time, as compared to subsequent requests.
We observed that instead of calling the codelibrary/classes/myclass.php file once, it actually refers to this file more than 10 times before jumping to the required location (validationArrName) and running that.
For subsequent requests, it works fine and refers to that file only once.
What could be the issue here? Could there be an issue with our usage of jquery submit ?
the best thing you can do is time stuff.
in javascript:
console.time('post load'):
$.post(className,$("form[name="+formName+"]").serialize()+"&isValidate=1&validateArrayName="+validateArrayName,function(data){
console.timeEnd('post load');
console.log('data');
...
});
in php, use microtime to time different part and echo them. they will be printed in the console.
It should not be cache or include related, as ajax starts a new connection each time.
Following your comments, I edit this answer:
I'm still at loss of what happens. However I see two possibilities. The first one is that you use a "flag" to validate forms or not. When you load the page, all forms flag are unset, and first submit check them all. Subsequent submits works correctly.
Another option is that the first time you submit a form, you dont event.preventDefault() on the submit click, but it's still a loosy explanation.
I would love to see how you call the $.post(...) function (how the submit button is binded, or how $().submit() is called).
Related
I'm developing a form with Symfony2 : several text inputs and one file input (for one picture). I have defined some asserts (maxLength, minLength...) in my entity in order to check the form (isValid).
My problem is : if the user puts bad data in text input (text too long or too short...), he still can submit the form, and error and printed but the user have to re-choose his picture.
As I think it's impossible to keep the picture in the form after bad validation, I should maybe check the form in client side (javascript), before submit.
So, is there an automatic way to do this (to forbidden submit until data are correct)? Can we get the assert minLength, maxLength value in twig ?
Thank you !
Ben.
You can use js validation before submitting the data, using some js form validation tools, but this way you need the replicate the validation logic from the server, so if validation rules changes, you need to modify on both server and client side. I recommend this method to reduce the traffic between client-server.
If you don't want this, use ajax form submitting (example here). You still validate the form using symfony, but the page won't refresh, so you won't lose the attached file. But this generates additional traffic to server, and you also need to implement error displaying using javascript.
Im looking for a way to add a new row and keep the form data together with the Save button enabled, to have the chance to resend the same data already sent.
What im trying to achieve is to facilitate the submission of similar-but-not-equal rows. So, for example, if a merchant receives an order all of the same X product, but with slightly differences, he can keep the common fields after saving a product and only change the different properties to submit the next one, and so on.
Then the server will throw an error if exactly the same data is sent more than once.
As per our discussion I would refer to the following as an example of adding a custom button to the Add form:
How to add custom buttons to JqGrid add/edit forms?
as for saving the information you can use the the documentation as an example, I think the beforeSubmit event would work for saving the field data
In jqGrid 4.4.4, file jquery.jqGrid.min.js:
At line 279, after 'beforeSubmit' takes place, you will find the following statement: if(k[0]&&!b[d.p.id].processing), the second part of the test means something like 'if request is not being processed', then after the 'processing' variable is set to true, the request to the server is performed.
What prevents to resend data is that the processing variable is never set back to false 'afterSubmit' for example.
So, my solution was to do exactly that: b[d.p.id].processing=false; at the end of the if block performing the action, this is done on line 287, col 55.
This way i can resend slightly different 'products' and just let the server to manage errors.
I suppose it could be a bug in the library to not 'close' the processing state by setting back the variable to false.
The specific case I've got in mind is as follows: an AjaxFormComponentUpdatingBehavior("onchange") is added to a TextField in a form. The behavior verifies the text for certain conditions (either the model object or the form component model, doesn't matter), based on which it might display a message (or hide it, if it has already been shown).
The problem is, there are also validators added to the TextField. One of the possible (and likely) scenarios consists of the user typing in, first, a value that causes the message to be displayed by the AJAX request. If, then, he/she types in a value that doesn't pass validation, the message should disappear, but it does not.
Apparently, either the onUpdate() method for the AJAX behavior is not called at all, or I am failing in my attempts to insert a check for non-validated entries (I have tried to test for both null values and empty strings, to no avail; I have no idea what exactly Wicket's validators do to models when data is invalid).
I am wondering if someone who actually understands validators (or AJAX, actually) has any ideas on where the problem could be.
I can post edit and post code if someone tells me this is not a general issue tying validators and AJAX, but most likely a programming mistake. I still believe the former and thus I'll refrain from posting code sections, in order to keep the discussion on an API/theoretical frame.
Thanks.
When using an AjaxFormComponentUpdatingBehavior, if any of the IValidators fail their validation, onError() will be called instead of onUpdate(). Wicket will effectively prevent invalid user input from reaching the IModels in your components, so the component's ModelObject will not be changed at all. The invalid input will probably remain available by means of getInput()/getConvertedInput() (not sure if it will in an AJAX scenario, it sure is in a traditional form submission).
However, take into account that IFormValidators are not executed when using this mechanism. If you've got any, you might be interested in overriding getUpdateModel() so that AjaxFormComponentUpdatingBehavior will not bring maybe-invalid user input into your IModels, and set modelobjects manually when you're certain user input is valid.
Regarding your specific case, you could perform all the required logic in onError() (or rely on Models that will grab data from somewhere else), and just add the components that need refreshing to the AjaxRequestTarget. This is probably what's missing in your scenario.
Is there an existing library that would do this?
I want to be able to have code on the client side where the user chooses something, it makes a call to the server, and the server sends back "for this option, you need a have a text field called foo and a select field called bar with the following options, this one is selected, etc", and then the client side builds the next part of the form from that information. Or if they choose a different option, a different set of fields and values is returned from the server and populated on the screen. Also it might cascade so after the first selection we need a select field with some options, and then depending what they select on that select field the next field might be another select field or it might be a text input field.
Has anybody done anything like that? Is my best choice to have the AJAX call return some html that I just stuff into a div, or can I do it field by field and value by value?
If it matters, the back end is going to be written in Perl/MASON, and the front end will be using Javascript/JQuery/JQuery-UI.
I would use jquery and submit AJAX calls to whatever backend system you choose. Have this backend system compute the necessary changes and return the info as JSON. Let JQuery parse it for you and append the necessary form elements. However, it seems like under alot of use cases these decisions could be made on the client side without even talking to the server just as we pre validate form input before allowing posting to the server. I don't, however, have your requirements in front of me so I am sure there is a reason you want to get the info back from the server.
P.S. please do not return pure html from the back end to the client....ever.
We have an existing Django form that accepts GET requests to allow users to bookmark their resulting query parameters. The form contains many fields, most of which are required. The form uses semi-standard boilerplate for handling the request, substituting GET for POST:
if request.method == 'GET':
form = myForm(request.GET)
if form.isValid()
# Gather fields together into query.
else
form = myForm()
The problem is that the first time the form is loaded, there's nothing in the GET request to populate the required fields with, so most of the form lights up with 'missing field' errors.
Setting initial values doesn't work; apparently, the non-existent values in the GET request override them.
How can we avoid this? I'm pretty certain we're simply not processing things correctly, but I can't find an example of a form that handles GET requests. We want errors to show up if the user hits the "Submit" button while fields are blank or otherwise invalid, but don't want these errors showing up when the form is initially displayed.
The positional argument to the forms.Form subclass informs Django that you intend to process a form rather than just display a blank/default form. Your if request.method == 'GET' isn't making the distinction that you want because regular old web requests by typing a URL in a web browser or clicking a link are also GET requests, so request.method is equal to GET either way.
You need some differentiating mechanism such that you can tell the difference between a form display and a form process.
Ideas:
If your processing is done via. AJAX, you could use if request.is_ajax() as your conditional.
Alternatively, you could include a GET token that signifies that the request is processing. Under this example, first you'd need something in your form:
<input type="hidden" name="action" value="process_form" />
And then you can look for that value in your view:
if 'action' in request.GET and request.GET['action'] == 'process_form':
form = myForm(request.GET)
if form.is_valid():
# form processing code
else:
form = myForm()
I'll also give you the standard, boilerplate point that it's generally preferable not to use GET for form processing if you can help it (precisely because you run into difficulties like this since you're using an anomalous pattern), but if you have a use case where you really need it, then you really need it. You know your needs better than I do. :-)
If your clean page load doesn't have any non form GET params, you can differentiate between a clean page load and a form submit in your view. Instead of the usual
form = YourForm()
if request.POST:
you can do
if request.GET.items():
form = YourForm(request.GET)
if form.is_valid():
...
else:
form = YourForm()
If your clean page load could have other params (eg email link tracking params) you'll need to use the QueryDict methods to test if any of your form params are in the request.
request.GET is and empty dictionary when you first load a clean form. Once you have submitted the form, request.GET will be populated with your fields data, even if the fields contain only empty data.
My first question is this, which I posted as comment:
Why not just use request.POST and the standard way of processing form data?
After considering everything here, perhaps what you are looking for is a way of processing data in your query string to populate a form. You can do that without using request.GET as your form.data.
In my own views, I take advantage of a utility function I created to add initial data to the form from request.GET, but I am not going to share that function here. Here's the signature, though. initial_dict is typically request.GET. model_forms is either a single ModelForm or a list of ModelForm.
def process_initial_data(model_forms, initial_dict):
Nevertheless, I am able to process the form through the standard practice of using request.POST when the form is POSTed. And I don't have to pass around all kinds of information in the URL query string or modify it with JavaScript as the user enters information.