- In IDEs - and many more technical RCP applications - most task is controlled by creativity. E.g. you get a task - create this or change that - and then it is more or less up to you how you want to solve it. You might have a number of large-scope processes - like you have to check in your work and change the state of issue reports - but nothing on the smaller scale.
- In many enterprise RCP application most tasks are controlled by processes. E.g. you have an exact description of how to perform most tasks - like create new account or change the payment plan. Processes are here centered on the smaller scale as well on the larger scale - like in which sequence data must be entered when making a new credit agreement.
That does not match well with many enterprise applications where the user must be able to 1) service phone calls in the middle of an on-going task and 2) alternate between a number of tasks...
The current wizard interface has a number of other problems as well:
- The interface for a wizard page (IWizardPage) assumes that a page cannot be "stale" compared with the model - which of cause is fine as long as wizards are modal... Note that this is actually solved in another similar interfaces used in the Forms UI API (IFormPart).
- The interface for a wizard page also makes the different pages aware of the previous and next pages as well as the actual control of the page which is a little peculiar when doing screen flows, where you might want a high degree of reuse of pages between processes.
- The use of WizardPage.setControl() seems to be one of the major sources of problems when developing pages - people just forget :-(
Until now we have implemented the needed processes as needed, but now are going to implement a rather large number of processes - of which many will be quite similar, so we want to implement some framework to ease the work and to make the result more maintainable.
The question is now: what would you do here? Implement a new wizard viewer in a view that can show multiple concurrent wiards or implement a new (simplified) flow interface that matches the requirements exactly? For those of you that have implemented RCP applications already, what have you done in these?
9 comments:
Eclipse Riena is just developing a process - driven UI - perhaps interesting for you ?
ekke
"what would you do here?" I would at least file an enhancement request in bugzilla, since you have valid points and ideally, the wizard framework should be evolved to support your use cases too.
We were having a look at integrating the Spring Webflow engine into our RCP apps. The engine itself is platform agnostic, but view handlers would need to be written, and a Flow Repository for obtaining flow definitions from extension points would be an ideal addition. Thoughts?
You might look at and vote for bug 147762 which has the same intention.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=147762
Gerd
@ekke, I'll have a look at Riena after my vacation. It does look like Riena has a number of interesting features. Do you have any tutorials or articles I can look at in the meanwhile?
@Boris, I will, but I prefer to ask for opinions first ;-) It does happen that somebody else have already implemented a solution to the problem, and in this case, I think it is just fine to avoid overloading bugzilla...
@bredan, I would prefer not to add any more frameworks into the application in question :-)
A few more plug-ins can be all right but new frameworks in the size of Spring is just too much for this type of problem...
Anyway, if we added Spring we would need a completely new way to design our pages as well, which I don't like.
Hi Tonny,
here's a link to a screenshot of the Riena UI. There is also a Riena 'Getting Started' wiki page.
Regards,
Elias.
@Thanks Elias, I will study this right after my vacation (the next three weeks).
Post a Comment