Product Development

Page tree
Skip to end of metadata
  • Created on 2009-06-04, last edited by Jan Haderka on 2012-07-27
Go to start of metadata
Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 104 rates

GREY Pending discussion. Summary of points on a simple and consistent way to maintain and provide demo content for both STK and ETK, and non-mandatory modules. Please provide additional discussion points in form of comments at the bottom of page.GREY

STK update will not be part of 5.0 release.

This page is not a real concept yet!!!

Notes from Philipp:

Theree are few inconsistencies, but the are some tricky dependencies issues (stk modules / etk depends on some EE modules / optional modules).

Optional modules:

  • An optional modules install their demo pages by themselves, but they make sure to use the IsModuleInstalled(demo-project) conditional task
  • they don't depend on the samples flag but on the existence of the demo-project (except for other sample content)

Non-optional ETK modules (formerly commenting, categorization, still the case for newsletter)

  • the content is (currently) in the demo-project but in the demo-project-etk-only bootstrap folder, which uses IsModuleInstalled(etk)
  • it will be easier to do the inverse: remove ETK pages/paragraphs while installing on STK (remove commenting, tag clouds, ..). This makes it easier to maintain the demo content.

Jan: Both of the modules are now community. However at least categorization has dependency on STK which makes it tricky to bundle w/ STK

Non-optional STK modules

  • the content is in the demo-project, nothing special has to be done

Why must this be like that? Modules the STK or ETK depend on cannot provide their demo pages themselves because of:

  • they are installed before STK/ETK (the dependencies enforce that)
  • the demo-project is installed after STK/ETK
    --> hence this modules cannot install any additional pages into the demo content, as it does not exist on installation time of this modules

Additional notes from Greg:

Taking the case of the newsletter-stk module:

  • easy solution: move ./magnolia-demo-project/src/main/resources/mgnl-bootstrap/demo-project/demo-features/website.demo-features.modules.newsletter.xml to ./magnolia-module-newsletter-stk/src/main/resources/mgnl-bootstrap/demo-project (i.e the file is IN the newsletter module, but will be bootstrapped BY the demo-project module upon install/update)
  • other solution: use a ModuleDependencyBootstrapTask in the NewsletterSTKModuleVersionHandler to bootstrap this file IF the demo-project module is present.

The first solution has the advantage that the page will be added even if one installs the demo-content later. Unfortunately, it also means that you have to have the whole demo-content installed. It also means the page will not be added if you install newsletter-stk after demo-content.
The second solution has the advantage that the page will be added when newsletter-stk itself is installed. It also seems (at least to me) a little less voodoo. Additionally, the day we have user-approved install tasks (MAGNOLIA-1664@jira/MAGNOLIA-1764@jira), one will easily be able to update the version handler to use the new task/options, and FINALLY, users will be able to get that single feature-demo-page without having to have the whole demo-content module.

1 Comment

  1. Jan Haderka

    Third possible solution (and imho the best in long term) - separate demo from STK bundle.
    Advantages:

    • optional modules can add optional dependency on demo and add their own content when they want
    • demo can be updated more often then the whole release and not only by the core team
      • update of content for marketing reasons
      • extra demo features for sales
      • etc
    • release of STK would not force re-releasing of demo content
      Disadvantages:
    • STK bundle would come w/o showcase, however it will be still present in CE and EE bundle and one since STK is not installed separately anymore it should not be big issue.