Post by qahar » Thu Mar 06, 2014 9:06 pm

OpenCart 2 have similiar templating approach with 1.5x, and possibly facing the same issue of developing 3rd extensions and themes.

I have three proposal for OpenCart 2 templating.

1. Clean page template

I'm refering the product.tpl, category.tpl, information.tpl as Page Template.
OpenCart use the Page template to layouting the site, this come to be the main reason of unnecessary template modification for developing themes.

overview of information.tpl

Code: Select all

<?php echo $header; ?>

<div class="container">
    <ul class="breadcrumb"></ul>
    
    <div class="row">
        <?php echo $column_left; ?>
        
        <div id="content">
            <?php echo $content_top; ?>
            
            <!-- Information page -->
            <h1><?php echo $heading_title; ?></h1>
            <?php echo $description; ?>
            <!-- End: Information page -->
            
            <?php echo $content_bottom; ?>
        </div><!-- End: #content -->
        
        <?php echo $column_right; ?>
    </div> <!-- End: .row -->
    
</div> <!-- End: .container -->

<?php echo $footer; ?>
Screenshoot to visualize code above:
opencart-default-templating.jpg

opencart-default-templating.jpg (91.26 KiB) Viewed 5870 times

At image above (and for next refference):
  • Box with blue background is code at header.tpl
  • Green background is page template (I use information.tpl)
  • Orange is code at footer.tpl
My proposal is to make the Page template clean and move all other html layout to header and footer.

header.tpl

Code: Select all

<html>
<head></head>
<body>
    <nav id="top"></nav>
    
    <header></header>
    
    <nav id="menu"></nav>
    
    <div class="container">
        <ul class="breadcrumb"></ul>

        <div class="row">
            <?php echo $column_left; ?>
            
            <div id="content">
                <?php echo $content_top; ?>
information.tpl

Code: Select all

<?php echo $header; ?> <!-- echo code above -->

    <!-- Information page -->
    <h1><?php echo $heading_title; ?></h1>
    <?php echo $description; ?>
    <!-- End: Information page -->

<?php echo $footer; ?> <!-- echo code below -->
footer.tpl

Code: Select all

                <?php echo $content_bottom; ?>
            </div><!-- End: #content -->
            
            <?php echo $column_right; ?>
        </div> <!-- End: .row -->
        
    </div> <!-- End: .container -->
    <footer></footer>
</body>
</html>
Refer to image below, page template (green) only contain it's own content.
Html layout and positions is loaded by header.tpl (blue) and footer.tpl (orange).
opencart-new-templating-workaround.jpg

opencart-new-templating-workaround.jpg (106.61 KiB) Viewed 5870 times

This will minimise html layout issue of 3rd extensions and themes.
And also reducing unnecessary modificate OpenCart template to develope themes.
And of course, OpenCart will more easy to maintain.

I manage to make quick change to show how it work. You can see it here.

Pull request status: rejected

2. Clean Module template

The second proposal is based on Q idea.

Module only contain it's content.
Html layout related to visual theming handled by Position template (column_right.tpl, content_top.tpl etc)
opencart-new-templating-module.jpg

opencart-new-templating-module.jpg (66.98 KiB) Viewed 5870 times

My module/welcome.tpl code is only <?php echo $message; ?>, the module box is handled by column_right.tpl below

Code: Select all

<?php foreach ($modules as $module) { ?>
    <?php if ($module['title']) { ?>

        <!-- welcome module at image above -->
        
        <div class="panel panel-default">
            <div class="panel-heading">
                <h3 class="panel-title"><?php echo $module['title']; ?></h3>
            </div>
            <div class="panel-body <?php echo $module['class']; ?>">
                <?php echo $module['content']; ?>
            </div>
        </div>
    <?php } else { ?>

        <!-- category module at image above -->
        
        <?php echo $module['content']; ?>
    <?php } ?>
<?php } ?>
My modification to test this.

Pull request status: I'm canceling this part coz the first proposal is rejected


3. Dynamically add Position

OpenCart have 4 controller and template file for position (column_right, content_top etc) and all of them have code pattern.

To make it easy to add and manage Position, we need general Position handler.

position.php

Code: Select all

 // Example
class ControllerCommonPosition extends Controller {
    public function index($setting) {
    
        foreach ($extensions as $extension) {
            if ($module['position'] == $setting['position']) {
                // array $module_data
            }
        }
        
        if (!isset($setting['template'])) {
            $setting['template'] = $setting['position'];
        }
        
        return $this->load->view($setting['template'], $data);
    }
}
Usage on header.php

Code: Select all

// Current position
$data['column_left']    = $this->load->controller('common/position', array('position' => 'column_left'));

// 2 new position with 1 template
$data['content_top_a']    = $this->load->controller('common/position', array('position' => 'content_top_a', 'template' => 'position_a_b'));
$data['content_top_b']    = $this->load->controller('common/position', array('position' => 'content_top_b', 'template' => 'position_a_b'));
For theme developer this will increasing possibility to add more module positions.
Even if themes have different amount of positions or may be up to 21 positions, extensions developer only need to modificate one position.php to make their ext work seamless with OpenCart "layout override" concept.

But of course it is required to "read" theme position and show them in modules based on active theme.

I'm not test this yet, but I think it's possible with current WIP (work in progress) of OpenCart 2 to read install.xml during installation and save some data to database.
Then load theme position from database to admin module.

Screenshoot when we add a module to content_top_a position
opencart-new-templating-position-1.jpg

opencart-new-templating-position-1.jpg (56.64 KiB) Viewed 5870 times

Screenshoot when we add a module to content_top_a and content_top_b
opencart-new-templating-position-2.jpg

opencart-new-templating-position-2.jpg (59.12 KiB) Viewed 5870 times

1 module at content_top_a and 2 module at content_top_b
opencart-new-templating-position-3.jpg

opencart-new-templating-position-3.jpg (57.03 KiB) Viewed 5870 times

My modification to test this feature.


This proposal based on quick modification to see the result, when it comes to prepare them to OpenCart 2 core I'm sure more test is required.

If you have any feedback feel free to share, I plan to start working on first proposal next week and Pull Request to OpenCart repo.
I hope we can see this proposal come true in OpenCart 2
Last edited by qahar on Fri Mar 21, 2014 9:23 pm, edited 1 time in total.
Reason: add pull request status at 1st proposal

User avatar
Expert Member

Posts

Joined
Tue Jun 29, 2010 10:24 pm
Location - Indonesia

Post by rph » Tue Mar 11, 2014 12:19 pm

Very interesting work qahar. I've been playing around with modifying the theming system and it's a surprisingly difficult balance to strike. I can definitely see wanting to get rid of a lot of the redundancy but the flip side here is that the templates are being tightly coupled together.

-Ryan


rph
Expert Member

Posts

Joined
Fri Jan 08, 2010 5:05 am
Location - Lincoln, Nebraska

Post by JNeuhoff » Thu Mar 13, 2014 2:51 am

While this proposal may offer some improvements, it doesn't consider the fact that different 3rd party extensions (such as from VQMod XML scripts, or template modification via the Override Engine) may want to modify the same core template file. This could be made easier if each template file contained clean XHTML5 code. Therefore it lends itself to the usage of e.g. a common.tpl, to be used by every page, with something like this:

Code: Select all

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html dir="<?php echo $direction; ?>" lang="<?php echo $lang; ?>" xmlns="http://www.w3.org/1999/xhtml">
	<header>
		<title><?php echo $title; ?></title>
		<!-- ..... -->
	</header>
	<body>
		<?php echo $header; ?> <!-- breadcrumbs, menu, language and language selectors etc -->
		<?php echo $column_left; ?>
		<?php echo $content; ?>
		<?php echo $column_right; ?>
		<?php echo $footer; ?>
	</body>
</html>
If each of the $header, $column_left, $content, $column_right, $footer etc contains clean HTML5 code, then extensions could use an XML or DOM parser to add, modify or delete nodes as needed by the extension. Better than search/replace operations on HTML source codes!

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by qahar » Fri Mar 14, 2014 5:11 am

@JNeuhoff
This is mere proposal for templating, I still consider extending OpenCart is a bit problematic solution.
As for me, I prefer hook/ plugin mechanism instead of modification or override.

Hook only allow developer to extend OpenCart on predefined track.
We only able to extend what is allowed by OpenCart: before url alias, after url alias, before load controller, after load controller, before render, after render etc.

Some people may think this is a limitation, but for me that is the advantage because it will reducing lot of system change by 3rd developer. It might limiting creativity, but better to solve the issue rather than solving the consequence.

User only think this is OpenCart system and should work as OpenCart logic, but sometime and in some case it's not.
In experience of supporting client, we used to spend lot of time to learn system change by 3rd developer extension and theme (or mix of them). This is lot of effort that we can't avoid for now, because either modification or override is common method to extend OpenCart right now. Still far from ideal but OpenCart is still evolving.

User avatar
Expert Member

Posts

Joined
Tue Jun 29, 2010 10:24 pm
Location - Indonesia

Post by OSWorX » Fri Mar 14, 2014 5:46 am

+1 hook/ plugin mechanism

Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.


User avatar
Administrator

Posts

Joined
Mon Jan 11, 2010 10:52 pm
Location - Austria

Post by JNeuhoff » Fri Mar 14, 2014 6:33 pm

OK, come up with a list of meaningful hooks. My fear is it will be very long, though I do see some advantages with a hooks / plugin mechanism when properly used.

None of it touches the problem with templates though: There will still be a need for 3rd party extensions (which are unaware of each other) to modify some TPL files, e.g. add or remove form fields, or other HTML tags. Hence my conclusion that, if we used clean HTML5 which follows the strictness of XML for each of the TPL files, a 3rd party extension could easily parse them and then add/modify/delete nodes as needed before the final rendering.

Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig


User avatar
Guru Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by qahar » Sat Mar 15, 2014 5:37 pm

Wordpress have more than thousand hooks now, but when the first time hook introduced nine years ago they only have 39 hooks.

I found tutorials where we can use wp hooks or joomla plugin (with xml config) to add extra field, but not to alter existing field. My assumption is, instead of alter existing function, they might prefered to build new extensions to fulfill requirement.

I think this is one of hooks/ plugin limitation ;D

User avatar
Expert Member

Posts

Joined
Tue Jun 29, 2010 10:24 pm
Location - Indonesia
Who is online

Users browsing this forum: No registered users and 10 guests