A Database Controls Your App-Wizard

What you will learn…

  • How Database entries can populate your Wizard

About the Author
Manfred Jehle is CTO at Software Center of Excellence, dieInkasso AG, Switzerland and CEO at CeTris Ltd.
Manfred Jehle has over 30 years’ experience in computer science. Having served in different positions, he has a deep insight into various aspects of information technology. As the CTO at Software Center of Excellence, dieInkasso AG, Switzerland and CEO of CeTris Ltd., he is responsible for the system concepts of all Software Center of Excellence and CeTris® products. Through collaboration in realization and coding, he acquires repeatedly practical experiences which are incorporated into future concepts automatically. Manfred Jehle has many years of practical experience in conceiving, production and application of services from and within different environments. He has developed many practical solutions which are often neglected in theoretical views. For all his solutions, user-friendliness is a top priority. His appropriate technical solutions are oriented to the architectures which are factored in at an early stage to accommodate possible future change. He is the author of various white papers of CeTris Ltd. and various articles at SDJ and Object Spectrum.
Contact: [email protected]

A Database field entry populates your App-Wizard

Imaging the scenarios, you populate your App-Wizard dynamically depending on App state. You will find such a condition in a dynamic workflow environment. In case your workflow is based on states stored in a database, what is more obvious than the fact to make your user interface dynamic. Based on the fact that your .net environment can handle .net reflection to call methods dynamically, you can use this part to do so.
How to create a workflow system based on a database structure is a part others have described in several articles – so I won’t discuss it here.
You have to extend your workflow environment to the point you can handle workflow actions (action is the part between two workflow states) that you use them in a user wizard. The user wizard is a common way to make flow parts available for user interactions. The common way is to hardcode such wizard actions and the wizard flow in the App.
If you go one step back to get a new entry point for a solution, it becomes an interesting task to make all those parts configurable! From the point where you have a database or XML based workflow environment, it is a small step to the solution to have the GUI environment included in the definition.

Wizard environment

What is needed to get a flexible wizard environment based on the common WPF technology?
You need a GUI base part including the flow buttons to go steps forward and back, to cancel and finally accept all entries. The workflow step part can be defined as a user control interacting with the base part to exchange information of validated content and other necessary information. If you have designed such a base layer for the wizard, you have reached more than half of the solution!

Dynamic load environment

Where you achieved the above-described state, you have to define your environment loading your dynamic content. That means your workflow solution part has to generate a result to the question; what are the next workflow steps I have to display in the wizard GUI? You need to get the right content, including the information needed for the .net reflection to load dynamically a class or in case it is already running, to call the entry point for the initialization. Hope you got the idea of having dynamic content instead of hard-coded facts!
If we go one step further, you will see that your dynamic content hasn’t been included in your App assembly. However, you can make your independent assemblies containing the GUI parts which implement an interface you described separately. That gives you the full flexibility for extensions, so there is no need to compile your already tested and approved App twice!

Silent Wizard

If you have implemented the visible wizard environment, you can proceed to make your workflow steps invisible for users, but based on the flexibility you have already implemented in the upper described steps. That means there are several environments which need user interactions as a requirement for having the workflow steps implemented. Also, there are requirements with no user interaction. If you have extended your base part loading the dynamic .net reflection part in a way to achieve flexibility by making them visible or not, you have achieved the full flexibility of a dynamic loadable workflow environment.

Manfred Jehle
CEO at VIP Office a group of CeTris Ltd.
Manfred Jehle

Latest posts by Manfred Jehle (see all)