Wiki source code of Application Independence
Last modified by Vincent Massol on 2024/11/19 16:13
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | == Related Proposals == | ||
| 2 | |||
| 3 | * [[Color Theme Feature for Flamingo>>Proposal.ColorThemeforFlamingo]] | ||
| 4 | |||
| 5 | == Problems == | ||
| 6 | |||
| 7 | XWiki is focused more and more on the concept of applications, but in the same time these applications need to adapt on the skin and version where they are installed. | ||
| 8 | A solution (A) would be to specify very clearly for an application for which version and what skin it was created, while another solution (B) would be to try to let the applications be used across versions and across skins. | ||
| 9 | |||
| 10 | In the 6.0 roadmap, one of the objectives was to provide new designs (based on a new skin Flamingo) for older/existing applications that were creating on a different skin (the old Colibri skin or even on custom users skins). | ||
| 11 | |||
| 12 | While an approach (I) for this problem would be to provide a generic layout for the application across skins, another approach (II) would be to try to adapt the application depending on the skin's standards, providing a custom layout depending on the application's purpose. | ||
| 13 | Examples: | ||
| 14 | |||
| 15 | |((( | ||
| 16 | * (I) we could decide that all application entries are displayed vertically and there is no specific skin layout defined, example | ||
| 17 | [[[[image:[email protected]||width="45%"]]>>attach:[email protected]]] | ||
| 18 | )))|((( | ||
| 19 | * (II) we could provide a custom layout depending on the purpose and prioritisation of the fields, example | ||
| 20 | [[[[image:taskedit.jpg||width="45%"]]>>attach:taskedit.jpg]] | ||
| 21 | )))| | ||
| 22 | |||
| 23 | Some layouts are easier to adapts than others. For example: | ||
| 24 | |||
| 25 | |((( | ||
| 26 | * Flamingo Calendar: | ||
| 27 | [[[[image:[email protected]||width="45%"]]>>attach:[email protected]]] | ||
| 28 | )))|((( | ||
| 29 | * Colibri Calendar: | ||
| 30 | [[[[image:[email protected]||width="45%"]]>>attach:[email protected]]] | ||
| 31 | )))| | ||
| 32 | |||
| 33 | This layout uses a combination of Var 3 (standard for headings, panels, etc.) and Var 4 (uses Bootstrap and Colibri specific classes). | ||
| 34 | |||
| 35 | {{code}} | ||
| 36 | <div class="btn-group buttonwrapper"> | ||
| 37 | <a class="btn btn-success btn-small button" href="#"><i class="icon-plus"></i> Add event</a> | ||
| 38 | </div> | ||
| 39 | {{/code}} | ||
| 40 | |||
| 41 | But the above layout is not very complex and the differences between the skins are not noticeable. | ||
| 42 | |||
| 43 | A more detailed example is: | ||
| 44 | |||
| 45 | |((( | ||
| 46 | [[[[image:taskedit.jpg||width="45%"]]>>attach:taskedit.jpg]] | ||
| 47 | )))| | | ||
| 48 | |||
| 49 | Some problems with the above layout: | ||
| 50 | |||
| 51 | * Colibri doesn't have a complex grid system; | ||
| 52 | * Colibri doesn't have a font-icon and standard icon classes; | ||
| 53 | |||
| 54 | For the above case, which version is the best? Var 1? Var 2? Var 3? Var 4? Var 5? | ||
| 55 | |||
| 56 | == Solutions == | ||
| 57 | |||
| 58 | |||
| 59 | |||
| 60 | One of the big criteria in defining a successful platform and applications suite is their **presentation independence**. This means that no matter of your personal preferences for the platform, if you install an application it should adapt to the environment. | ||
| 61 | |||
| 62 | This brainstorm is needed in order to determine how/if we can create "presentation independent" XWiki application. | ||
| 63 | |||
| 64 | == Variants == | ||
| 65 | |||
| 66 | It depends very much on the content and complexity of the application and regarding the context there could be multiple variants. Still we should have a common position on which variant is ideal and has priority when selecting a solution. | ||
| 67 | |||
| 68 | {{toc start="3"/}} | ||
| 69 | |||
| 70 | === Var 1: Creating different applications per skin === | ||
| 71 | |||
| 72 | If the application content is complex and the skins are very different we could provide different applications/skin. | ||
| 73 | |||
| 74 | Cons: | ||
| 75 | |||
| 76 | * This model is hard to manage since the functionality is branching and usually is hard to simultaneous maintain two different implementation of the same application. | ||
| 77 | |||
| 78 | Might be considered: | ||
| 79 | |||
| 80 | * If the new skin has totally different patterns from the old one (like different ways to add information ex. modals, different layout order, different icon sets, etc.) it might be a solution to create a totally new application instead of trying to adapt the old one. Example: [[Flamingo ColorThemes>>Proposal.ColorThemeforFlamingo]] | ||
| 81 | |||
| 82 | === Var 2: Creating custom presentation per skin === | ||
| 83 | |||
| 84 | This solution was also [[discussed>>http://markmail.org/thread/vwl2m4dt5ykeypmr]] but in the context of uicomponents. | ||
| 85 | |||
| 86 | ==== Var 2.1: Stylesheet / Skin ==== | ||
| 87 | |||
| 88 | Make some checks for the current skin and provide a different stylesheet; | ||
| 89 | |||
| 90 | ==== Var 2.2: Selectors / Skin ==== | ||
| 91 | |||
| 92 | Have custom styles for the skins, like '##.skin-flamingo .xform##'; | ||
| 93 | |||
| 94 | === Var 3: Create a standard that both skins will use === | ||
| 95 | |||
| 96 | Cons: | ||
| 97 | |||
| 98 | * Depending on the new skin's requirements, there might be some additions needed by the old skin. Modifying the old/existing skin means introducing backwards compatibility problems for the users of the old skin. Instead of branching the application, the old skin is branched. Example: [[ColorThemes version 3.4 changes>>Improvements.34Proposal]] | ||
| 99 | * The standard is somehow limited to a specific period of time when it was created. If we need to make additions, any skin implementing the standard needs to be updated too. | ||
| 100 | |||
| 101 | Might be considered: | ||
| 102 | |||
| 103 | * If the standard is strong and generic, there is no problem for any new skin to use the standard/api classes and just change the presentation for them. | ||
| 104 | For example, class '##xform##' should be used by both skins since its purpose is to handle forms, while the skin decide how labels are displayed, etc. | ||
| 105 | This means the application is using the '##xform##' class inside its structure, while all the skins are providing a style for it ##.xform##, ex. "class='xform'" | ||
| 106 | |||
| 107 | === Var 4: Use both/all skin specific classes === | ||
| 108 | |||
| 109 | If we want an application to adapt to a certain skin, just make sure it uses the skin specific classes. Example: if we want a container to be displayed on grid, we would need to add the Flamingo specific grid classes (taken form Bootstrap) '##.col-md-4##' and Colibri specific classes '##.third##', ex. "##class='col-md-4 third'##" | ||
| 110 | |||
| 111 | Cons: | ||
| 112 | |||
| 113 | * The developer needs to know what are the supported skins and their way or organising/displaying presentation. It is not scalable. | ||
| 114 | * Some skins might not have the exact functionality as another, thus missing some classes. For example, Colibri doesn't has a grid system and provides just a limited number or columns (##.full##, ##.half##, ##.third##). In this case the developer needs to provides a backup / addition styling for the missing presentation. | ||
| 115 | |||
| 116 | === Var 5: Make the application stand-alone and not adaptable per skin === | ||
| 117 | |||
| 118 | The application will not adapt depending on the skin and all the presentation needed to display it will be incapsulated inside it. | ||
| 119 | |||
| 120 | Cons: | ||
| 121 | |||
| 122 | * Duplication of code: for example if an application is using Bootstrap classes and not fallbacks on the skin, this means it should provide it's own Bootstrap packing, posing problems when wanting to upgrade to a new dependency version. |
