How to organize a multi-step app

Design
1

Hello everyone. After working with Rails full-stack for several years, in the past year I realize that using a JS front-end framework with Rails back-end is the way I want to develop the next applications.

Among the available framework I have picked up Ember mainly because of its routing system (I do believe that UI development should be url-driven).

So, few months ago I started creating a couple of “dummy” apps to learn Ember basic and watching all the screencasts I could and now I feel it is time to work on something more “serious”.

At my company, we have an aging Rails (2.3) app that seems to be the perfect candidate to be updated using Ember. My initial plan is to make the controllers respond to json (touching as less as possible), remove all the UI stuff (views, js, css), and make it talk to an new Ember app.

The application has (of course) some peculiarities that I’m still not sure how to address. So I’d love to hear from you guys how I may tackle them.

Let me provide some context without going into too many details that for this conversation could be useless (please, feel free to ask for more if you think I’m missing anything).

The app (only) displays analytical results imported daily though a rake task from a legacy system. To get to the results the user browses through a series of steps in which he selects one or more options among the available ones. According to the values selected during the previous steps, the last one displays the desired results. The steps are the ones below:

  • Product(s)
  • Specification
  • Batches
  • Test

At the first step the user selects one or more products he’s interested in, for instance Product1 and Product3.

At the second step the user selects the specification he’s interested in among the ones used to analyze Product1 and Product3, for instance IS.

At the third step the user selects the batches he’s interested in among the ones of Product1 and Product3 analyzed with IS, for instance 001-14, 002-14, and 004-14.

At the fourth step the user select the test he’s interested in among the ones common to batches 001-14, 002-14, and 004-14, for instance pH.

At this point the pHs of the 3 batches are displayed.

As I mentioned at the beginning, I love the fact Ember is built around urls so I’d like to be able to have a different url for each step and the url should include the selections done until that point. In this way users may share urls.

I’m thinking to have a template and controller for each step but I’m not sure how to organize them in a way to be able to store the selected values in the route (in some step the user may select dozens of elements). Moreover, I’m not sure where I should store the selections done in each step in order to be able to retrieve them at the next one.

What do you guys think about?

Thanks for reading through this and I appreciate any suggestions.

1 Like
2

While I also agree that apps should be url driven, I hesitate to embrace urls like example.com/test1param/test2param/test3param/test4param/result.

The general rule is only one or two levels deep, so to my taste I would prefer just example.com/search, and figure out some clever way to make the form all on one route. All that said, rules like that don’t necessarily apply in certain types of sites, and yours may be exactly the type that should make an exception. I certainly appreciate the elegance of having a chunk of url per specification parameter. Still, it irks me that there are like thousands of different urls taking you to the same search result…it’s what motivated me to suggest making it all one route.

It sounds like a really interesting project, and I’m curious what the other folks on here will have to say about the design philosophy.

3

Hi tristan​pendergr, Thanks for your reply.

I don’t see how there could be thousands of urls taking to the same results since to see the same results you should specify the same params on each step.

Anyway, one idea I got (totally untested yet) it is to create a digest from the params and use it in the url. So the urls will look like example.com/searches/5ebe2294ecd0e0f08eab7690d2a6ee69 And in the route I get the params from the digest first to know the already selected values. When I complete a new step, I update the digest adding the newly selected params.

As I said, I have’t found the time to try it and I’m not sure yet if this solution is feasible. So, I’d like to know what more experienced Ember developers think about it.

4

It sounds like you work in tech for a company with a production-line that needs a chemist. :smile:

There are options. One could be query parameters. The user sets controller state on top of a route with a model. Each of your routes would then match all of the available things to that point and then the query parameter would identify each of the filters selected by the user. This will result in messier-looking URLs, but in my opinion is most “correct” as long as you intend searches to be ephemeral/calculateable.

Alternatively you can think of each as building up a new model for the next route. In that manner of thought you could treat this as a process of creating a new RESTful resource (a specific search) which has defined parameters that the user created. That search would then have a unique ID as you propose (the user is “creating a search”), it doesn’t need to be a hash. If you’re taking that approach, I’ll have something for you at some point in the future: ember-flows and ember-flows-generator.