This project is read-only.

Orchard 1.7 Setup Extensibility & New Recipes feature team

Topics: Announcements
Nov 6, 2012 at 9:15 PM

This thread is to discuss setup extensibility and new recipes in Orchard 1.7.

This feature would enable extensions to the setup wizard so modules can provide their own steps.

Nov 8, 2012 at 7:15 PM

Very simple to describe, designing it a little bit harder ;)

Today we can somehow have script which are ran during Setup. But there is no way to integrate user data in those scripts like, email address, twitter account, or any custom value that could be used during Setup to pre-configure specific modules.

For instance, if I choose to setup a Blog, we could ask the user to enter a twitter account to add a twitter widget automatically, or the Blog tag line. We should give developers more options to create those custom recipes.


Key design decisions will be about how to represent forms (simple template, shape, code base form, ...), how to validate them, and how to communicate the entered values to the recipe. Also how to have conditional sections, like if the user doesn't want a twitter widget on his blog, how no to execute this portion of the recipe.

Ultimately, we could reach the point that recipes could be hosted on the gallery, and the setup screen could help among those.

Nov 8, 2012 at 9:13 PM

Is there a bridge to build maybe between the forms API and a possible representation of forms in a recipe file?

Nov 8, 2012 at 11:08 PM

Could be easy. But in C# we can have conditional statements to render a form. Maybe don't need a representation but a way to call specific dynamic forms. The recipes could then actually come from Modules. 

Nov 14, 2012 at 11:07 AM
Edited Nov 14, 2012 at 11:15 AM

Do you think extending the workflow work could give us these dynamic step/wizard type flows? By extending the workflow engine to support pageflow as described in the following link we could get a lot of flexibility for not only the setup screens but also the rest of Orchard.

The whitepapers are very interesting reads

This would fit with your description of the workflow design, we would have an 'InteractionActivity' as described in the article that represents the interaction with the user to get setup data. Possibly a PageInteractionActivity, FormInteractionActivity, FormInteractionGroupActivity depending on if the module wants a custom page route to be displayed or just to use the forms API.  

At this stage i don't think a change to the recipe file would be needed. Just adding a Workflow support flag to pull down the Workflow module? By just enabling the feature the module could contribute its 'InteractionActivity' actions to the work flow engine for the the 'Setup' workflow definition. Possibly a nice setup provider API around this that builds on a pageflow API such as below?

    public interface IPageflowStepProvider : IDependency {
        string Pageflow { get; }

        void GetSteps(StepBuilder builder);

    public abstract class SetupStepProvider : IPageflowStepProvider {
        public string Pageflow { get { return "Setup"; } }

        public abstract void GetSteps(StepBuilder builder);

    public class TwitterModuleSetup : SetupStepProvider {
        public void GetSteps(StepBuilder builder) {
            // Add a step to the setup page flow - 'DefineStep' because it may be overridden or extended by another module like shapes.
            builder.DefineStep("TwitterSetup", T("Setup Twitter"), "7")
                .Action("Setup", "TwitterSetup", new {area = "Orchard.Twitter"})
                .OnCompleted(x => x)

Possibly behind the scenes a PageflowManager dynamically builds a workflow of InteractionActivities with the page model data defined above. 

Having a pageflow engine would allow us to automatically provide feedback to the user on completed and future setup steps, optional steps could be defined as above and it gives the module authors a lot of flexibility to create/validate the forms they require and constantly re-evaluate based on the workflow state whether to change their setup properties or remove the step entirely.

I think an approach like this would give us what we need for setup but also provide huge benefit for other scenarios that require pageflow such as e-commerce.

In summary this may be completely too complicated and off track in which case just ignore but I thought it meets the requirements and solves the problems you mentioned along with getting reuse of other work and extending Orchard's flexibility in multiple areas and use cases.