Implementing screen flows

On EclipseCon '08 I had a presentation named Lessons Learned from an Enterprise RCP Application. As said then, one of the major differences between most Eclipse IDEs and many enterprise applications is the way the performed tasks are controlled by the end-users:

• 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.

Out of the box Eclipse RCP supports wizards as the primary type of processes engine. In the default implementation, wizards have one major limitations compared with what you would like to see in many enterprise applications: they are modal and thus you can only have one active process at any one time.

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 :-(

Of cause the wizard implementation has one major point that speaks for it: the current UI design tools - like SWT Designer - understands wizard pages, but not whatever we invent.

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?

View versus Editor in RCP - a different opinion

In a current blog thread David Orme writes, you should use editors in RCP applications when you need life-cycle management...

I very strongly disagree with this. For me the important statement by David is

The only real difference between a view and an editor is that there is exactly 1 editor area and once visible, it is always visible even if no editors are open.

The current implementation for editors does not allow you to mix editors and views in one stack (or folder), which can be a serious problem in many applications. E.g. consider the banking application where you use a perspective to show a lot of information about a specific customer. In a few cases you want to edit parts of this information...

Would you then use an editor for this? What would you put in the editor area when you don't need to edit any customer data?

The basic problem here is - in my opinion - that the editor area is a serous waste of screen estate when editors are not needed.

You can find a presentation on this from EclipseCon '08.

I'm pro-cloning - sort of

Begin at EclipseCon is hard work! To follow all the tracks I would like to, I will have to clone myself a couple of times!

At any one time there are at least 1-2 tracks with good serious talks on subjects I find interesting, there are plenty of people I would like to talk with, lots of coffee I need to drink, quite a few exhibits I would like to visit.... While I'm at it, I could use a couple of me's to relax while the others work, so I'm not to tired in the evening, when the official program is over and we all begin on the more informal networking....

Building a local Eclipse user group

If you consider starting an Eclipse user group or a an Eclipse society, then this Eclipse '08 BoF might just interest you. Building a new local Eclipse community is not exactly rocket science, but it does take some work from a few dedicated souls.

In this BoF, we will talk about how to build interest for a local community, tips for events, how to get sponsors for the events and similar essential user group stuff.

One hope is that we might be able to setup series of similar events in a region - e.g. Europe - where we can get companies to show they stuff multiple times... This makes it easier for us and likely more interesting for them as they get a bigger audience...

At the end of the meeting we should hopefully setup a mailing list or similar to help exchange ideas for events in the future as well.