Widgetset and browser support

1. Extend the widgetset

Problem

• Modules cannot add UI components to the Widgetset

Options

• 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, magnolia.properties
  •  moved it first to configuration but
    
    • makes no sense to change it at runtime
    • if it's misconfigured the whole admincentral is screwed
    •  we change it again in favor of magnolia.properties
  •  documentation
    
    • developers should not check out and modify our sources / aggregating widgetset
    • provide enough info so that they can extend it
    •  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
  
  •  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
  •  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

Problems:

• 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

Options:

• 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
•  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

Dependencies

Problems:

• 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

Options:

• We want to get rid of such dependencies
  
  • it's quite a lot of work, see comment in MGNLUI-1896 - Getting issue details... STATUS
  • we try to do it as a continuous improvement, step by step
  •  slight refactoring of the action bar  MGNLUI-1991 - Getting issue details... STATUS
    
    • 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
•  Document it
• Move whatever doesn't belong to widgets to the proper place

Forks and patches

Problems:

• 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

Options:

•  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
  
  •  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
•  The editor moves back to the pages module 

Widgetset structure

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.

	Desktop					Tablet		Smartphone
	Modern browsers	IE8	IE9	IE10	IE11	iPad	Android
Magnolia 5.0
Magnolia 5.2
Magnolia 5.2.2							*

* 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

•  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
  

  • https://vaadin.com/wiki/-/wiki/Main/Optimizing%20the%20Widget%20Set

Reworked messaging for unsupported browser page

Sorry.

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

 We do the widgetset-at-bundle-level step

 We also do the renames/reorganizes in the UI

 Speaks for magnolia properties

 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
•  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) ?

Planning

• 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

Goals