[LRUG] Multi page form design gem for Rails?

[Rob Anderson]

I feel it's best to avoid the session for this sort of thing if possible.

We use a form object to mediate between the params and the Rails model
itself.  The form object is responsible for performing the partial
validation at each step of the form process.  The Rails model validates the
whole thing when the data is complete.  The form object can delegate
individual field validation tasks to the Rails model to keep DRY, as
necessary.

State is handled by rendering the previous step's form fields as hidden
fields in step 2.  So all state is held by the browser.  This can mean that
a multi-step form is implemented in a single Rails view + action, although
it doesn't have to be.

Rob

On 14 February 2018 at 12:12, Duncan Stuart <dgmstuart at gmail.com> wrote:

> I don’t know of a gem - it’s a recurring problem, and a fiddly one since
> the concept of state is different from standard Rails CRUD.
>
> We’ve used an approach of storing a hash of answers in the session:
> https://github.com/LBHackney-IT/maintain-my-home/blob/develop/app/models/
> selected_answer_store.rb, and elsewhere configuring the branching
> structure of a set of similar multiple-choice questions in YAML:
> https://github.com/LBHackney-IT/maintain-my-home/blob/develop/app/models/
> question_set.rb
>
> This approach was borrowed from some gov.uk site (I forget which but you
> can find it in the commit history). Iirc that project additionaly had an
> object responsible for deciding what the next question should be, based on
> the previous answers.
>
> Good luck!
>
> Duncan Stuart
>
> On Wed, 14 Feb 2018 at 09:17 Stuart Harrison <Stuart Harrison
> <Stuart+Harrison+%3Cpezholio at gmail.com%3E>> wrote:
>
>> Hey LRUG
>>
>> I’m about to embark on a project which has a couple of multi page
>> branched forms, and, as it’s a common problem, I’m wondering if something
>> exists that allows me to design a form either via a DSL or YAML, rather
>> than having to reinvent the wheel each time. I used Surveyor
>> <https://github.com/NUBIC/surveyor> a few years ago, which kinda worked
>> for me, but it did cause some pretty major headaches too, and now seems to
>> be largely abandoned. I like the look of Wicked
>> <https://github.com/schneems/wicked>, which gets me part of the way
>> there, but I don’t get that DSL-y way of designing the form and not having
>> to worry about building the individual form parts in a view. Is there
>> anything out there that supports this? Or are there any patterns that
>> anyone else uses that would help this?
>>
>> Hope this makes sense
>>
>> Cheers
>>
>> Stu
>>
>>
>
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
>


-- 


Rob Anderson CTO

Payment Card Solutions (UK) Ltd

3A The Plough Brewery, 516 Wandsworth Road, London SW8 3JX

Office: +44 (0) 20 3137 3422 | Mob: +44 (0) 7767 623794

[image: PCS Email Logo] <http://www.paymentcardsolutions.co.uk>

[image: Facebook]
<http://www.facebook.com/pages/Bread-for-Business-Prepaid-Card/1453603974852717>
 [image: Twitter] <http://twitter.com/breadcards> [image: Linkedin]
<http://www.linkedin.com/company/payment-card-solutions-uk-ltd?trk=cp_followed_name_payment-card-solutions-uk-ltd>

This e-mail message may contain confidential or legally privileged
information and is intended only for the use of the intended recipient(s).
Any unauthorized disclosure, dissemination, distribution, copying or the
taking of any action in reliance on the information herein is prohibited.
E-mails are not secure and cannot be guaranteed to be error free as they
can be intercepted, amended, or contain viruses. Anyone who communicates
with us by e-mail is deemed to have accepted these risks. Payment Card
Solutions (UK) Ltd is not responsible for errors or omissions in this
message and denies any responsibility for any damage arising from the use
of e-mail. Any opinion and other statement contained in this message and
any attachment are solely those of the author and do not necessarily
represent those of the company.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20180214/9d0ed9a1/attachment-0004.html>