Routing and views probably need refactoring about forms-prototypes HOT 4 CLOSED

I think a better way to do this is probably to have an object for each page, with the data stored under it eg 'p1.long-title' - I'm guessing it would be much easier to manipulate page data that way - good for moving and deleting pages.

Yes, this sounds like a better way or organising things. The prototype kit does have built in support for nested data fields so this should be manageable.

A count of the total number of question pages is kept in the 'highestPageId' session variable. The way it's calculated is pretty fragile, and could easily go wrong I suspect.

For this I think we could take the nesting a step further and have the page configurations in an array, which would allow us to get the highestPageId from the size of the array. Something like this:

{
    pages: [
        { 
            "long-title": "What is your name?", 
            "short-title": "Name",
            "type": "text",
            ...
        },
        {
            "long-title": "What country do you live in?",
            "short-title": "Country",
            "type": "text",
            ...
        },
        {
            "long-title": "What is your date of birth?",
            "short-title": "Date of Birth",
            "type": "date",
            ...
        },
    ],
};

from forms-prototypes.

Some notes on how it currently works...

Creating pages

Pages are 'created' by appending a number to the URL for a view - eg. the number 1 in '/form-designer/choose-page-type/1'.

That number is then grabbed from the URL in the routes file, and passed into the page, where it's prepended to all of the form field names. Eg. 'long-title' becomes 'p1-long-title'.

It's also used to generate links and form actions - for creating or editing the 'next' page.

That way, the data for each page gets stored uniquely in the session, and can be retrieved if you know the page number.

I think a better way to do this is probably to have an object for each page, with the data stored under it eg 'p1.long-title' - I'm guessing it would be much easier to manipulate page data that way - good for moving and deleting pages.

The start page is page '/0'

The confirmation page is page '/confirmation'

A count of the total number of question pages is kept in the 'highestPageId' session variable. The way it's calculated is pretty fragile, and could easily go wrong I suspect.

There's a hidden 'currentPageId' field in the edit page form - but not sure it's needed now.

The preview 'refresh' link on the edit page is actually a button. It submits an 'update' action, so that the routing function knows what to do with it. The green button submits a 'createNextPage' action instead.

Previewing pages

There are two page preview views - one for the iframe preview and one for the new-tab preview. Each uses a slightly different nunjucks template, and there are differences in the way that links and buttons work - but perhaps they could be combined into a single view? Not sure.

The start and confirmation pages also get two preview views each - which again, feels like it could be rationalised somehow. Once we start making template views we're going to end up with lots of these!

from forms-prototypes.

Nice! I guess each page could have then an 'index' that was used to specify the ordering - then reordering and shuffling pages just means renumbering the indexes?

from forms-prototypes.

Yes, that's definitely something to look at when we implement the reordering - but we might also be able to rely on the native ordering in JS arrays.

from forms-prototypes.