Page tree
Skip to end of metadata
Go to start of metadata

This page intends to provide a quick feature status on the widgetset and browser compatibility of Magnolia 5.0. It should reflect the implementation status and collect improvement proposals on various aspects of the widgetset.

(green star) Green stars denote what we do for 5.1.

(blue star) Blue stars denote what we do for 5.2.

1. Extend the widgetset


  • Modules cannot add UI components to the Widgetset


  • Step 1
    • one can specify a different widgetset qualified name to use instead of ours
    • currently provided as widgetset param in ui-admincentral module descriptor
      • info.magnolia.ui.vaadin.gwt.MagnoliaWidgetSet
    • then it's up to the developer to compile it properly and extend the MagnoliaWidgetSet
      • we fall back on the default widgetset if configured widgetset
        • does not exist
        • does not extend the MagnoliaWidgetSet
        • rescue mechanism? (à la filter-chain)
        • at least keep the original sw else,
    • (tick) moved it first to configuration but
      • makes no sense to change it at runtime
      • if it's misconfigured the whole admincentral is screwed
      • (green star) we change it again in favor of
    • (green star) documentation
      • developers should not check out and modify our sources / aggregating widgetset
      • provide enough info so that they can extend it
      • (warning) if developers only use (i.e. not develop) custom widgets, they still have to compile that widgetset once
      • whatever we do, developers will try to reproduce our patterns
    • this is at least a first step for client projects but we cannot ship ready-to-use public modules with that
  • Plan B
    • (blue star) The aggregating widgetset in use is the one at bundle level
      • we explicitly reference an aggregate sub-widgetsets in ui + ce modules, if any (dam perhaps)
      • either manually or through the maven vaadin plugin
    • developers can checkout that project, add another widgetset to include, and build it easily
  • Rolls-Royce option for Magnolia 42
    • The bundle's widgetset fetches and extends widgetsets from all modules on the classpath
      • It is recompiled whenever magnolia or one of its modules is updated
      • As an update task
      • ideally happens on the server (author instance is unavailable while being updated anyway)
      • transfer widgetset to further instances through activation?
    • Each module that bundles its own widgets needs to provide and declare a widgetset
    • magnolia maven plugin?
      • aggregating and computing new gwt.xml 
  • Related: the Vaadin theme
    • there can be only one in use in the AdmincentralUI
    • (blue star) we try to aggregate module themes at bundle level too
      • make sure all Sass/CSS stylesheets are properly traversed 
    • currently some module styles (e.g. dam) stay under ui-admincentral
    • theme is currently configured on AdmincentralUI via annotation
      • we can also move its configuration as a first step


2. Widgetset - Architecture

Development / Developer's Time / Permutations


  • A lot of work on magnolia_ui doesn't require widget changes
    • e.g. api changes, configuration, form fields, shell apps
  • Many developers don't require widget changes either
  • When developers rebuild magnolia_ui they lose 5-10 minutes each time waiting for GWT permutations to be compiled
  • Hudson occasionally goes nuts with compilation of GWT permutations
    • OutOfMemoryExceptions
    • The whole widgetset is currently recompiled many times more than it should
      • e.g. for a minor javadoc improvement
      • for both 5.0.x and master branches
  • It is currently too easy/tempting for developers to fiddle with widgets or client-side code for specific admincentral needs
    • whereas widgets should stay utterly stupid, independent from their usage in admincentral
    • This might result in shortcomings by breaking the flow of UI development
      • UX specs first, identifying issues to be solved at the widget level, then feeding admincentral development with incremental improvements


  • Split the widgets out of magnolia_ui, so that
    • Widgets are built and made available upfront from the rest of development
      • fetch from nexus
    • GWT permutations are only compiled where they matter
    • Widgets are more usage-agnostic, i.e. reusable
      • should open up widget apis for extension or custom usages
      • can eventually be tested/ui-tested outside magnolia
  • (blue star) Aggregation widgetset at bundle level (semantically, i.e. widgetsets from ui + ce/ee modules)
    • not as a sub-module of ce-bundle
      • ideally it's a standalone project that only depends on other widgetsets
      • so that it's rebuilt only upon client-side changes
    • profile to enable gwt compilation
      • inactive by default
      • has to be active for hudson and releases
    • The current magnolia_ui widgetset stays where it is
      • no more gwt compilation there
  • Can we compile a first set of base permutations first?
    • superdevmode builds 3 of them...
  • Can we find a default development (in IDE) setup vs. default maven profile to only include yet even more limited permutations?
    • some devs work with Firefox, some with Chrome or Safari
    • we also need to test some features on the iPad too from time to time
  • Related topics:
    • Widgetset architecture main changes
    • Browser support and widgetset optimization




  • magnolia-ui-vaadin-common-widgets depends on magnolia-ui-vaadin-integration (=> transitively on core, api)
  • magnolia-ui-vaadin-widgetset depends on magnolia-ui-vaadin-theme
widget-centered dependency graph from an earlier alpha stage - theme wasn't there, model became api - the rest is still mostly valid.


  • We want to get rid of such dependencies
    • it's quite a lot of work, see comment in

      Error rendering macro 'jira'

      Unable to locate Jira server for this macro. It may be due to Application Link configuration.

    • we try to do it as a continuous improvement, step by step
    • (tick) slight refactoring of the action bar  MGNLUI-1991 - Cleanup Actionbar dependencies and apply proper MVP pattern Closed
      • because the View interface is currently implemented by widget
      • instead of Presenter producing a ViewImpl for it, using the widget internally
      • so that widgets don't depend on api (the View interface)
      • also refactor ActionbarFactory into ActionbarPresenter
  • (blue star) Document it
  • Move whatever doesn't belong to widgets to the proper place


Forks and patches


  • Currently, we use a fork of the context menu addon - duplicated in our code base
    • package org.vaadin.peter.contextmenu under magnolia-ui-vaadin-common-widgets
  • We also have patches for Vaadin tables, treetables and drag-and-drop wrapper
    • generating things like VScrollTablePatched class under com.vaadin.ui package
  • It is not clear when browsing sources why we have such packages
  • It is not clear what to do with it if changes are required


  • (blue star) We provide them as standalone maven modules
    • very rarely touched
    • magnolia-ui-vaadin-tables, magnolia-ui-vaadin-contextmenu
  • Explain why they are here and why we need them
    • (tick) README.txt in those packages with rationale and howtos
    • proper module descriptions
  • Explain how to maintain them


Structure proposal

  • magnolia_ui
    • most ui modules like today
    • magnolia-ui-vaadin-theme
    • magnolia-ui-vaadin-integration
    • pages
      • magnolia-ui-vaadin-editor
    • magnolia-ui-vaadin-widgetset
      • magnolia-ui-vaadin-common-widgets
      • magnolia-ui-vaadin-tables
      • magnolia-ui-vaadin-contextmenu
  • (blue star) The editor moves back to the pages module 


Widgetset structure


git repo



Widgetset name (.gwt.xml)









check for 5.1 EE

enterprise / content-dependencies





just here as a ee module example







replaces MagnoliaWidgetSet (5.0) - integration and compiler options

modules / dam





just here as a ce module example

magnolia_ui / pages





replaces PageEditorWidgetSet (5.0)







replaces CommonWidgetSet (5.0)

magnolia_ui / magnolia-ui-widgetset





extracted from CommonWidgetSet (5.0)

magnolia_ui / magnolia-ui-widgetset





extracted from CommonWidgetSet (5.0)

magnolia_ui / magnolia-ui-actionbar





just here as examples for further ui modularization

magnolia_ui / magnolia-ui-mediaeditor











M5-agnostic vaadin components - not for now


Theme structure



3. Browser support

What we do currently (5.2.2)

  • We compile a specific set of permutations (20) for compatibility reasons
    • mainly to highlight our lack of support for smartphones
  • We have a fallback page for these unsupported browsers
    • rather than leaving the user with a blank page loading forever.
  • Unable to locate Jira server for this macro. It may be due to Application Link configuration.

The following table gives a general overview of the browser/platform support since Magnolia 5.0.

Modern browsersIE8IE9IE10IE11iPadAndroid 
Magnolia 5.0(tick)(error)(tick)(tick)(error)(tick)(error)(error)
Magnolia 5.2(tick)(error)(tick)(tick)(tick)(tick)(error)(error)
Magnolia 5.2.2(tick)(tick)(tick)(tick)(tick)(tick)(warning) *(error)

* Although we enabled the permutation for Android tablets from Magnolia 5.2.2 on, and it generally works well in Chrome, we don't claim to fully support Android just yet.

What we should do

  • (star) We should rework messaging on the unsupported browser page, to be less web browser dependent
    • It is confusing if one logs in on an android smartphone, and reads 'please login using firefox, chrome, etc.'.
    • see proposal below.
  • We should compile the 12 GWT standard production permutations
    • limiting permutations is only a nice-to-have at development time
  • We should reconsider usage of mgwt in magnolia-ui
    • we use maybe 10% of it (gesture detection)
    • we could then lower again the number of required permutations
      • 12 permutations as of IE8 support
      • then increased to 20 permutations with mgwt's android_tablet mobile-user-agent
  • We should display a warning message for browsers where support is uncertain
    • based on e.g. user-agent, feature detection, screen estate
    • example: "You're trying to use Magnolia 5 on a browser which we currently do not support. We cannot guarantee that it will work properly, if at all. We encourage you to log in using a modern browser. - [Keep going anyway]"
  • There are additional means for optimizing the widgetset for devices/browsers with low capabilities
Reworked messaging for unsupported browser page


You're trying to use Magnolia 5 in a set up we currently do not support.
Please log in on an iPad or a desktop machine using a modern web browser.

For a detailed list of supported platforms and browsers, see here.

We apologize for any inconvenience caused.


Status 2013.08.29

(blue star) We do the widgetset-at-bundle-level step

(blue star) We also do the renames/reorganizes in the UI

(green star) Speaks for magnolia properties

(blue star) Auto-discovery?

  • Should we do it as a guideline?
  • It's helpful for others

  • or through an archetype?

Performance (hudson)

  • full-fledged gwt compilation in bundle build
  • (blue star) we split this out
    • depends on ui, modules
    • is depended upon by bundle
    • we use profiles, or subset of the reactor

Rescue UI when admincentral config is messed up (widgetset, security) ?


  • it's better if it's one significant step, but it may well require too much time vs. 5.1 stories
  • For 5.1, we do as little as changing configuration to magnolia properties, so that we don't ship something we know will be removed
  • everything else is for 5.2 then


Status 2014.03.17


  1. Reduce build size
  2. Reduce build time
  3. Get faster CI feedback
    1. unit (UI)
    2. integration (bundles)
  4. Gain stability
  5. (Self-explain how to extend widgetset/theme)


  • Whenever there's a tiny change in UI framework, the whole UI is rebuilt, including the widgetset
    • GWT compilation takes 50% of build time, whereas client-side classes change on little occasions
  • Jenkins doesn't have build triggers at sub-module granularity
  • We want to keep client-side code where it belongs (module-wise)
    • e.g. pages-editor at same git repo as pages app, common-widgets inside UI


  1. Extract magnolia-ui-vaadin-widgetset
    • out of UI
    • not as bundle submodule either (wouldn't rebuild it even more often)
    • as an independant module
      • runs after the UI
      • under dependency management in bundle
    • should also perform aggregation of VAADIN themes and Sass compilation
      • theme and widgetset are used in a very similar way by Vaadin, there is only one at a time
      • this is currently 'hacked' in ui-admincentral 
    • gain:
      • mainly unit CI feedback on UI
      • move back 5 module themes to where they belong (ui-contentapp, about-app, pages, dam, cdep)
  2. Exclude client-side modules from UI parent project's reactor
    • We configure separate jobs on CI to cover these artifacts
    • (warning) Who should run first? We might have some "hen VS. egg" issue for now because of poor sub-module dependencies
    • Or configure the widgetset job to run only upon git changes at certain paths, not necessarily triggered by new SNAPSHOTS 
  3. Clean up dependencies
    • Need to analyze these dependency again, but:
      • We've made one step for 5.3 already regarding Actionbar widget VS. View interface
      • We should be able to untie API from Vaadin-int without too much effort (AvailabilityRule implementations, MVH)
      • We also already analyzed/specified a dependency issue regarding notifications/alerts/confirmations

Ideally, we end up with a build flow as follows:


  • No labels


  1. Given that the creator of Jenkins himself tends to prefer git-hooks to trigger builds rather than SCM polling (see, I tend to think we could also have a git-hook that specifically triggers the (queuing of the) build of widgetset under certain circumstances (i.e have that hook on ui, pages, etc.. executed if gwt code was changed)

  2. Shouldn't API be also extracted away? Ideally, it being API only, this module in particular should change only for the major releases. Otherwise, yeah, widget set is the biggest pain during releases, and if i read JIRA change log correctly, in last 2 maintenance releases we didn't touch it either so there should not have been need to re-release it either (and no, I don't think that keeping version numbers in sync is worth the pain of rereleasing widget set).

    1. Shouldn't API be also extracted away?

      If we did that, 1) we'd need to "fix" all dependencies straight away, and more importantly 2) every modules that has custom client-side ui code (e.g pages) would need to be split as well, which is not desirable (harder to maintain, while the split parts would have 1:1 lifecycle)

      The key to understand what we really need to do is to differentiate between a Maven dependency and a Jenkins job dependency, and granularize that notion to (sub) module. Unfortunately, as we currently configure it, Jenkins will trigger a downstream job regardless of what has changed in the upstream job (which is a good default), whereas we need to have this particular trigger, specifically for widgetset, to be more fine grained.