Hot answers tagged

3

Since you want to persist things on the server between wizard steps, it seems perfectly acceptable to consider each step as a separate resource. Something along these lines : POST /wizard/123/step1 POST /wizard/123/step2 POST /wizard/123/step3 By including hypermedia links in the response, you can inform the client on what it can do after this step - go ...


2

I had needed to do something similar some time ago, and the following describes what we end up with. We have two tables, Item and UnfinishedItem. When the user fills in the data with the wizard, the data are stored in UnfinishedItem table. At each wizard step, the server validates the data entered during that step. When the user is finished with the wizard, ...


1

It should scale perfectly well, if you make async calls to the wrapper app. IF you're making synchronous calls, you're limited by the response time of the external service and network. You don't have much control over this. By making a call to the wrapper though, and not waiting for a response, you can perform the rest of your processing and either wait for ...


1

Have a look at CLOS, the Common Lisp Object System, described notably in Object-Oriented Programming in Common Lisp: A Programmer's Guide to CLOS in 1988. CLOS itself was influenced by existing object systems like Flavors and CommonLoops. The following defines or redefines a class when called: (defclass my-class (multiple parent classes) ((x :initarg ...



Only top voted, non community-wiki answers of a minimum length are eligible