Apologies I can't post any code at this time cos I'm away from my desk, but I will try and explain my problem as clearly as possible in the hope someone can help!
I have a long form that submits to a method in a controller. To make things more user friendly I have split the form into sections. Each section has a hidden field that acts as a flag. The method that the form submits to is made up of conditionals that test for these flags. If a flag is found then the next part of the form can be displayed. I can also gather the data in sections rather than processing the whole lot in one go.
My problem arises when I try to use the set_select method to set a default value for select menus. The method is part of the CI system form_validation library. If an optional third parameter is passed to the method as true it should set that value as the default. However, this only works if the form_validation hasn't previously been run. This makes perfect sense because it is assumed that a default would only be needed the first time a form is seen ie. before any submission and therefore before any post data.
Ofcourse this isn't how it is in my situation. If i simply empty the post array then that defeats the point of the set_select function because any select menus higher up the form would no longer be able to be set to their last value.
Can anyone think of a good solution? I know this would be much easier with AJAX, but I want to make sure that everyone gets the best possible experience whether or not they decide to use JavaScript.
Personally, I would use AJAX to break the form up into your 3 sections, submitting by AJAX each time.
THEN for non-javascript users (the few there are), I would just display the form in its entirety, and process normally.
breaking the form up sounds like a "feature" not a function. Meaning that javascript users will be able to take advantage of the "feature" of breaking the form up, while non-javascript users will still be able to effortlessly accomplish the "function" of submitting the information.
what about doing it like this:
split it into 3 different form in 3 different method
on each method, set switch using session to check what form currently is
add form validation on each of these form and check accordingly
if those 3 form is OK then you can proceed to whatever process you want
if some form is failed, you load back the previously failed form
I've decided that using set_select is probably not the best option for me, so I've added some code into my view files which will do this for each individual case rather than trying to use a generic function.
Not ideal, but is working!
Related
is it ok to simply point all forms action to a single url and seprate them with a input_hidden for example form_id?
for example we create a url like: /process
and point all forms on that url , and there we seprate forms by a hidden counter
Actually there is no harm in doing that, but if you make different files than it will make a lot easier for anyone to understand.Making different files and calling them will make your code look cleaner.
No, it's not wise. Separate unrelated functionality to different files, and call those, it makes it easier to see where is what. Lots of small files > One huge file.
A few is typically OK, but only if you have lots of different forms on the same page and you aren't using Ajax to submit them. The way you keep it tidy is by giving the forms names, and namespacing each field with that name so you know which form has been submitted.
This is often necessary in this case to reduce the work needed to load form validation errors, whereas you would normally need to keep the errors in the session to reload after a redirect from the processing page.
Example:
-> contact.php
-> Submit to contact.php
-> If errors, re-render the form without redirect on contact.php
-> Else, process the form, then redirect.
In the event of errors, the second showing of the form would be part of the POST request, meaning you still have easy access to the previously submitted data.
If it was valid, you no longer need the posted data as you have already persisted it elsewhere.
This is highly contextual however. It is not a reason to use a single script to process "all" of your forms. Only the ones on the active page.
Generally no.
But there are use cases where it's desirable to do it, at least for some forms. But these forms must implement the same interface, their behaviour is the same.
For example I have one use case where buttons are placed on page, each loads a different form in a modal. Each is posted to the same controller, but all the controller needs to know is that it calls validate(), save(), and render() methods on the form.
I'm sure there are other cases, but your general stand should be "no", unles you have a good reason for it.
How can I remember checkboxes in Smarty when I create them dynamically?
If a user fills in a webform and he submits the page and there are errors they are always gone. (The ones that are checked)
I should have a way to store them.
Currently I set them the following way (in a {foreach}:
{html_checkboxes values=$event#key output=$event#key selected=$event id=$event#value name=$event checked="1"}
Thanks a lot for helping me out.
That question isn't Smarty-specific in my eyes. It can be done in more than one way. Two examples to demonstrate how to cope with this:
Use a JScript libraries form validator to validate the data before submitting. An example if you're using JQuery can be found here: http://jqueryvalidation.org/ (there are many more out there for nearly every JScript library, I just chose JQuery as an example because its current widely acceptance).
Don't transfer the form data to your server using the form submit, use some AJAX to submit them and wait for a response from your server. If the response is "oops, error", show the user the field which contains the error.
Again, there's more than those ways of doing it, but - depending on what the form does - those two are usually the fastest and easiest to implement.
I'm developing on a really bad code-base that is loosely formed around Zend Framework (PHP) so ORMs can't be used and neither can any other framework. I have attempted using Zend_Form but I found the documentation too sparse (I have developed small forms with Zend_Form but nothing of this size).
I need to create a long form (6 pages long). The user will be able to switch between each step as they please with no validation at all until they attempt to submit the form (not a good idea in my opinion but that's what the spec says).
At the end of the process, the form will be validated and then the data will be split into a number of different tables in the database. Oh and just to make things fun: there are three versions of this form, all with slight alterations on fields, nothing major. They all store the data in the same tables.
So, what's the best way to go about doing this? How should I structure it and what would you do if you had to build such a form? I'm writing it in PHP but would like to hear responses from programmers of other languages too. Also if there are any libraries or tools for building such forms, I'd like to hear those as well.
Never done this using ZF, never done such form with validations only when submitting last step, never done a multistep form where user can jump from step to step as they want (I mean jumping from 1st step to 4th, e.g.).
What I did was a 5 step form (where there could be more 3 substeps within 4th step). User can follow the steps one step at a time or go back one step at a time. Each step is submitted and validated - until it is valid user cannot jump to the next step but he still can go back - the values inserted are stored within session. I have created a model (structured class containing other subclasses) so after each step is submitted and valid the data is set into this model that is stored within session.
If You need a really big form where user can jump through steps as he wants, I would consider two ways:
Create just one form with steps visually divided into a tabs - each tab will contain only related fields and only the last tab will contain the submit button. Other tabs will contain a "next" button that will only open the next tab. There could be a possible problem with the number of fields - You can send only limited amount of fields through POST and even more limited amount of fields through GET (sorry, don't know the numbers). Then after submit is invoked a validation takes place and then You can just fill the DB tables...
Create a form for each step. Create a model that will store the data. Each step will submit and only store the data into that model (except the last step - this will also invoke validation of inserted data) - while model will be saved within session. When validation fails You will redirect user to the first invalid step, display a message at what steps the data is invalid (also visually make that steps invalid). If the validation is OK, take the model and fill the DB tables...
Cannot tell You how difficult will both ways be as I didn't do such thing using ZF... And hope never will have to.
I would also consider talking to client and explain that validation only at the very last step is kinda foolish and user un-friendly...
I'll split it up in a few sections:
form handling
You have two main choices here (no strong feelings one way or another):
Create the whole form in one page and use JavaScript (or a library such as jQuery) to move between the form sections; optionally you could do some client-side validation here as well.
Create one form per page and let PHP handle the carry-over, either by using sessions or keeping everything inside the form by using hidden input fields (I personally prefer sessions).
Handling the slight variations could be done by simply passing down the version in the first page and have your form change accordingly by adopting strategy pattern.
final submission
For validation you can use PHP's filter extension (shipped by default btw); it's pretty decent and extensible.
If validation fails, it's probably best to gather all errors and show them to the user (possibly with hyperlinks to jump to their respective sections) rather than only showing the first error; at each section you might mention the errors again for ease of use (users hate to jump back and forth).
Storing the whole form in your database is not much different in terms of variations than showing the form itself. Use strategy pattern again here.
Hope this covers most of it, let me know if you think I can improve.
You are restricted by being unable to use an ORM or framework so you could take a look at serialization and storing objects as session objects.
Create a "Form" class with some properties specific to your forms and set these values after each form submission.
Thanks everybody. (For some reason I couldn't up vote answers, so everyone wins today :] thanks again!)
Complete php and javascript novice here, apologize up front for anything half-witted.
I have a portion of a user's profile in which I'd like the user to be able to add additional items of the same thing, with slightly different conditions.
For example, let's say it's favorite books. A fieldset contains some checkboxes for genre and an input text box for the title of a book. After the user checks a genre and fills in a title, they can add the book to their set of favorite books and then have the option to add another. When done adding books, they move on to the next fieldset, complete the form and submit.
How is this done? And more-importantly, is it possible without javascript?
Without JS, I understand this probably entails a lot of reloading of the page to add the items, regardless I'm more confused about how the $_POST data is handled, both before and after the submit.
Sorry for such an open ended question, really just looking for someone to point me in the right direction, as searching for this topic proved to be a bit difficult.
Thanks.
Some Clarification
I'm trying to develop an application that is as independent of javascript as possible. In that sense, I don't know if it's possible to add the new items with PHP alone. My sense is the fieldset in question could have it's own submit button, the action of which POSTS to the page itself (no DB interaction, etc), and variables like $book_genre1, $book_title1 are populated in the page. Then, the "official" submit is sent later, which actually adds the POST data, which contains the books array, to the DB. But I don't know if that is a safe procedure or good logic to begin with.
In reply to the above answer, if that is exactly what you need since I seem to have a different idea.
You simply store each addition in an array stored inside a session variable, and in each page load, parse the data into readable html.
$_SESSION['form'][] = serialized_form_data;
On each load,
foreach ($_SESSION['form'] as $form) {
unserialize_data_and_create_html();
}
add_new_form_element();
I'm assuming you want to show the user already filled forms so he can deal with them as he wishes.
This is a better implementation than what I thought of earlier. I wanted to implement a db version.
Sorry for the delay. I can't comment since I'm mobile (js issues) so I decided to edit instead.
You can simply use the $_SESSION['form'] for your inserts.
A simple foreach will work as well. However, remember to sanitize each value properly before inserting it. That's the key.
If you use prepared statements with binding, you have the advantage of clean input as well as better database performance.
What you're really asking is how to persist information between POSTs of the same form. The most common and effective way of doing so is to just use the inputs on the form. If you have information that shouldn't be displayed then use hidden input elements for them.
Note that storing information in the form like this is not considered secure since it can be manipulated and/or forged, so the next option is to store it in the session; since it is server-side only the cookie/session ID needs to be protected. The values can then be retrieved from the session in PHP after the POST has occurred.
Before you submit a form...there is no data to handle. Once a form is submitted data then is sent to the server in the form of an array.
(From php.net/manual/en/reserved.variables.post.php):
$_POST = "An associative array of variables passed to the current script via the HTTP POST method."
So a user submits some data to the server. Now that data is available to your scripts for use: Populate a database, validate the values before doing "x", write HTML to the client, etc.
I like where #frosty is going with his approach. It does potentially send multiple requests to the server, but it's also a very straight forward approach. A completely server-side solution.
JavaScript or the jQuery Library would allow you to accomplish a similar result, and post to the server just once - by simply hiding/showing populated fields, writing additional fields to the form dynamically (eg: After completing "book #1" the user can click "Add another" and JS writes an identical set of form fields all referencing book #2). Obviously, this approach will get more involved than a straight PHP approach. And you'll need a backup plan if you want to allow users with JS disabled to participate.
I would suggest you use javascript to handle the user adding multiple items. Check out jQuery (http://www.jquery.com) which is a fantastic javascript library that will help you do lots of great dynamic things.
Then once you have all of the information from the user, just once it all at once to your php and save it. For information about to access and use $_POST or $_REQUEST, you'll need to check out some PHP tutorials or pick up a book. That's fairly basic PHP stuff and too large a topic for this thread.
I've got a website that has a form that the user can type in. I want it to be the replacement for a 3rd party website (Autotask) form with the same fields. Normally I'd just have the action in my form go to where the 3rd party's form points and then have all the same id/name values for my own fields, but there are several problems with this:
Autotask's forms aren't just simple muli-field forms. They import at least 15 Javascripts that make something magic and unidentifiable happen, and they are incredibly difficult to read and understand. So that causes two problems, one that the form takes a very long time to load (5 seconds or so for 4 fields), and two is that if Autotask changes anything at all I'll need to redo the whole form (very tedious and crapshoot-y, and I already have needed to do it twice).
In order to make the load time more transparent, I put my copy of the Autotask form within an iFrame. That way the rest of the website can load separately from the expensive number of scripts I've got to include with Autotask's logon process.
Ideally what I want to be able to do is to just have those 4 fields on my site with whatever name and configuration I want, then send that POST data to my own PHP script, which will automatically (and transparently) submit that data directly through Autotask's forms in the proper fields. If I need to make the id/name match, that's okay. I can use HTML, Javascript, and PHP on this site.
EDIT:
Autotask has built-in GET handlers for their logins. You'll notice that you have a client ID at the login (it will be the "ci" variable in the URL). If you send a GET request with the client ID there and variables for "username" and "password," then it Autotask's login page will immediately forward you to the client page, given a successful login.
I think a lot of people would advise against this in general, as you're kind of hacking the functionality of someone else's app. In this case I only advise against it because they (Autotask) have an outward facing API already. http://www.autotask.com/press/news_and_press_releases/071006.htm I think that you'd be better off just utilizing it and developing something that functions pretty well within the constraints of their system.
one really round-about way of doing it is have your page load a form with some generic id/names. have a php script that scrapes their page for the correct id/names, and the ajax them into your forms.
That way you avoid having the load time of iframing their content in, or scraping their page on your initial page load and they change the id/names you'll always have it up to date.
I could write up a big post that explains on this, but really I think this is a perfect time to let someone else's words do the work.
Autotask's forms aren't just simple muli-field forms. They import at least 15 Javascripts that make something magic and unidentifiable happen, and they are incredibly difficult to read and understand.
Sounds like anti-spam measures to me? If so, then they will probably change over time.
So: follow NateDSaint's advice!
As a follow-up, it turns out that with Autotask they have GET handlers so you can just send information via GET. Problem solved.