This project is read-only.

Workflow across modules

Topics: Customizing Orchard, General, Writing modules
Oct 19, 2012 at 2:22 PM

Hello everyone

I am designing a new application for a client that is going to be largely based on workflow. The major areas of data entry are going to be concerned with Persons, Organizations, Relationships and Contact Information.

What I want is to build a workflow for the high-level process the drive the user through the major areas of data capture but each of those stages could have a sub workflow. Something like
Person stage captures personal information and then that top workflow moves to the Contact Info stage which itself has multiple steps.

There are going to be multiple types of users of the system and not all roles will follow the same workflow. Some will not need to capture Contact Info at all so we don't want to force them through those views.

Here is the piece I am not sure how to do. I'd like to encapsulate all the major areas into modules
PersonInfoModule, ContactInfoModule, OrganizationInfoModule, etc. Yet, the workflow will need to access routes from all of these - and be smart enough to not die if a specific route is not found.

The idea is that IF the workflow transitions to an unknown route then we have to nicely tell the user and give them the option to "skip" that step. Thsi is because workflows are going to be rather volatile.

Any thoughts?

We are trying to validate if Orchard is going to work for this project so, there are more questions coming in separate threads.


Oct 19, 2012 at 5:11 PM

Why do you want to make them separate modules? Why not features?

But that is a separate concern. You could build a step interface and implement it in each feature. Then, inject en Ienumerable of that interface and that will enable you to discover the set of steps that are available.

Oct 19, 2012 at 5:17 PM

This is a very good point. My main intention is to allow separate tracks of development and because not everyone will need all components.
There is a somewhere multi-tenant aspect to this. ALL states have access to ALL persons, but not all states will care about address information.

So, my thinking was that I should manage the non-common aspects as separate modules.

However, I think you are correct that these could be better as features. It almost seems like the entire LoB aspect of this system could be a single module with multiple parts that are all attachable to comments, tags, etc.