The spv.vds Namespace

The spv.vds.CCInputParam Class

… more

The spv.vds.Campaign Class

… more

The spv.vds.CampaignCollection Class

… more

The spv.vds.ConfigQuickInfo Class

… more

The spv.vds.ConfigQuickInfoResult Class

… more

The spv.vds.ServiceInfo Class

If the ServiceInfo.has_message is true, then the message must be displayed before initializing the client. If blocking_dialog is true then the client shouldn't be allowed to start at all. This is usually in the case of maintanence. @export @struct … more

The spv.vds.VdsClient Class

VdsClient provides a layer of abstraction between GUI code and session-/protocol-handling. The configurator system is stateful. Session state is shared between server and client, this is a source of complexity and can hopefully be removed at some point in the future. VdsClient provides synchronization of session state between server and client by centralizing management of the shared state inside this class. Member functions are stateful if the member function name begins with "session". Other member functions are state- and session-less and can be called at any time, in any order. Most session dependent functions also require a loaded configuration. Preconditions should be documented for each member function in this class. The configurator system can be simplified as the following three phases: A. The user finds the configurator application on the web or in the showroom. B. The user choose and change the product components (called items) until the user is satisfied or leaved the application. C. The user saves the configuration for a later time or choose to place an order or request a sales contact for the built configuration. Technical usage example 1, Starting a new configuration session and interacting with the user. (Step-by-step example of phase B): 1. Construct an instance of spv.vds.Client 2. Call sessionInit 3. Call getIntroPage to retrieve the available start configurations 4. Generate images for the start configurations using getConfigImage 5. Display the available start configuration images to the user using the appropriate techniques for the GUI implementation. 6. The user chooses a start configuration 7. Send that start configuration to sessionLoadConfig 8. On success, call sessionGetRootMenuItems and sessionGetImage 9. Populate the GUI root menu with menu items and wait for the image response 10. On image success, load and display the configuration image 11. The user makes a choice about which menu to open 12. Call sessionToggleItem for the user chosen MenuItem (both menus and product components are MenuItems) 13. On success, call sessionGetStateUpdate to populate the currently open menu with menu items. 14. The user clicks an item in the currently open menu, send that MenuItem to sessionToggleItem and handle response. 15. On success, update the currently open menu with new MenuItems (most menu items will usually be unchanged, but some may change state and some may disappear while others may be added). Call sessionGetImage to get the new configuration image and wait for response. 16. On image success, load and display the configuration image 17. The user clicks a new item and the sessionToggleItem cycle continues until the user closes the application or decides to place an order for the built configuration. (this step is customized action for each configurator application, eg. cars and bathroom products require different types of shopping cart solutions) @export … more

The spv.vds.VolvoCarSpec Class

… more

The spv.vds.VolvoCarSpecItem Class

… more

The spv.vds.VolvoCarSpecTechData Class

… more

The spv.vds.VolvoRetailer Class

… more

The spv.vds.impl Namespace

… more

The spv.vds.ipprot Namespace

… more

The spv.vds.ipprot_nova Namespace

… more