Post by daniel2008 » Wed Jul 17, 2013 8:31 pm

Hi intersect,

Yes, you're right on choosing a prefect or well-coded theme to fit every sides of a website.
In that case can you or anyone suggest some themes near 'well-coded' for me?
Thanks again,

Daniel

http://www.smartebuy.com.au/ http://www.myleathers.com.au/ http://www.cctv4oz.com.au/ http://www.origreen.com.au/


Active Member

Posts

Joined
Wed Jul 07, 2010 8:54 pm


Post by lvcoded » Mon Sep 09, 2013 5:40 pm

Hi everyone,

It's been a while, but somebody pointed me to this long overdue discussion between Opencart and theme developers. I thought I should share my opinion too..

We used to run an Opencart theme shop called Themedisk. All our themes were coded from scratch, because the HTML used on the default theme was simply not good enough. It did not validate, it was full of tables, and other HTML elements used incorrectly. The obvious option was to redo the HTML completely. Now I know it was naive to hope we can keep updating all our custom themes every time a new Opencart version is released, so after a year or 2 we had to close Themedisk down. It wasn't just because of our custom HTML. It was also because every new Opencart release had its HTML changed a lot and we would have had to update all our themes constantly anyways, and the fact we were getting half finished updates and therefore loads of them didn't help either.

I am happy to see something is finally being done about this, and I really hope the front end of Opencart finally gets sorted and everyone can stick to the default HTML. It will make everyone's lives much easier, especially theme developers. I can see the front end is already looking much more up to date, and mostly is valid HTML, but I am sure the structure of CSS/HTML can still be improved. Also, the default theme should be responsive by now..

Kind Regards,
Igo

User avatar
New member

Posts

Joined
Wed Apr 27, 2011 4:24 am

Post by intersect » Thu Sep 12, 2013 12:25 am

lvcoded wrote: I am happy to see something is finally being done about this, and I really hope the front end of Opencart finally gets sorted and everyone can stick to the default HTML. It will make everyone's lives much easier, especially theme developers. I can see the front end is already looking much more up to date, and mostly is valid HTML, but I am sure the structure of CSS/HTML can still be improved. Also, the default theme should be responsive by now..
To everyone stick to the default HTML makes no sense at all. There're a lot of situations that you got to change the outputted HTML.
The main problem - that remains unsolved even in the 2.0 version - in my opinion is this fragile, laborious and inflexible templating system. It's not the devs faults or the designers fault, but it's the system fault's.
In Joomla, wordpress and other CMS's you can change everything in the theme/template and there aren't any problem with any extension. I know they are completely different systems, but no system should have this kind of problem where a template/theme brings problems to any extensions.
Unfortunately this not only won't be solved with the 2.0 version but will get a lot worse with the use of bootstrap. Devs will rely even more in the HTML and anyone who doesn't stick to bootstrap (like me) will have a lot of issues with a lot of extensions because the HTML is different from the default.
OC is a great system, but has a really troublesome theming system.

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by Qphoria » Thu Sep 12, 2013 1:38 am

I know Joomla has the older "layout" style which I liked in OpenCart. But I also see benefit to the current way.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by intersect » Thu Sep 12, 2013 3:39 am

If opencart had a theme system like Joomla, it'd be heaven. It's just too painful to make a theme in opencart...
The Joomla's theme system is simple, direct and extreme powerful. The overriding system is just awesome (mainly the modules and components overrides) and the theme can be just as simple or as complex as you need.

This should be the way to go (and of course, iron out any framework dependencies that make the life of a lot of people harder).

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by JNeuhoff » Thu Sep 12, 2013 4:17 am

Qphoria wrote:Yea I'd love to see something like the Joomla theme system in opencart.
Curious: Could you briefly explain how the Joomla theme system works, and why it is supposed to be better than Opencart's theme engine?

MHC Web Design
Override Engine * Integrated VQMod * Multilingual SEO * Instant Option Price Calculator * TrustPilot Reviews * Download Options * Google Rich Snippets * Export/Import Tool * Template Switcher PHP/Twig


User avatar
Expert Member

Posts

Joined
Wed Dec 05, 2007 3:38 am


Post by rph » Thu Sep 12, 2013 9:07 am

I'd be interested also. I've been doing a lot of research on template and modding systems lately.

OpenCart itself seems weighted much more for designers than developers. A designer only needs to know some very simple PHP and they can do just about whatever they want. Developers who want to easily override/add template elements are out of luck.

I looked a little through Joomla 3.1. I believe it's supposed to be MVC but the separation between controller and view isn't very strict. There's a good amount of HTML in the controller files and a designer is going to have to be competent with both PHP and OOP to theme.

-Ryan


rph
Expert Member

Posts

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

Post by intersect » Thu Sep 12, 2013 9:15 pm

rph wrote:I'd be interested also. I've been doing a lot of research on template and modding systems lately.

OpenCart itself seems weighted much more for designers than developers. A designer only needs to know some very simple PHP and they can do just about whatever they want. Developers who want to easily override/add template elements are out of luck.

I looked a little through Joomla 3.1. I believe it's supposed to be MVC but the separation between controller and view isn't very strict. There's a good amount of HTML in the controller files and a designer is going to have to be competent with both PHP and OOP to theme.
No way opencart is better to designers. It's a bloody amount of work to get a full theme developed. And to make things worse, any HTML we change can affect an extension or mod.

Of course a designer just need basic PHP, it should be this way. PHP is not a front-end language so this should not be required to know it to get a theme developed.

I'm no developer but I can say that develop a template for Joomla is just easier and more consistent than in opencart. You don't need to know a penny about PHP to make a template. Good old HTML is what it takes, unless you want something more.

I usually make a whole template in Joomla in one or two days, but in Opencart it takes 1 or 2 weeks. How can this be good for a designer?

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by Qphoria » Thu Sep 12, 2013 11:25 pm

I don't know much about Joomla but what I've read on their wiki about how to create a theme. Basically its more like the OLD opencart 1.3.x where there is one main "layout" file that has all the pieces on one page. So you can easily shift things around.

Code: Select all

<html>
<body>
<div class="header">
<?php echo getHeader(); ?>
</div>

<div class="main">
<?php echo getMain(); ?>
</div>

<div class="sidebox">
<?php echo getSideModules(); ?>
</div>

<div class="footer">
<?php echo getFooter(); ?>
</div>
</body>
</html>
Now I don't know for sure how the individual modules hold code.

One thing that annoys me with opencart modules is that overall "box wrapper" html is inside EACH module tpl file. Instead the module should only hold the html that is specific to the module itself. The theme itself should maintain the "wrapper" code so that all modules match with the current theme. The way it is now, if I using the default "box" wrapper in my module tpl file, and another theme uses a completely different box design, it doesn't match.

So the column_right.tpl file should be specific to the theme and instead of this:

Code: Select all

<?php if ($modules) { ?>
<div id="column-right">
  <?php foreach ($modules as $module) { ?>
  <?php echo $module; ?>
  <?php } ?>
</div>
<?php } ?>
It should have the wrapper like this:

Code: Select all

<?php if ($modules) { ?>
<div id="column-right">
  <?php foreach ($modules as $module) { ?>
  <div class="box">
  <div class="box-heading"><?php echo $heading_title; ?></div>
  <div class="box-content">
  <?php echo $module; ?>
  </div>
  </div>
  <?php } ?>
</div>
<?php } ?>
and the actual module tpl should only have the "guts"

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by rph » Fri Sep 13, 2013 12:55 am

intersect wrote:No way opencart is better to designers. It's a bloody amount of work to get a full theme developed.
Perhaps flexible is a better term. Plus a huge amount can be achieved through CSS changes.
Of course a designer just need basic PHP, it should be this way. PHP is not a front-end language so this should not be required to know it to get a theme developed.
PHP's templating lineage is still very much there. But my point is that Joomla seems to require you not only know more PHP, it requires you to know object-oriented programming too.

I might be looking in the wrong spot but the files in /templates/[TEMPLATE]/html/ are a heavy mixture of PHP and HTML, including stuff like instantiating objects in the HTML block and a lot of controller-like functionality at the head of the file. I know how designers complain about simple echo statements so I can't imagine areas like this:

Code: Select all

<p class="readmore">
    <a href="<?php echo $link; ?>">
        <?php if (!$params->get('access-view')) :
            echo JText::_('COM_CONTENT_REGISTER_TO_READ_MORE');
        elseif ($readmore = $this->item->alternative_readmore) :
            echo $readmore;
            if ($params->get('show_readmore_title', 0) != 0) :
                echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit'));
            endif;
        elseif ($params->get('show_readmore_title', 0) == 0) :
            echo JText::sprintf('COM_CONTENT_READ_MORE_TITLE');
        else :
            echo JText::_('COM_CONTENT_READ_MORE');
            echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit'));
        endif; ?></a>
</p>
are particularly comprehensible.

-Ryan


rph
Expert Member

Posts

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

Post by rph » Fri Sep 13, 2013 1:22 am

Qphoria wrote:One thing that annoys me with opencart modules is that overall "box wrapper" html is inside EACH module tpl file.
Two advantages I see are that it makes it easier to look for errors if HTML for a single element isn't split up in multiple locations plus it allows more flexibility for module developers. An idea I really like is having required id/classes in themes like "oc_box". That way a developer knows they'll be using the same style while allowing for their own customization.

-Ryan


rph
Expert Member

Posts

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

Post by intersect » Fri Sep 13, 2013 1:50 am

rph wrote: Perhaps flexible is a better term. Plus a huge amount can be achieved through CSS changes.
Oc's templating is not flexible, believe me. CSS has its limits, there're just a certain amount of modification that you can do without have to resort to hacks, which is a really bad idea. Also, if you try to modify just the CSS you'll not get to use something like inuit.css or even some jQuery plugins. The HTML got be flexible.
rph wrote: PHP's templating lineage is still very much there. But my point is that Joomla seems to require you not only know more PHP, it requires you to know object-oriented programming too.

I might be looking in the wrong spot but the files in /templates/[TEMPLATE]/html/ are a heavy mixture of PHP and HTML, including stuff like instantiating objects in the HTML block and a lot of controller-like functionality at the head of the file. I know how designers complain about simple echo statements so I can't imagine areas like this:

Code: Select all

<p class="readmore">
    <a href="<?php echo $link; ?>">
        <?php if (!$params->get('access-view')) :
            echo JText::_('COM_CONTENT_REGISTER_TO_READ_MORE');
        elseif ($readmore = $this->item->alternative_readmore) :
            echo $readmore;
            if ($params->get('show_readmore_title', 0) != 0) :
                echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit'));
            endif;
        elseif ($params->get('show_readmore_title', 0) == 0) :
            echo JText::sprintf('COM_CONTENT_READ_MORE_TITLE');
        else :
            echo JText::_('COM_CONTENT_READ_MORE');
            echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit'));
        endif; ?></a>
</p>
are particularly comprehensible.
The HTML folder keeps the overrides for the template, it's optional and you'll just need something as complex as this if you're changing something like a behavior of the system. 98% of the cases you won't need nothing more complex than

Code: Select all

<?php if($this->countModules('any-module-position')) : ?>
Do whatever you need
<?php endif; ?>
The template itself just need the index.php and nothing more. You can extend as you need, but usually it's very simple.
Here the whole code of a template I've done in Joomla:

Code: Select all

<?php
/**
 * @copyright   Copyright (C) 2013 Intersect. All rights reserved.
 */

defined('_JEXEC') or die;


$app = JFactory::getApplication();
$doc = JFactory::getDocument();
$this->language = $doc->language;
$this->direction = $doc->direction;

// Unset Unused Scripts
unset($this->_scripts['components/com_k2/js/k2.js?v2.6.6&sitepath=/
  ']);
// Add Stylesheets
$doc->addStyleSheet('templates/'.$this->template.'/stylesheet/style.css');
// Add Scripts
$doc->addScript('templates/' . $this->template . '/javascript/custom.modernizr.js', 'text/javascript');
?>

<!DOCTYPE html>

<!--[if lt IE 7]> <html class="no-js lt-ie9 lt-ie8 lt-ie7" dir="<?php echo $this->direction; ?>" lang="<?php echo $this->language; ?>"> <![endif]-->
<!--[if IE 7]>    <html class="no-js lt-ie9 lt-ie8" dir="<?php echo $this->direction; ?>" lang="<?php echo $this->language; ?>"> <![endif]-->
<!--[if IE 8]>    <html class="no-js lt-ie9" dir="<?php echo $this->direction; ?>" lang="<?php echo $this->language; ?>"><![endif]-->
<!--[if gt IE 8]><!--> <html class="no-js" dir="<?php echo $this->direction; ?>" lang="<?php echo $this->language; ?>"> <!--<![endif]-->

<head>
  <meta name="viewport" content="width=device-width,initial-scale=1" />

  <jdoc:include type="head" />

</head>

<body>
  <!-- Header -->
  <header>
    <div class="row">
       <div class="small-9 large-4 columns">
          <!-- Logo -->
          <div id="logo">
            <a href="<?php echo $this->baseurl ?>" id="taximud" title="TaxiMud do Brasil">TaxiMud do Brasil</a>
          </div>
       </div>
       <div class="small-3 large-8 columns">
        <!-- Menu -->
        <div class="menu-container">
          <div class="menu-icon"><a href="#"><i class="icon-menu"></i></a></div>
          <nav>
           <jdoc:include type="modules" name="menu" style="none" />
           <ul id="search">
            <li class="heading-flyout"><a href="#"><i class="icon-search"></i></a>
              <div class="content-flyout"><jdoc:include type="modules" name="search" style="none" /></div>
            </li>
           </ul>
          </nav>
        </div>
       </div>
    </div>
  </header>
  <!-- End Header -->

  <div class="message" id="message">
    <jdoc:include type="message" />
  </div>

  <?php if($this->countModules('tools')) : ?>
  <div id="tools">
    <jdoc:include type="modules" name="tools" style="well" />
    <div class="tool-icon">
      <a href="#" class="close-tools" title="Ferramentas"><i class="icon-menu"></i></a>
    </div>
  </div>
  <?php endif; ?>
   
  <?php if($this->countModules('slideshow')) : ?>
  <!-- Slideshow -->
  <aside id="slideshow">
    <jdoc:include type="modules" name="slideshow" style="well" />
  </aside>
  <!-- End Slideshow -->
  <?php endif; ?>
  
  <?php if($this->countModules('highlight')) : ?>
  <!-- Highlight -->
  <div class="row" id="highlight">
    <div class="small-12 large-12 columns">
      <article>
        <jdoc:include type="modules" name="highlight" style="none" />
      </article>
    </div>
  </div>
  <!-- End Highlight -->
  <?php endif; ?>


   <!-- Content -->  
   <div class="row">
    <div class="small-12 large-12 columns">
      <section class="content">
        <jdoc:include type="component" />
      </section>
    </div>
   </div>
   <!-- End Content -->

   <?php if($this->countModules('clients')) : ?>
   <!-- Bottom Modules -->
   <section>
      <div class="row" id="clients">
         <div class="small-12 large-12 columns">
            <jdoc:include type="modules" name="clients" style="well" />
         </div>
      </div>
   </section>
   <!-- End Bottom Modules -->
   <?php endif; ?>

  <?php if($this->countModules('news')) : ?>
   <!-- Bottom Modules -->
   <section>
      <div class="row" id="news">
         <div class="small-12 large-12 columns">
            <jdoc:include type="modules" name="news" style="well" />
         </div>
      </div>
   </section>
   <!-- End Bottom Modules -->
   <?php endif; ?>

  <!-- Footer -->
  <footer>
    <div class="row">
      <div class="small-12 large-4 columns" id="footer1">
        <jdoc:include type="modules" name="footer1" style="well" />
      </div>
      <div class="small-12 large-4 columns" id="footer2">
        <jdoc:include type="modules" name="footer2" style="well" />
      </div>
      <div class="small-12 large-4 columns" id="footer3">
        <jdoc:include type="modules" name="footer3" style="well" />
      </div>
    </div>
    <!-- Login Button -->
    <div id="login-button">
      <a href="index.php/login" title="Login"><i class="icon-user"></i></a>
    </div>
    <!-- End Login Button -->
  </footer>
  <!-- End Footer -->

  <jdoc:include type="modules" name="debug" style="none" />
  <script src="/taximud/templates/taximud/javascript/jquery-1.9.1.min.js"></script>

</body>
</html>
See? It's a bit complex page, but all the code I needed was this and some overridings for some modules, but that's all (besides the CSS, of course).

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by Qphoria » Fri Sep 13, 2013 3:14 am

rph wrote: I know how designers complain about simple echo statements so I can't imagine areas like this:

Code: Select all

<p class="readmore">
    <a href="<?php echo $link; ?>">
        <?php if (!$params->get('access-view')) :
            echo JText::_('COM_CONTENT_REGISTER_TO_READ_MORE');
        elseif ($readmore = $this->item->alternative_readmore) :
            echo $readmore;
            if ($params->get('show_readmore_title', 0) != 0) :
                echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit'));
            endif;
        elseif ($params->get('show_readmore_title', 0) == 0) :
            echo JText::sprintf('COM_CONTENT_READ_MORE_TITLE');
        else :
            echo JText::_('COM_CONTENT_READ_MORE');
            echo JHtml::_('string.truncate', ($this->item->title), $params->get('readmore_limit'));
        endif; ?></a>
</p>
are particularly comprehensible.
You make a good point.. I hadn't dug that far to realize there was a deeper structure.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by rph » Fri Sep 13, 2013 3:34 am

intersect wrote:Oc's templating is not flexible, believe me.
We'll just have to agree to disagree. Having so much of the view locked in the controller is limiting to me. (Commingling of controller elements in the template isn't ideal either.) I'd also add the large variety of OpenCart themes at themeforest.net shows significant versatility in what can be achieved.
Here the whole code of a template I've done in Joomla
The main template is very nice but it still requires solid PHP and OOP knowledge so I'm not sure why you'd disagree there. It's dangerous inserting code you don't understand. The simple areas doesn't change the fact there are highly complex ones, too.

-Ryan


rph
Expert Member

Posts

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

Post by intersect » Sat Sep 14, 2013 9:31 pm

rph wrote:
intersect wrote:Oc's templating is not flexible, believe me.
We'll just have to agree to disagree. Having so much of the view locked in the controller is limiting to me. (Commingling of controller elements in the template isn't ideal either.) I'd also add the large variety of OpenCart themes at themeforest.net shows significant versatility in what can be achieved.
Here the whole code of a template I've done in Joomla
The main template is very nice but it still requires solid PHP and OOP knowledge so I'm not sure why you'd disagree there. It's dangerous inserting code you don't understand. The simple areas doesn't change the fact there are highly complex ones, too.
Just because people can do various kind of templates doesn't mean it's a good or even flexible system. The are (were?) a lot of people that use OSCommerce, so is it good?

Maybe the oc's templating system is good for devs, but for designers it's not. It's over complex and extremely laborious. There're a lot of code repetition, which is bad and prone to error, the most used modification system (vQmod) makes a complicated situation when you need to change the HTML and you can only override the default template and not the template in use (this is a really useful resource).

When a designer/front-end coder is building a template, he/she is not meant to mess with the controller or model, he/she is supposed to change just the view, or am I missing something?
Isn't this one of the points of the MVC(L)?

Why Joomla's template need solid PHP and OOP knowledge? As you can see the template itself need as few php as possible, you're just echoing the component and modules. Why is this dangerous? I'm really not understanding... Take just some overrides as example is not the best way to evaluate it, as this is not required or even needed. And Joomla 3.x you can override a lot more than the modules, you have to use and understand the system to have a position about it.

To be honest, I use Joomla a lot and it has a lot of problems, really, but to the day I found few systems that has a templating system as pleasant and powerful to use as Joomla. Even Wordpress requires a lot more work and php knowledge than Joomla.

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by rph » Sat Sep 14, 2013 11:35 pm

1) OpenCart is flexible because there's separation of view and controller. This means there's no area a designer can't change, if they choose to (with the exception of a very minor bit of pagination code). Joomla does not have complete separation. Not even close. Saying "I don't want to change those areas" isn't an argument against that. It's just saying you're happy to ignore it.

2) Developers have no template override method. The high flexibility of the view also encourages designers to change things they shouldn't. That in turn can make overriding with an unofficial system like vQmod difficult for developers. I'll also add that vQmod has been able to make changes to multiple templates through wildcards for a long time now.

3) Because of OpenCart's fallback system you can build an entirely unique theme with CSS changes and a couple custom template files. The default template does need some rewriting and standardization to help further facilitate this but the system itself is sound. If you're rewriting everything from scratch you're doing it wrong.

4) I could understand if Joomla had a simple, dedicated display object for designers with output properties (along the lines of $display->title or $display->link['url']) but it does all kinds of crazy stuff like instantiate objects and run methods in the template. That means designers have to laboriously ensure everything is exactly copied over and must be able to troubleshoot OOP programming issues. This also has the side effect of making code refactoring a complete nightmare since it's not the controller building the output. Start changing methods and now everyone's templates have to be updated.

-Ryan


rph
Expert Member

Posts

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

Post by intersect » Tue Sep 17, 2013 9:03 pm

rph wrote:1) OpenCart is flexible because there's separation of view and controller. This means there's no area a designer can't change, if they choose to (with the exception of a very minor bit of pagination code). Joomla does not have complete separation. Not even close. Saying "I don't want to change those areas" isn't an argument against that. It's just saying you're happy to ignore it.

2) Developers have no template override method. The high flexibility of the view also encourages designers to change things they shouldn't. That in turn can make overriding with an unofficial system like vQmod difficult for developers. I'll also add that vQmod has been able to make changes to multiple templates through wildcards for a long time now.

3) Because of OpenCart's fallback system you can build an entirely unique theme with CSS changes and a couple custom template files. The default template does need some rewriting and standardization to help further facilitate this but the system itself is sound. If you're rewriting everything from scratch you're doing it wrong.

4) I could understand if Joomla had a simple, dedicated display object for designers with output properties (along the lines of $display->title or $display->link['url']) but it does all kinds of crazy stuff like instantiate objects and run methods in the template. That means designers have to laboriously ensure everything is exactly copied over and must be able to troubleshoot OOP programming issues. This also has the side effect of making code refactoring a complete nightmare since it's not the controller building the output. Start changing methods and now everyone's templates have to be updated.
Ok, I can't argue with you because I don't have that much knowledge in development. I don't know if you're looking a Joomla's "default" template or a template framework. If it's a template framework, you should avoid it. People tend to over complicate things and even change the behavior of the system. Don't ask me why....

But let's get back to Opencart. I know you can build a oc's theme just with few overriding and focusing mainly in the CSS, that's as clear as possible, but it's not always enough. There are a lot of situation where you have to change HTML. Suppose you need for some reason the breadcrumbs in the bottom part of the content's container. How do you do that without any css "hack"? You've got to put the breadcrumb html (the variable output in this case) in the bottom. Now, just do that to more 10 tpl files and you're done. What if I want the search module in the footer? I can't to that unless I add some code outside of the View. I can't call the modules I need in the places I need. Isn't this a limitation? A pretty big one, to be honest.

How about using OOCSS in oc? Or BEM? How can I do that without change the HTML? I'll probably even have to remove some id's for the sake of consistency and good (front-end) code... If I do this, will the majority of vQmods work? Probably not.
Why can't I build a theme from the scratch? It's the same as saying you can't build a module from the scratch. This is not fair to front-end coders. Why just the developers can have good code?

I like to build my own code because I know how things work and I need good and consistent code. When you have to make pages work in almost every browser out there, mobile or not, you have to get to change the html as you need. I can't reuse the default's code in most of the situation because it's outdated, is really messy, has no comments and is not even indented.

I don't know what developers think about this, but in my experience, a templating system should allow a designer or a front-end coder to do whatever they need to, as long as they don't change the core of the system. It shouldn't deny changes in html. It shouldn't limit where they could put the elements. It shouldn't be as laborious as have to change more than 10 files just to change a small detail.

I don't know if you have ever needed to build a whole theme in oc, but if you did or do you'll see how troublesome, tedious, inflexible and time consuming it is. It's great that the inwards of the system work as they should, but there're a lot of things that should be optimized so we can build really awesome theme, with good (front-end) code, without have to resort to hacks. The sad thing is that the new version (2.0) won't have any improvement in this area, it's just the same old oc's theme with Bootstrap and a bit better code. It'll just make things worse for the ones who doesn't use it or doesn't like it. Now you'll have to clean up the code, just to make things work the way they should...

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by Qphoria » Tue Sep 17, 2013 9:44 pm

intersect wrote: Suppose you need for some reason the breadcrumbs in the bottom part of the content's container. How do you do that without any css "hack"? You've got to put the breadcrumb html (the variable output in this case) in the bottom. Now, just do that to more 10 tpl files and you're done. What if I want the search module in the footer? I can't to that unless I add some code outside of the View. I can't call the modules I need in the places I need. Isn't this a limitation? A pretty big one, to be honest.
I'm no theme expert. But I know that the <div class="breadcrumb"> exists and why can't you use CSS to move that? Forget the fact that you and I both know that the breadcrumb appears at the top of the html, when the page is rendered, it is all considered one-piece. You can move it around all you like using CSS and positioning or margins. Changing 10 tpl files or a few lines in CSS seems like a no-brainer.
intersect wrote: How about using OOCSS in oc? Or BEM? How can I do that without change the HTML? I'll probably even have to remove some id's for the sake of consistency and good (front-end) code... If I do this, will the majority of vQmods work? Probably not.
Then why do it? First off BEM and OOCSS are like completely different frameworks. You could say "what if I code in ASP instead of PHP".. What if I used Smarty? There is no need to use OOCSS ... it doesn't give you any better options than standard css. It is a personal preference in trendy coding but It only works if you are designing a personal site or building your own blog or ecommerce system and starting with that as your foundation. You said it yourself, when people try to make their own frameworks in Joomla it turns out badly... That is because it is unnecessary and goes against the grain for the sake of being different. It gives no benefit in the end result. In the end, everything comes out as standardized HTML and CSS. That's like adding Prototype or Mootools instead of just sticking with jQuery.. there's just no need to mix or switch to different frameworks just because it is trendy at the moment. In the end plain ol' html and css are still the foundation of any web page and don't get "old".
Why can't I build a theme from the scratch? It's the same as saying you can't build a module from the scratch. This is not fair to front-end coders. Why just the developers can have good code?
Because like any platform you need to follow the standards that are already set up. I'm not saying the default theme is perfect, but it has a good level of id and class tags. It follows the rules of a single id name per page. It may not be semantic but that is not a show stopper and being semantic is almost always impossible for more complex setups and is typically considered as more of an ideal than a usable practice.
I like to build my own code because I know how things work and I need good and consistent code. When you have to make pages work in almost every browser out there, mobile or not, you have to get to change the html as you need. I can't reuse the default's code in most of the situation because it's outdated, is really messy, has no comments and is not even indented.
Well If there is one thing to be said about Daniel's code, it's that it is mostly ALWAYS indented. php files have a single tab, tpl files have 2 spaces, but they are almost all indented at the html level (ignore the php in the tpl files as that is purposely non-indented because it follows the html as the master). The only places I've seen it a little off is on some of the

Code: Select all

<td><select>
</select></td>
being on the same line. But even still, the indents are there.
I don't know what developers think about this, but in my experience, a templating system should allow a designer or a front-end coder to do whatever they need to, as long as they don't change the core of the system. It shouldn't deny changes in html. It shouldn't limit where they could put the elements. It shouldn't be as laborious as have to change more than 10 files just to change a small detail.
I'll agree that some recent changes (like moving the breadcrumb from the common header into each individual page... ridiculous) weren't the best ideas. But again, most of them are classed correctly and can be adjusted with CSS. But the bigger focus on this topic was the themes that change the actual standard tag name to something similar or use poor coding practices. Things like the product page, id="price" as you can guess would be a pretty important factor in a lot of mods. Changing it to "s_price" or "priceStandard" or "normalPrice" is just unnecessary.
The php code for price is

Code: Select all

<?php echo $price; ?>
Changing it to

Code: Select all

<?php echo '<b>' . $price . '</b>'; ?>
is just ridiculous. But it is this type of ridiculous code that I have to deal with all the time when people have issues with my options mods and price update mods. I spend at least 2 hours a day logging into people's ftps to find out that the price tag was changed or the class or they changed it from id="price" to class="price" or id="image" was removed or changed to id="mainImg" or some other unnecessary change.
I don't know if you have ever needed to build a whole theme in oc, but if you did or do you'll see how troublesome, tedious, inflexible and time consuming it is. It's great that the inwards of the system work as they should, but there're a lot of things that should be optimized so we can build really awesome theme, with good (front-end) code, without have to resort to hacks. The sad thing is that the new version (2.0) won't have any improvement in this area, it's just the same old oc's theme with Bootstrap and a bit better code. It'll just make things worse for the ones who doesn't use it or doesn't like it. Now you'll have to clean up the code, just to make things work the way they should...
Well now see, bootstrap is a popular theme framework. It requires ALL elements be classed and I would assume would force good theming practice. Why wouldn't this be better? Aside from the overall theme structuring issues (like the breadcrumb issue I mentioned) the end result of css and html should be a lot cleaner and lot easier to use more CSS changes.

OpenCart's theme framework of having separate controller code is a lot like phpbb, wordpress, etc.There is a header.tpl file that handle's the code from the header controller. There is a column left, right, footer all matching their associated controller files. This isn't something new. It is standard MVC style theming. As rph said, Joomla appears to be adding html directly into controller files and then loading that data with a function call. But that defeats the purpose of MVC.

The biggest issue I see with OpenCart theming is like I said above where the individual module code should only have the "module" code in it and not the box structure. That should be controlled by the theme and the module data should be theme agnostic. That would allow one theme to have a wrapper like this:

Code: Select all

<div class="box">
   <div class="boxTop"><?php echo $heading_title; ?></div>
   <div class="boxMid">
  
  --module_code_call_goes_here--

   </div>
   <div class="boxBot"><?php echo $heading_title; ?></div>
</div>
and another theme could have

Code: Select all

<div class="boxLeft">
  <p><?php echo $heading_title; ?></p>
  <div>

  --module_code_call_goes_here--

  </div> 
</div>
and the actual mod contents will display correctly on both themes because it only has its own code to worrry about. The way it is currently in opencart means each theme requires its own tpl file with the box wrapper code specified and it's a pain for module devs. So we have to adapt module tpl files to each crazy ass custom theme which means more work for us.

But theme devs need to follow the standards of the platform, even if you don't like it. Module makers also have to follow the standards. You think we wouldn't prefer a single file for a module instead of a minimum of 6? When you are making car parts for a Chevy then you can't expect the Honda parts to fit.

Image
Donate!|OpenCart Basics|GeoZones
Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by pedro1993 » Tue Sep 17, 2013 11:20 pm

This has got to me the most in-depth topic I have read! My head is sore after reading through this! :L

For professional OpenCart, HTML/CSS & PHP/MySQL support feel free to PM me :)
Click here for my extentions
Did I help you? Donate here to show support
Follow me on Twitter!
Catch me on Facebook!
Watch YouTube OpenCart Tutorials and Extension Demos

Image


User avatar
Active Member

Posts

Joined
Tue Oct 18, 2011 4:31 am
Location - Glasgow, Scotland

Post by pedro1993 » Wed Sep 18, 2013 9:15 am

Well, I don't know enough to comment on other shopping carts template frameworks, and CMS template frameworks, but here is a preview of my nearly finished OpenCart template. The template is made up of 3 files:
template/common/header.tpl
template/common/footer.tpl
stylesheet/stylesheet.css

I edited the header so OC uses my new stylesheet and not the default. I also added a wrapper div round the left, right and center columns. The wrapper div is opened at the bottom of the header.tpl file. I edited the footer file so it closes the wrapper div before actually reaching the footer. In total I have spent 20 minutes working with HTML, and roughly 3-4 hours on styling and moving things around on the CSS file.

I think it's safe to say that building for templates for OpenCart is pretty effortless unless you complicate it.

Attachments

preview.png

preview.png (554.88 KiB) Viewed 13412 times


For professional OpenCart, HTML/CSS & PHP/MySQL support feel free to PM me :)
Click here for my extentions
Did I help you? Donate here to show support
Follow me on Twitter!
Catch me on Facebook!
Watch YouTube OpenCart Tutorials and Extension Demos

Image


User avatar
Active Member

Posts

Joined
Tue Oct 18, 2011 4:31 am
Location - Glasgow, Scotland
Who is online

Users browsing this forum: No registered users and 4 guests