[MTE-49] More sophisticated main page template Created: 08/Oct/15  Updated: 26/Feb/16  Resolved: 08/Feb/16

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

Type: Story Priority: Neutral
Reporter: Christopher Zimmermann Assignee: Christoph Meier
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0.5h
Time Spent: 2d 0.5h
Original Estimate: Not Specified

Attachments: HTML File index-mtk-suggestion.html    
Issue Links:
dependency
depends upon MTE-63 Add PageTemplateDefinition to MTE Closed
depends upon MTE-74 Use i18n "best practices" in MTK 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)
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Epic Link: LD: components + pages
Sprint: Basel 30
Story Points: 8

 Description   

Do the following things

  • copy the page template named main from MTE to MTK and name it basic; keep the old one!
  • html kind-of-starting point: see attachment from topher (which is based on https://html5boilerplate.com/)
  • use webresources form 3rd party providers such as cdn or similar to lower maintain efforts

areas to add which (will may have its own area template):

  • htmlHeader ; type: noComponent, createAreaNode: false; code could be a mixture of travel-demo/templates/pages/areas/htmlHeader.ftl and the attachment on this ticket based on html5boilerplate.com/
  • navigation , added file will be +/- empty; type: noComponent, createAreaNode: false
  • main , using "default" template, no file provided
  • footer , using "default" template, no file provided; use inheritance (see /modules/travel-demo/config/travel/templates/prototype/areas/footer/areas/footer1/inheritance)

dialog should be based on / be similar as /mte/dialogs/pages/pageProperties.yaml (actually moving this file to /mtk/dialogs/pages/basic.yaml)

i18n should follow "best practices" since we already have ticket (see MTE-74). However ... to not to "depend" on other tickets, let's start using "old" i18n using the bundle info.magnolia.templating.models.messages to start with and later on refactoring it once MTE-74 is ready.

template definition class: Use info.magnolia.templating.definition.PageTemplateDefinition as soon as MTE-63 has been integrated.



 Comments   
Comment by Christoph Meier [ 01/Feb/16 ]

Note that the one and only page template within whole "MTE" (incl. subreactors) currently is part of mte. I will move it to mtk.

From the above mentioned components which should be included from the main page template "MTE" (both subreactors mte and mtk) does not provide htmlHeader, navigation, footer, main ... so ... basically none of these components are available.
I guess we should create sub tickets for some of these components.

Comment by Christopher Zimmermann [ 01/Feb/16 ]

I would suggest handling the compoents mentioned in this ticket. I think it will be easier to manage - but dev team should make that decision.

I recomment using the main.ftl, and standard.yaml (and the related configuration stored in JCR/prototype!) from the magnolia travel-demo module as a starting point for the page.

Concerning navigation, I would include the area, but not a template, and specify no available components in the page definition.

Comment by Christopher Zimmermann [ 01/Feb/16 ]

Recommend updating html page based on latest https://html5boilerplate.com/
Probably including html5shiv and normalize.css, but it could be argued that we should include nothing.

Comment by Christopher Zimmermann [ 01/Feb/16 ]

Suggestion for page .ftl template based on html5boilerplate. I think we should include the main.css and normalize css as well.

Comment by Philip Mundt [ 01/Feb/16 ]

To be determined: What should the name of that template be? MTE Page?

Comment by Christopher Zimmermann [ 01/Feb/16 ]

For the name, how about basic, simple or standard? I think basic would be appropriate.

Comment by Philip Mundt [ 02/Feb/16 ]
  • create standardComponents.yaml to be included to define the available components for the areas main and footer

I vote against adding this file because

  1. It introduces a new pattern that I think doesn't make much sense.
    1. When using a site definition this file becomes useless (components will be defined on prototype level; components for main area will be specific to each template)
    2. In most cases footer and main-content components differ anyways
    3. When all templates share the same available components, why would you need different templates at all?
      • Looking at previous projects (incl. stk), the thing that was the main characteristic of a template, were its available components
      • Also see the defaults of the prototype
  2. Changing the values in that file will not trigger reloading of the definitions that use it
    1. we have decoration that is coming in the near future making this file somewhat unnecessary
    2. we have a pattern that works much better: YAML's & anchor and * alias – if we really want to keep availability in sync; changing the underlying area def. will immediately be reflected!
  3. Template availability overhaul is in the making
Comment by Christopher Zimmermann [ 02/Feb/16 ]

I think the standardComponents.yaml would be a decent pattern as a straightforward way to add and manage availability of a bunch of components. I would have recommended also including it in the columnLayout component. Project devs could use it include it in their own pages or components that have areas. This is more the point - and its not addressed by YAML's & and *.

I agree that its fairly bogus for the footer - because it is too open - but I dont think its a bad default.
I dont think decoration would "solve" or "replace" this because this is about having a chunk of configuration that you want to re-use in a bunch of places.

It's less relevant with a JCR based site (prototype) - but once site is YAML based I still think its useful for the above reasons. But I like that standardComponents.yaml solution works out of the box without any site configuration.

However, I dont mind if we skip the standardComponents.yaml idea for now if you or someone feels strongly about it.

Comment by Christopher Zimmermann [ 03/Feb/16 ]

Agree to skip the standardComponents.yaml.

Comment by Christoph Meier [ 03/Feb/16 ]

What is the expectation about the styling of this "basic" template, pmundt, czimmermann?
Since it will use info.magnolia.templating.definition.PageTemplateDefinition as its definition class, most of the guys will add css files via definition property cssFiles.
But:
(a) Without any styling, it looks really "basic" .
(b) When i add a "default" css on htmlHeader, people would have to override that file at some point.
Do we agree on (b)?

Comment by Christopher Zimmermann [ 03/Feb/16 ]

Lets go with a) for now. It's closer to the goal. We can add something later if it is too unattractive.

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