I use symfony admin generator to create a very long form.
This form is so long, that users hesitate to start completing.
I need to make small steps in fill in :
example: First form: step 1 : organization
Second form: step 2: name and occupation
Third form: step 3: solution
....
Tenth form step 10: memo
Every step has a submit button to save another portion/part of the form.
Do you have any ideas how to realize that ?
Thank you
I would create 10 different forms (and actions in the controller), and when each part is completed (and validated) redirect to the next part of the form's controller action.
Related
I am a research student working on an access database where I have created a continuous form that is to be used in a sort of scrolling electronic health record format. The header includes information about the patient and the continuous form aspect is a series of patient visits. In the header, I have a few subforms, which populate based on linking on the patient_ID number which is posted in the header (generated by vba macro such that previously reviewed patients aren't revisited). These subforms seem to significantly lag such that they the results from the previous patient stick around going into the next one. The subforms contain user-selected pertinent data. Each form has its own table. They are linked primarily based on patient_ID.
I have tried:
macro on the header detail: on click, refresh. - seems to work, but not very elegant/intuitive
macro on the main form - same as above but on load, click, got focus, lost focus, open, activate -- none of them seem to do anything.
forced requery via vba (see below) on opening/etc of the form. Neither way has worked. Tried to run these on opening the header form.
Public Function RequeryMain()
Dim frmMain As Form
Set frm = Forms("FRM_continuous_reports_patient")
frm.Requery
End Function
Public Function RequeryHeader()
Dim frmHeader As SubForm
Set frmHeader = Forms("FRM_continuous_reports_patient").FRM_continuous_header_working
frmHeader.Requery
End Function
In the end, it is frustrating for users to have to click to clear the form for new entries. It works otherwise.
The end goal is for the form to open and have all the subforms load based on the newest patient_ID. This would likely have to involve a staggered load: (1) VBA script selects the next patient based on certain characteristics and passes the patient_ID to the main form; (2) load main continuous form based on patient_ID submitted to it; (3) load the header subforms and any pertinent data within (although should be blank for the first time these are seen); (4) on completion, back to (1).
From what I understand, this is already how it is working, however the subforms are loading too quickly? How can I fix this?
Hopefully someone can help explain how to remedy this/correct any misunderstandings I have about the mechanics of forms.
I know this will sound odd, but subforms actually load before parent form. Lag in subform display is not something I have encountered. Code should not be needed and likely will not correct. Must be something about the form/subform design, maybe their RecordSource. Would have to examine db to determine.
It is not necessary to create form objects in VBA just to requery. Is code behind the main form? Me.Requery will be enough for the main form. I always give subform container a name different from the object it holds, like ctrPatient. Then just Me.ctrPatient.Requery.
Why not put subforms in Detail section?
To answer your questions, and provide a condensed version of the logic referenced at: https://accessexperts.com/blog/2014/01/07/delay-loading-subforms-in-access/
is to:
In design view, set your subform SourceObject to "" (and save your form)
When you are ready to show the subform, just execute: Me..SourceObject = ""
When you are ready to navigate to the NEXT patient, clear the subform link: Me..SourceObject = ""
Now that should solve the issue of out of sync data between the main and sub.
You don't need to use the CASE statements, but they operate as if you had a bunch of "If" / "ElseIf" all nestled together -- except the CASE makes it easier to follow. It basically gets a value from a variable (i.e. Select Case MyVariable); then checks to see if it equals what you want (Case 1, Case 2, etc.), and if so, does whatever you code.
in Visual Foxpro, I need to work with two forms concurrently. When I invoke the second form, from the first form, I need the second form to stay open, when I do some work on the original form. Presently the second form closes immediately, if I should try to click on any element in the first form.
The way I call the second form is this:
DO FORM imagez WITH ThisForm.pf1.page4.image7, this_form
READ EVENTS
Any ideas would be appreciated.
The form properties of both forms are:
DeskTop = .T.
ShowWindow = 2 - As Top-Level-Form
My above solution works. I had a ThisForm.Release() command installed in the LostFocus event...
My apologies to all...
Dennis
I am building a Booking model in Rails 3.2.3 where a user steps through several form-screens of choices. If the form exactly mirrored the underlying model I know I could use a gem (e.g. Wicked gem) to build a multi-step form. The issue I am having is that on one of the form-screens there are multiple options for the user and within each of those options there are multiple options coming from an external web-service. In other words, on step 2 of the multi-step process, the form presents the user with many options of Rates from our database and for each Rate we have multiple additional options from the web-service. So a user would need to choose one of the options from the web-service (radio buttons) and then make a selection of their Rate of choice. This is then repeated multiple times on this page (although the user can only choose one radio-button option from the web-service and one Rate).
Where I am unsure of best practice is that I can display the multiple options from the web-service as radio buttons but there is a Hash of values associated with each of those options and hence with each of those radio buttons.
So, the question is, should I be attempting to pass that Hash as a param to the next step of the form process or should I be making that into an object and passing that or something else entirely!
I know this is a long explanation but I feel it's a critical point in the design of this workflow and I want to get it right.
Many thanks in advance,
J.
EDIT
Thinking it through again, the initial problem is how to represent a series of radio buttons when each radio button represents many values as opposed to say an id (in this instance each radio button represents a hash of values from the external web-service). Should the hash be made into an object and this passed instead - something along those lines?
I figured this out. On inspecting the "hash" coming back from the external web-service, I noticed that date fields were not in quotes, e.g.
:departs=>Wed, 21 Aug 2013 10:40:00 +0000
whereas all the other fields were in quotes. This made me a little suspicious. So in the end I used to_json on the returned hash:
response_hash_from_webservice = data.to_json
In the form I then used:
JSON.parse(response_hash_from_webservice).each do |nested_item|
# Access elements like so
... nested_item['company_name'] etc ...
end
However I needed to post this nested_item through to a next step of the form (as a radio button) and it only worked by again using to_json.
<%= radio_button_tag 'nested_item', nested_item.to_json %>
I could then post this value or put it in the session and on the following form page use:
require 'json'
hash = JSON.parse session[:nested_item]
And then access the values as normal:
<%= nested_item['company_name'] %>
To add multiple steps before submit form. like:
Registration page:
Step 1 - Enter first, last name and email (validate on click of next button and show next step)
Step 2 - Enter Password and Confirm password and submit
Step 1 and step 2 are separate DIV's (Show/hide on Next Click)
You can give a try of this JS snippet:
var formToValidate = $('place the id of the form, that I want to validate');
var validator = new Validation(formToValidate);
if(validator.validate()) {
/* The logic, that you want to execute if you pass the validation. */
......
......
}
Good luck!
I have a three step form where each step posts to its own action. The action redirects to the next step. The data is stored in the session scope. I have a filter that prevents a user from accessing the form handlers through anything other than a post request.
There's nothing to stop someone from manually typing in the address of a step, however. To deal with this problem I set a currentStep variable in the session.
<!--- Some data is processed here --->
<cfset session.currentStep = "stepTwo">
And in step two I would check for a structkey:
<cfif NOT session.currentStep = "stepTwo">
<!--- redirect to #session.currentStep# --->
This approach works, but it has a major drawback: A user can not press the back button in the browser window, or edit any data he or she has already entered.
What are some the best practices to implementing a multistep form? Can I improve my process to incorporate back-button functionality?
Instead of using the session variable to only allow them to access the current step, allow them to access the current or previous steps. Sort of a "how far you can go" flag.
Now, add links to the previous steps, like a breadcrumb trail.
Finally, use a lookup in the persistent store (db, session, xml, bag of holding, etc.) for the data already entered for that form. Create a blank set of form data, overwrite it with anything found in the persistent store, then overwrite it with anything from the form scope itself. Something like:
populate = structNew(); // this is the data to populate your form with on load
populate.someValue = "";
structappend(populate, dataFromStorage);
structappend(populate, form); // from things submitted from the form scope, in case validation fails
<input type="text" name="someValue" value="#variables.populate.someValue">
Now, if someone hits the same form step twice, they will see (in order of precedence) the values they submitted, but which didn't pass validation, values from the persistent data store, and then an empty form.
You can stay using Session approach if you want.
To solve your major drawback, you can change your logic a bit.
At the last step, make sure data of all steps are found in the session. If not, redirect the user to the first unfilled step? Shouldn't be too hard.