[LRUG] Multi page form design gem for Rails?

Wed Feb 14 07:48:49 PST 2018

+1 for the form_object approach. It may seem long winded but I have a
separate form model, controller and views for each stage of the wizard. The
form_models just inherit from a base, and this makes conditional validation
super easy (you just add the specific validation to the form model for each
step. The controllers also inherit, so most of them just have a couple of
private methods to set the model, and you end up with a view folder for
each step. With this approach you have much more control, and there is no
need for any clever libraries. The minus is that you have a lot of extra
files, but you can use folders and name-spacing to organize these. I
suspect it will take at least twice as long to initially write a wizard
using this approach, however it does seem alot simpler to maintain control
and maintain/add to existing wizards, and you do get the ability to track
and record all wizard interactions, even the ones that don't complete.

All best

Andrew

On 14 February 2018 at 13:15, Stuart Harrison <pezholio at gmail.com> wrote:

> Cool, thanks all. That’s really useful. Given me a lot of food for
> thought. I think I’m going to go down the route of using Wicked and having
> some DB persistence, as well as using a form object to separate out the
> branching and validation logic. This still feels like something that could
> be standardised / gemified, as it’s a common problem, particularly in the
> public sector (funnily enough, this is actually for some work I’m doing for
> Hackney Council!). I will continue to mull, but this is super useful.
>
> Cheers
>
> Stu
>
>
> On 14 February 2018 at 13:10:45, Murray Steele (murray.steele at gmail.com)
> wrote:
>
> I think the gov.uk app you’re talking about would be smart-answers (
> https://github.com/alphagov/smart-answers).  This avoids most of the
> problems by encoding all the answers in the url.  E.g. you start at
> gov.uk/something and then advance through some questions until you get to
> something like gov.uk/something/y/aberdeen/1000/dogs/n/n/2018/  which has
> your outcome.  I reckon this is a reasonable approach if you can encode the
> answers in the URL, and you’re not exposing any personally identifiable
> information by doing so.
>
> I’ve also used the approach Rob suggests of hiding all the previous state
> in hidden fields in the form, and using some logic on the backend to work
> out what the next step is.  Ultimately this means that your final step is a
> standard rails create action with a big hash of params that you persist to
> the db in an active record object.  I think this works ok, but it may
> depend how complicated your step-by-step form is, and if there’s any
> branching or whatever.  I didn’t use a gem for this, just rolled my own
> thing.
>
> The advantage of something like Wicked though is that you persist in the
> db at various stages and can get some after-the-fact analytics on abandoned
> sessions and how far through people get which might help you tweak the form
> to simplify it.  Or you can also email people a week later to say “Hey, you
> didn’t finish this thing, can we help / give you a discount / whatever”
> which may be useful.
>
> Cheers,
>
> Murray
>
>
>
> 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/bl
>> ob/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
>>
>>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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
>
>

-- 
------------------------
Andrew Premdas
blog.andrew.premdas.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20180214/3854e794/attachment.html>