[MTE-58] Workshop: Review existing MTE components Created: 14/Oct/15  Updated: 17/Oct/16  Resolved: 11/Dec/15

Status: Closed
Project: Magnolia Templating Essentials
Component/s: None
Affects Version/s: None
Fix Version/s: 0.8

Type: Story Priority: Neutral
Reporter: Christopher Zimmermann Assignee: Christopher Zimmermann
Resolution: Done Votes: 0
Labels: workshop
Remaining Estimate: 0d
Time Spent: 3h
Original Estimate: Not Specified

Issue Links:
Relates
relates to MTE-66 Workshop: Frontend Resource Inclusion Closed
relates to MTE-64 Revise existing MTE components Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: Light Development 1.0
Sprint: Basel 22
Story Points: 5

 Description   

Results of the workshop:
https://wiki.magnolia-cms.com/display/PMTEAM/MTE+Components+Workshop+-+2015-12-9

Workshop Goals:
Review existing components, including scripts, models and functions.
Decide on concrete changes to make & a standard "code guide" for all components to follow.

A 1/2 day workshop including people who have had experience working with the components, or have extensive project or STK experience.

As preparation, participants should spend ±1/2 day to re-familiarize themselves with MTE components and create a branch with two components rewritten to the standard they would propose. Ideally textImage and internalTeaser.
(Branch "mte1-[your name]")

Workshop has three parts:
Preparation
2 hour workshop weds morning - to share suggestions & discuss.
1 hour workshop thurs afternoon - to finalize decisions after we had a chance to sleep on it.

Also consider proposal to move MTE templates to new module:
https://wiki.magnolia-cms.com/display/PMTEAM/MTE+Components

Based on the workshop - implement the recommended chages.

Some possible changes / coding guide topics:

  • Moving model logic to templating functions and templates.
  • Improve reusability / genericness - possibly by making more atomic.
  • Recommendations for how to use MTE in projects. (https://wiki.magnolia-cms.com/display/PMTEAM/MTE+In+Projects)
    • How should people customize the template scripts?
  • Approach to i18n.
  • Approach to testing / samples.
  • Using yaml includes.
  • Convention on css classes used.

( Note: How to include css, js, or other resources in MTE for components considered in another workshop: MTE-66)

Workshop goals:

  • Work towards consensus.
  • Document agreements.
  • Document disagreements & remaining questions.
  • Define how to resolve disagreements & remaining questions.
  • Define tickets for execution of work.


 Comments   
Comment by Tomáš Gregovský [ 08/Dec/15 ]

Lets just put my comment before tmr meeting, to save some time I already spend a lot of time thinking about same topic an building something light (everytime needed, but keep it minimal as much possible) for projects I was working on, originally as alternative to heavy, not flexible stk. Something what later changed more to "bootstrap framework" but in point it is still lightweight foundation for building sites on Magnolia. And from description above and looking at others linked docu pages and from discussions I was in so far. Current questions are how far MTE has to go?

For example. to have just components, without at least one page with availability for them is no-go for me. (I don't want to define page template and set availability to all MTE components just to see what they are doing). Then this topic for me continue with many follow-up questions:

  • In case there are 1 or 2 pages template definition in MTE (home, standard?). Then there must be main.ftl, which means some basic set of areas (main, navigation, branding?, footer?, ....) which of them, decision made based on what?
  • Of course they have to has position in main.ftl. so we need to provide some universal page structure (div layout), again, based on what?
  • Once we talking about divs there must be some theme (css, js, etc...). Does this has to be our own theme like stk (speaking about theme only), or reusing any existing framework? (bootstrap, foundation, grid, material, ....)
  • Choosing one we will push away huge group of others so they will hardly reuse MTE
  • BTW choosing twitter bootstrap (most probably), so someone will just re-develop something what already exists for Magnolia? (and do it smaller or bigger compare to it?)
  • When choosing any framework, how will components ftls really looks like? (e.g. for link it will be just <a href='#'>link</a> or <a href='#' class='btn btn-default'>link</a> or <div class='col-xs-12'><a href='#' class='btn btn-primary'>link</a></div> ). I am using bootstrap class name, which will be different for other frameworks, but you probably get it. The thing is if there will be just <a href='#'>link</a> and whole page will consist of components like this, it will be looks ugly and not so many will reuse it. But when starting apply class names how deeply you want to go?
  • and in case of any framework, will we reuse fonts (icons)? js (navigation, carousel, popup effects)? and other stuff which are part of that framework?

These are much more follow up questions which I already went true and is really simply to struggle in question of complexity. And I am worried about to make something universal for everybody is almost impossible these days.

I will just repeat myself, but in case of usability for developers I would much more like to see "basic modules" for today's most used html frameworks (3-5 of them) instead of trying to provide one universal thing for everybody. Any of them can by later extended with "addons module" for more specific components like carousel, social share, etc... (or they can by just downloadable in yaml+ftl zip). And in case any new framework will come in future no matter how crazy he will be we will don't have to look how to extend our universal MTE to support it, but will just provide new basic for it....

Comment by Christopher Zimmermann [ 08/Dec/15 ]

Thanks Tomas.
I can answer a few of your points. (And we can discuss the others tomorrow)
I agree that it would be hard to build a universal MTE template kit that could work in every project. That is not our goal. The MTE should provide instances of the key components that cover the basic functionality of building a web site based on configuration and user input. We work to make them flexible so that they could be an option for a project, or they could provide a good blueprint or starting place. It should be framework independent so that people can see the "pure magnolia & html" combination. I agree that having other framework specific template kits would be great - but I think its important that there is one that is as framework-independent as possible.
I previously envisioned that these framework-specific templating kits would be based on MTE - but now Im not sure if they should or could be.
We should also make clear to developers that its perfectly valid to create their own template kit from scratch. But the MTE still provides a valuable reference - or maybe even starting point for that.
I propose removing the templates from MTE module and putting them in a separate templating kit module. Partly to emphasize this point. This will be available as maven module or light module.

Part of this workshop is not just to refine the existing components - but to create a good convention for how to build components - like a coding guide/style guide that could be reused on other template kits.

Yes we will include page templates. See https://jira.magnolia-cms.com/browse/MTE-49
MTE itself won't include a style. I could see a very simple theme. There will be a few simple css - to support responsive video embed for example.

Regarding css classnames - what about creating a new templateDefinition which is the same as the existing link - but sets a css class parameter, (or using extends when that becomes available)? OK - this does not cover the wrapping div case. Maybe we should add a new parameter - that when present it adds a wrapping div to the component html.
Maybe - as Christian has suggested - we really need to provide a convenient, standard way for providing some custom FTL just for the RENDER part of the template.

Comment by Richard Gange [ 09/Dec/15 ]

Just want to point out I did open this ticket about groovy model support some time ago: MAGNOLIA-6378.

Groovy models work just fine when configured in JCR. It's the YAML based config that's the issue. I have a patch for it. I'm not proud of the patch however

Generated at Mon Feb 12 07:41:03 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.