Hey there, I think you should consider importance of data and common behaviour of users when deciding whether you save it on backend or in local storage.
Questions to be answered: Should I need half-answered forms? (means you'll save on be) Can user fill form on different computers? (means you can't use local storage) Do users get mad if I lose their data? (say, they cleaned browser cache and local storage gone, they need to start over) After you decide which way to go, I think you need a scope stucture like this: scopes - main wizard scope - step 1 scope - step 2 scope etc. services - wizard manager service I think service should provide an API somethink like this: var w = new Wizard() w.getCurrentStep() w.setData() w.getData() w.nextStep() getCurrentStep returns current step id as string based on the data. nextStep returns the next visible step, based on the data (i should skip a step etc.) setData sets some partial data, service saves it to local storage and also uses it to determine which step user should navigate getData gets data, can be used for ajax and fill a step On Monday, June 29, 2015 at 6:37:59 PM UTC+3, Mark Wilkins wrote: > > Hello all. Longtime ASP.NET dev working on his first Angular project > here. > > I'm working on a wizard-type interface that will contain between 5-15 > "screens" (views), depending on user options. The user will use this > wizard to define criteria that will feed into analytical processing. > > The data structure behind a complete Wizard object might look something > like: > > WizardData > - Setup > - (a few properties) > - Metadata > - (a few more properties) > - Criteria (a collection of different types of criteria objects) > - Simple Criteria (could be 0-4 of instances of these) > - handful of simple attributes > - Complex Criteria type, with the following sub sections (could be 0-3 > instances of these) > - lists of items the analytical process will be looking for (could be > hundreds of items in list) > - a dozen or so attributes about the collection of items > > I'm coming into this project after some design work has been done, and the > team is currently storing the complete "Wizard" object in a single JSON > field in an RDBMS. I think that their expectation was the web application > (written in Angular) would simply make a single REST API call to update the > entire JSON object with any updates that the user might make to the object. > > The workflow might be something like: > - User starts a wizard > - Completes Setup screen > - Based on user input, certain types of criteria are made available. > - Each of these criteria types are displayed on a separate screen, where > they are completed by the user. > - There is no requirement that the user must complete all of these screens > at one sitting. They should be able to work on as little or as much as > they want at a time. > - once the user has completed all of the criteria, they hit perform some > sort of "I'm all done" action. No more edits after this. > > Given all of that context, here's my situation: > > I'm thinking I should be persisting the user input to the backend whenever > the user "completes/edits" a screen. Given the way the API and backend > database is currently designed, however, that means that I would be sending > up a potentially large-ish JSON object for even the smallest change. That > seems wrong. > > What about a separate set of API methods, just for the UI, that will work > on a separate set of DB tables? These would be traditional RDBMS tables, > and would not be storing JSON. When the user hits that "I'm all done" > button, all of the data from this set of tables will be transformed into > the complete Wizard JSON object and stored in the original table. > > Or...Should I be saving everything to local storage as I go, and require > the user to hit some sort of "Really, really save this" button to persist > everything to the backend? What if the user never hits that button, or > just heads home for the day before hitting it? > > I guess I'm looking for advice on dealing with multi-screen forms in > Angular: > - frequent/granular retrieval/update of data? > - initial load of a complex object model that serves many screens, then > save at the end? > - hybrid approach? > > Thanks in advance for any help. > > Mark > -- You received this message because you are subscribed to the Google Groups "AngularJS" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/angular. For more options, visit https://groups.google.com/d/optout.
