[Best Practice] Separate Demo eSpaces from the Main Application on the Forge

Community Forge
On our radar

Having the Demo example eSpace on the same application it will lead to the demo espace to be moved from one environment (QA, PRD) whenever the application is promoted. 

Removing the eSapce on DEV does not go the trick since when a new version is uploaded the eSpace will be there again.

Created on 1 Mar (3 weeks ago)
Comments (4)
3 Mar (3 weeks ago)


this should be better in all ways.

we like the demos, but do not like them in our environments :)

4 Mar (3 weeks ago)

I agree with this to some extent. 

Having demo eSpaces out of the application is a good idea, but I'm not seeing people downloading two different apps/modules just to see how it works. For this, I believe that there is a simple and a complex solution.

The simple? When deploying via lifetime, do a custom deployment and check only non-demo eSpaces.

The complex? Allow an eSpace-level configuration like "Is Demo eSpace". This would mean that deployments won't consider these eSpaces as well as Service Studio would not allow these eSpaces to appear on the References pane (to be referenced, of course).

Still a good idea, though.

6 Mar (3 weeks ago)

I agreed.

Also demo screen should not be counted in AOs.

13 Mar (12 days ago)

Agreed, this is a pain.

IMO the best practice push should be:

  • If you provide a Forge Component, you also need to provide a Demo Application that shows how it is used.
  • As part of the description of the Forge Component reinforce that you should install instead the Demo Application through Service Studio (it will automatically install the Forge Component). This way the user only has to explicitly install one app (answering part of Armando Gomes' concerns.

I'd actually go further and do a slight overhaul of the Forge by simply:

  • Add a new Demo Application attribute to the info of Forge Projects, where you can specify another Forge Project.
  • Any Forge Project that is not marked as Application, Template or How-tos would be in a Pending state until the Demo Application attribute is filled (not available on the Forge for users to browse, download and/or install).
  • Any Forge Project that depends on a Pending Forge Project would also not be available on the forge for users to browse, download and/or install.
  • Redesign the Forge Project page itself to guide/reinforce that users should check/install the Demo Application instead if the Demo Application attribute is filled (or if project is not Application, Template or How-tos?).
  • Provide guidelines for developers of Component/Demo Applications to:
    • create simple, one-module applications, with no public elements (so that they don't clutter the Producers list in the Manage Dependencies like Armando Gomes' mentions).

This way we don't need to change anything in the concept of an eSpace Module, just on the Forge itself (and educating the community).

If the Demo is a different Application altogether, I wouldn't be too concerned with AOs, as IIRC they are not enforced on the Development environment