Bringing Back the Layout Switcher Feature #205
Replies: 3 comments 3 replies
-
To keep class |
Beta Was this translation helpful? Give feedback.
-
Having automatic custom layout feature is probably a bad idea. It would be better if custom layouts were available as custom fields. But it will probably be available in a separate extension: ---
title: Page Title
description: Page description goes here.
layout: page/index
type: Markdown
...
Lorem ipsum dolor sit amet. Example extension to enable this feature: Hook::set('route', function($content) {
if (is_array($content) && isset($content[0]) && is_string($content[0])) {
$page = $GLOBALS['page'] ?? new Page;
if ($page->exist && $layout = $page->layout) {
$content[0] = $layout;
}
}
return $content;
}, 900); |
Beta Was this translation helpful? Give feedback.
-
The error page layout should not exist as a separate file. This layout can be expressed only in <?= self::enter(); ?>
<?php if ($page->exist): ?>
<article id="page:<?= $page->id; ?>">
<h2>
<?= $page->title; ?>
</h2>
<?= $page->content; ?>
</article>
<?php else: ?>
<article>
<h2>
<?= i('Error'); ?>
</h2>
<p>
<?= i('Page does not exist.'); ?>
</p>
</article>
<?php endif; ?>
<?= self::exit(); ?> <?= self::enter(); ?>
<?php if ($page->exist): ?>
<?php if ($pages->count > 0): ?>
<?php foreach ($pages as $page): ?>
<article id="page:<?= $page->id; ?>">
<h3>
<a href="<?= $page->link ?? $page->url; ?>">
<?= $page->title; ?>
</a>
</h3>
<p>
<?= $page->description; ?>
</p>
</article>
<?php endforeach; ?>
<?php else: ?>
<?php if ($site->has('part')): ?>
<p>
<?= i('No more pages to show.'); ?>
</p>
<?php else: ?>
<p>
<?= i('No pages yet.'); ?>
</p>
<?php endif; ?>
<?php endif; ?>
<?php else: ?>
<article>
<h2>
<?= i('Error'); ?>
</h2>
<p>
<?= i('Page does not exist.'); ?>
</p>
</article>
<?php endif; ?>
<?= self::exit(); ?> |
Beta Was this translation helpful? Give feedback.
-
Why?
After 2 years, 2 months and 28 days have passed since the release of Mecha version 2.2.0, I am having intolerable difficulties regarding synchronization between the local layout file structure and the remote repository associated with that layout. It’s very difficult for me to develop automatic update features on the layout because when the layout has been uploaded, its folder name will disappear and all files in it will merge into one in the
.\lot\layout
folder. Unlike extensions which will be uploaded including the folder, so that the mapping between extension name and remote repository associated with that extension can be retained.Typical Extension File Structure Per v2.6.4
Typical Extension Repository Structure Per v2.6.4
Typical Layout File Structure Per v2.6.4
Typical Layout Repository Structure Per v2.6.4
At first, I tried to make a
git
property proposal inabout.page
file to solve this problem. Hopefully, this can also be applied to third party extensions uploaded outside of https://github.com/mecha-cms organization, so that they can tell panel about their repository name in anabout.page
file’sgit
property to be fetched.This should works fine if the
git
property exists, but gets a bit hacky when I have to guess the repository name by creating a folder name via the layout title. Layout titles should be freely defined and unrelated to the internal structure of the file system. Repository name errors will occur when an uninformed developer decides to change his layout title without changing his remote repository name.Using the
y.
PrefixInstead of using the
layout.
prefix, I’d probably use they.
prefix in the future to accompany the.\lot\x
folder, so we’ll have unique folders named.\lot\x
and.\lot\y
, just like in algebraic mathematics. Here, x will become an abbreviation for extension (noun) and extend (verb), and the.\lot\x
folder will be used to store extensions. And y will become an abbreviation for layout (noun) and yield (verb), and the.\lot\y
folder will be used to store layouts.The Rise of
X
andY
ClassI plan to remove the👎 This feature should be very simple and easy to develop.layout
extension from the core and make it as a built-in non-removable feature instead.Right now, the only idea that comes to my mind is simply to rename
Layout
class toY
, and to add classX
as a companion toY
which is currently useless.Below is an example usage of the
Y
class. Pretty much the same as when usingLayout
class.The only method that can be useful for
X
class is probably justhas
.Advantages?
Disadvantages?
X
.Another
whyway to makeX
andY
classes more viable to exist is to extend them to theState
class. As there’s astate.php
file in the core, and also astate.php
file for each extension and layout folder makes more sense to me.To be continued.
Beta Was this translation helpful? Give feedback.
All reactions