Manager Theme-Engine / API

[Deesen]

As the Bootstrap-theme for manager #672 seems to get more and more serious, I would like to point out again that it would be great having a template-engine that fully separates HTML- from PHP-Code. I don´t think its the perfect solution to hardcode Bootstrap3 into manager. Wouldn ´t it be great to have ModxRE and Bootstrap3-theme available for example? For those who missed it:

http://pm-fx.com/sandbox/evobootstrap/manager/ user: githubviewer password: gview345

I am thinking of a template-override mechanismn similar to Joomla. Means you can overwrite standard .tpl-files shipped with MODX by your own custom files if needed. When a custom theme is active, MODX will first check for .tpl-files in custom-theme directory and if none are found, it falls back using the standard .tpl-file from directory /manager/theme/default/tpl/.

I am brainstorming about the following mechanismn / file-structure :

/manager/theme/default/theme.php /manager/theme/name-of-custom-theme/theme.php

• Base-file with configuration-options to be set by users or admins (example: optional 1 column / 2 columns-layout)
• Configuration-settings are available in every tpl as placeholders like [+config.column1-sm+] [+config.column2-sm+]
• great potential for more custom configurations: Every user could set the width of column 1 and column 2 independently

/manager/theme/default/tpl/tpl.container_1col.html (example for 1 col layout) /manager/theme/default/tpl/tpl.container_2col.html

• default wrapper for displaying content

<div class="container">  
  <div class="row">  
    <div class="col-sm-[+config.column1-sm+]">
      [+column1.content+]
    </div>  
    <div class="col-sm-[+config.column2-sm+]">
      [+column2.content+]
    </div>
  </div>
</div>

/manager/theme/default/tpl/tpl.form_default.html

• default wrapper for displaying forms

<form name="[+name+]" id="[+id+]" class="[+class+]" method="post" enctype="multipart/form-data" action="[+action+]" onsubmit="[+onsubmit+]" [+attributes+]>
  [+wrapper+]
</form>

/manager/theme/default/tpl/tpl.form_input_checkbox.html

• default tpl for input-checkboxes

<div class="checkbox">
    <label>
      <input name="[+name+]" type="checkbox" class="[+class+]" onclick="[+onclick+]" [+attributes+]/> [+label+]
    </label>
  </div>

So theme-developers for example could also create their own tpl.form_input_checkbox.html with additional mark-up to use instead of above default tpl, for example when porting to Bootstrap4 or whatever.

What do other developers think of it? Is it: Future proof, worth the effort, which time-frame is acceptable and how to start, follow up and finish such a project?

BTW: We could also consider about updating the tree, but I´m not sure if it is really worth the effort (keeping it compatible to existing plugins etc) : https://mbraak.github.io/jqTree/ http://daviduv.github.io/jqTreeContextMenu/

[fourroses666]

Yay, its a nice solution for all Evo users, we can all choose our own setup and theme. +1

[bossloper]

Sounds good, though I suppose managermanager plugin would need a major rewrite, and if developers are creating their own templates it could be tricky to keep managermanager working with all custom templates. Managermanager would still be needed because of the dynamic customisations it provides for users/templates etc.

[pmfx]

I like the idea, yet I prefer that we have only one Manager theme in future because it would be more consistent, easy to mantain etc. In my one-theme scenario "Manager Theme-Engine / API" would still be very useful if we ever want to update css framework or move to another. I have no clue how much work will be needed to have it working. If time investment is needed, then maybe it is not worth it .

[Deesen]

In my thinking, the engine/API is responsible to prepare and provide the elements that will be rendered into HTML. So all needed parameters and values would be inside an array first (kind of Typo3ish?). For mutate_content.dynamic.php it would look like (simplified example) :

$apiArray = array(
  'head'=>array(
    'title'=>'Title-Tag Content'
    'script'=>array(
      0=>'window.addEvent('domready', function(){ "mootools-code" };'
      1=>'someOtherCode'
    )
    'scriptSrc'=>array( 0=>"media/scripts/mootools.js")
    ...
  ),
  'body'=>array(
    'class'=>'css-class for body tag'

    // type will be set by managers action,
    // Here content is pure html, maybe as fallback for old tools like YAMS
    'type'=>'html',     
    'content'=>'<p>Final output of action / module etc</p>'

    // OR content is an form-array, like for almost all manager actions
    'type'=>'form',
    'tabs'=>array(
      0=>array(
        'id'=>'general',
        'label'=>'General'
      )
    ),
    'content'=>array(
      0=>array(
        'type'=>'text',
        'name'=>'pagetitle', // can be taken also as CSS-ID
        'value'=>'the documents title',
        'order'=>0,
        'tab'=>'general',
        'class'=>'has-warning',
        ...
      ),
    )
  )
);

So managermanager would have to be rewritten in order to manipulate the content-array instead of the HTML-markup. For example mm_createTab() needs to modify the array like $apiArray['body']['tabs'][] = array('id'=>'new_tab_id','label'=>'new tabs name');

mm_moveFieldsToTab() has to change the array like $apiArray['body'][0]['tab'] = 'target tab-id';

In the end the template-engine will take care of sorting etc and is responsible for rendering this content-array accordingly using default- or a custom-template. As managermanager will only change the array, not custom HTML-markup, every custom theme should always be 100% compatible. At least in my idealistic world ;-).

Also: If we add a new button like "Sort menu index" or other new features say into resource tree, this button is inside an array first, and the engine will render the whole array using the custom theme. Means as soon as new buttons exist, custom themes will display them immediately.

[nick0]

There are some wonderful ideas here to modernise Evo. Its really exciting to see the thought going in to Evo.

I cannot comment on the programming related concepts or much of the above because I am not a programmer and don't understand the ins and outs.

However I love how Evo currently separates formatting from function / content and hope it remains that way.

And I agree with @pmfx in having one kick ass manager theme for simplicity sake. I just want one awesome Evo manager.

I have been using WordPress a bit lately for client projects and I really don't like how different themes / plugins are required to add functionality in the backend to do anything worthwhile.

Having one awesome manager for Evo that does everything we need seems the best approach.

[Deesen]

Maybe I will try a prototype of this template-engine in future for a "proof of concept", until then I close this issue. But I keep dreaming of a manager that is as flexible as the frontend ;-)

[fourroses666]

:(