everyone!
At first, I made a single form with large amount of elements: text fields, text areas and so on. When I had got the form ready, I understood that it is not so user-friendly to have such a large form to be filled-in in a row. I don't want to use the "step" system (step 1 -> step 2 -> ... -> step n), because I want for the end-user to be able to have this form filled in any order (+ User would be able to see beforehead what forms he would need to fill), so I divided the form into the several tabs.
The idea is following: once user has filled the form in some tab, he hits the "Save" button and proceeds to the next one (in arbitrary order of his choice).
The thing I wanted to know - what would be the best approach to store the intermediate data ? Should I have some hidden input for each of the tab forms with tab-id to be passed to the model, so that at each 'step' only tab relevant data was validated and stored in DB. Or, maybe, I should have a session[:object] that would contain the current object and at the very end I would store it in DB and erase from the session.
Can this idea be realised ?
Thanks in advance! :)
there's a gem called wicked, it allows you create wizards in a very simple way, check it out
I'm not a ruby ninja, but in other languages (like php) we usually use sessions to do this. Why not to do this on rails?
Also you can consider creating a table for "temporary storage rows" in addition of using sessions, so every time you change the page you could save the data to that table and, at the end, save them all to your main tables.
This is useful if you usually loose your session... you can related the temporary storage rows with the user and if he looses the session, you can restore his uncompleted forms from your database.
You could simply go the Railscasts 217 - Multistep form approach, which works fine.
However, this may not suit you as you may only store the data AFTER you have everything collected, and not step by step.
Another solution - as you mentioned - would be using e.g. jQuery tabs to create your form steps and building a little validation via AJAX / backbone.js before storing the actual record with all its data.
Related
I have a form which allows a user to create an unlimited number of fields. If this forms fails validation I want the user to return to this page with the form populated with their previous input values - i.e. I want these fields to persist.
With a normal form I could do this with {{ old 'title' }}, however, these additional fields are being generated through JavaScript and so I cannot add this PHP snippet. What is the best way for me to retrieve these previous input values?
3 ways to do this, cache, sessions and cookies.
cache and sessions are server side which is much better for security, however it will take extra time and effort for setting up, but if the data is not sensible and can be passed within cookies, better to the cookies.
The best thing about cookies for your current situation is: you can set it up directly from your front end JS code.
How can multiple users work on same project / same form at a time?
Something like a repository.
In our project there are multiple sections & work is divided on these sections. We tried to save the same form from different systems but form saves only recent data (recently saved form).
Is there a method to club or merge code?
At this point, Orbeon Forms and Form Runner don't support multiple users editing exactly the same form data. Of course, multiple users can at the same time edit multiple "instances" (form data) of the same "form" (form definition).
So, I would, if possible in your case, restructure the form, maybe splitting it into multiple forms, to avoid that situation.
After researching I found an alternative.
We are team of 4 & we spitted our work based on the Sections. Make sure that each developer should have Unique Section.
Go through the Orbeon Source & Collapse XML Tags shown in Image.
after doing this your code should look like above.
Point #1: Copy your other sections here
Point #2: Copy your Binding Code.
Point #3: Copy your Services & Actions
Point #4: Copy your form sections.
This is how we merged 4 different application.
Few things to be checked
Repeated Grid
Actions
Services
All the best! Happy Coding :)
Using Git, each user can work on their own copy of a form, regularly committing changes and pushing to the main branch. Occasionally there will be merge conflicts, but if each user only updates a specific section then conflicts should be get to a minimum and not too complex.
Orbeon persistence can also be configured so that form code can be saved directly to text files.
I need to build an application wherein the admin must be able to define forms for data entry. The data to be entered is unknown to me. But the system will need to be able to support all the possible form fields (minus hidden fields, I suppose). So text areas, text fields, radios (with ability to specify what the options are), checkboxes, etc. Also, it needs to be able to support line item entries (similar to EE’s Matrix plugin).
Obviously, I don’t want to try to build this from the ground up. Are there any libraries I can use in CI to make life easier for me?
If none exist, what are some database design patterns I should consider for such a problem?
The best database-design for this is the Entity-Attribute-Value Model. For use with a FORM, essentially your form is the ENTITY, the Attribute will have a type (used for deciding how input will be captured, and data interpreted). Make sure that you index properly.
Remember that you'll only need to data to change the form, don't read from this model everytime you need to show a form. Store a flat file (.json is handy) of the finished form and read that when displaying the form.
What is the standard convention to save data in textboxes and other form data to be loaded the next time the program is opened?
I personally do not know of any convention, however you could look into the following methods:
Using the registry: http://radio-weblogs.com/0111551/stories/2002/10/14/registryRwInC.html
Using profile strings: http://dotnet-snippets.com/dns/c-read-and-write-ini-files-SID574.aspx
Not sure of the standard convention, or if there is one, but saving to a text file would be a simple-to-implement solution.
It depends on the kind of data that you are trying to save. If this is a relatively small amount of user specific data associated with their user preferences, then user settings are the way to go.
If this is large amount of application data (for example like an entire address book), then you are probably better off writing to an external file or database in whatever format suits your needs.
You should be looking at Windows Forms data binding - that is the best way to save data from and reload data into a Windows Forms application. Once you have set up your form controls for data binding, you have a choice of where to store the data, as explained here.
I've been having a look at several MVC frameworks (like rails, merb, cakephp, codeignitier, and similars...)
All the samples I've seen are basically plain and simple CRUD pages, carrying all the infr needed in the querystring and the posted field values.
I've got a couple of apps made with some sort of framework built with classic asp.
This framework handles some CRUD stuff a little more complex than the examples I found.
Something like master-detail, filtering by example, paging, sorting and similars.
I have a controller class that it's just a finite state machine, that goes thru diferent states (like new, browse, filter, show, etc.), then performs the appropiate action depending on the event raised and finally retrieves the neede info to the calling page.
To achieve this I have several hidden inputs to keep the state of the web page (like current id, filter criterias, order criterias, previous state, previous event, well, you get the idea)
What do you think would be the finnest approach to achieve this kind of funcionality?
hidden inputs built in the view and used from the controller??? (I guess that would be the equivalent of what I'm doing right now in classi asp)
--
(added in response to tvanfosson)
basically, my question refers to the third category, the context-dependent setting (in respect to the other two categories I agree with you) the info I was storing in hidden fields to store them on the querystring, I guess that when you click on the "next page" you include everything you need to save in the querystring, right? so that piece of query string gets appended in each and every link that performns some kind of action...
I'm not sure, what are the advantages and disadvantages of using the querystring instead of hidden inputs???
I use different strategies depending on the character of the actual data. Things that are preferences, like default page size, I keep in a Preferences object (table) that is associated with the current logged in user and retrieve from there when needed.
Persistent settings associated with the current logon, like filter settings for a page, are stored in the user's session. Generally these are things that if a user sets them in the current session they should remain sticky. I think filter settings and visibility are like this. If I filter a list, navigate away from it to drill down into a particular item, then come back to the list, I want my filter settings to be reapplied -- so I make it part of the session.
Context-dependent settings -- like the current sort column or page number, are controlled using query parameters. Paging and sort controls (links) are built with the appropriate query parameters to "do the right thing" when clicked and pass any necessary query parameters to maintain or update the current context of the control. Using the query parameters allows you to use an HTTP GET, which is bookmarkable, rather than a POST. Using hidden form parameters makes it much harder for the user to save or enter a URL that takes them directly where they want to go. This is probably more useful for sorting than it is for paging, but the principle applies equally.