[LRUG] Multi page form design gem for Rails?

Duncan Stuart dgmstuart at gmail.com
Wed Feb 14 04:44:25 PST 2018


To clarify my poor explanation: the fact that we used the session as an answer store is incidental - it was just the quickest thing which worked. It would be trivial to change the answer store class to save to some other store (eg redis) and just store a key in the session.

Duncan Stuart

On Wed, 14 Feb 2018 at 12:25 Rob Anderson < Rob Anderson ( Rob Anderson <rob.anderson at paymentcardsolutions.co.uk> ) > wrote:

> 
> 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
> 
> 
> _______________________________________________
> 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
> 
> 
> 
> 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
>> (
>> 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 (
>> https://github.com/LBHackney-IT/maintain-my-home/blob/develop/app/models/question_set.rb
>> )
>> 
>> 
>> This approach was borrowed from some gov.uk ( http://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 (
> http://lists.lrug.org/pipermail/chat-lrug.org )
> Manage your subscription: http://lists.lrug.org/options. cgi/chat-lrug.org
> ( http://lists.lrug.org/options.cgi/chat-lrug.org )
> List info: http://lists.lrug.org/ listinfo.cgi/chat-lrug.org (
> 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 

PCS Email Logo ( http://www.paymentcardsolutions.co.uk )

Facebook ( http://www.facebook.com/pages/Bread-for-Business-Prepaid-Card/1453603974852717 ) Twitter ( http://twitter.com/breadcards ) 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/a89b1a34/attachment-0004.html>


More information about the Chat mailing list