Post by JNeuhoff » Wed Sep 18, 2013 7:50 pm

pedro1993: I totally agree with you, creating Opencart themes is easy and does not take excessive amount of time. Only poorly implemented themes like shoppica will break 3rd party extensions.

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 rph » Wed Sep 18, 2013 9:40 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"?
It's doable with CSS positioning as others have mentioned. I don't think you'd find many people that disagree breadcrumbs should get their own template and currency, language, and search should be set up as true modules instead of the half-state they're in. These are simple matters of implementation rather than architecture, though. They're also a tiny part of any theme.
I can't call the modules I need in the places I need. Isn't this a limitation?
No, that's how MVC works. It's the controller which decides the view. Joomla really blurs the lines here which would confuse a lot of people. If it was the template which decided what to display then there would be no way to remove or add a module without editing template files.

There's an argument to be made for a layout install system so users don't have to manually set up all their modules with a template (if it needs it), but the layout system itself is a good one since it keeps the modules nicely decoupled and portable.
Why can't I build a theme from the scratch?
I guess I don't follow what the limitation is here. You can rewrite all the HTML/CSS you want. (Weren't you just saying it was too much work rewriting everything?)
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.
If a designer is experienced with the system and can't get a customized OpenCart theme made in a day or two they should probably re-examine their workflow.

-Ryan


rph
Expert Member

Posts

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

Post by rph » Wed Sep 18, 2013 9:54 pm

Qphoria wrote: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.
Why not enforce mandatory class/id names instead?

-Ryan


rph
Expert Member

Posts

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

Post by intersect » Thu Sep 19, 2013 12:43 am

Qphoria wrote: 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.
To do this you'll have to set the element position as absolute and this can be a bit troublesome in responsive layouts. CSS ordering is not always the best choice. Also, it's just an example that's easy to anyone to see one of the problems.
Qphoria wrote: 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".
Sorry, forgot to tell BEM naming scheme and not just BEM. OOCSS is a not a framework it's an efficient way to code CSS. It gives a lot of benefits and is not just a trend. There are a lot of efforts in the front-end area to make things better and OOCSS is one good, consolidated and really useful "method". I don't see why to not use it.
Qphoria wrote: 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.
The default is outdated and doesn't use any HTML5 feature. It's important for SEO, accessibility and even performance. It doesn't have a convention and lacks documentation. You have to dig deeper to understand what is what and follow the dated rules (and aren't even the best to an outdated convention) set by it. Semantic is not just an ideal it's an important topic in front-end development. It should be used, and big guys in the area say it a lot.
Qphoria wrote: 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 tend to disagree. Maybe the php's files are (by the way, they have comments and are even pretty to look at), but the tpl's are not good indented. They have just the basic, but they are not well indented. By the way the use of tables limits a lot what can be made just with CSS...
Qphoria wrote: 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 totally agree with you. A good front-end developer will even avoid using id's for style and will use them just for js. But if this happens a lot, shouldn't we being discussing (as we are ;) ) what can be changed or improved in the system itself, so it wouldn't happen anymore? I don't think this is a problem where just the theme developers are guilty, I think that this is a big situation where people are just point fingers at each other without seek any (real) solution. Maybe improve the theme system in a way the theme developers don't feel the need to to such strange thing? Or that would make this almost impossible to do... I don't know.
Qphoria wrote: 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.
Forcing the use of a (css) framework is not really a good thing. As you said yourself, there're a lot of trends in this area, and Bootstrap is indeed a trend. To be honest it's far from the best. When you use Bootstrap you have to use its not really efficient convention. There're a lot of discussion about this, but to be straight forward, it not a good framework to work with if you're serious about designing and front-end coding... Something like inuit.css would be a great framework to embed in a opensource system.
Qphoria wrote: 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.
I can't say much if a system is breaking MVC or not, like I said before, because I just don't have enough knowledge for this.
Theme agnostic, this this the keyword in this whole problem. I totally agree with you. What more could be made to achieve that?
I know that we have to follow the system conventions, but why can't the system be improved to make life easy to both sides? I might be wrong, but to me it seems that there are just developers in the oc team and that the whole platform is made just for developers and end users. It shouldn't be this way. The designers should be considered too and not just treated as bad guys that mess with everyone work.

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by intersect » Thu Sep 19, 2013 12:50 am

JNeuhoff wrote:pedro1993: I totally agree with you, creating Opencart themes is easy and does not take excessive amount of time. Only poorly implemented themes like shoppica will break 3rd party extensions.
If you're just "skinning" it, it's really easy. Try to change a bit of the page's structure and you'll see how bad this can be. Anything that is not in the footer or header and has to be changed in the HTML will be a lot of work. Try it yourself and you'll understand...

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by intersect » Thu Sep 19, 2013 1:00 am

rph wrote: It's doable with CSS positioning as others have mentioned. I don't think you'd find many people that disagree breadcrumbs should get their own template and currency, language, and search should be set up as true modules instead of the half-state they're in. These are simple matters of implementation rather than architecture, though. They're also a tiny part of any theme.
I've already explained that in the post before. Why not change these little things, so our lives will get a bit easier?
rph wrote: No, that's how MVC works. It's the controller which decides the view. Joomla really blurs the lines here which would confuse a lot of people. If it was the template which decided what to display then there would be no way to remove or add a module without editing template files.

There's an argument to be made for a layout install system so users don't have to manually set up all their modules with a template (if it needs it), but the layout system itself is a good one since it keeps the modules nicely decoupled and portable.
I didn't know that MVC had this big limitation. I'll have to study it more so I can really understand...
rph wrote: I guess I don't follow what the limitation is here. You can rewrite all the HTML/CSS you want. (Weren't you just saying it was too much work rewriting everything?)
There're a lot of people here who said that this should be avoided at all costs. That's what I was referring to. But anyway, if I do it, won't a lot of vQmods stop work? So, there's a big limitation in this...
rph wrote: If a designer is experienced with the system and can't get a customized OpenCart theme made in a day or two they should probably re-examine their workflow.
I have a pretty good work flow and I'm always trying to improve it, but I can't make a theme that isn't just a restyled default in just two days. I've tried. If it was just CSS, yes, I could do it in half a day using SASS and everything I can. But as I said before, anything that hasn't the same structure as the default, will be a lot of work...

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by Qphoria » Thu Sep 19, 2013 1:22 am

intersect wrote: I totally agree with you. A good front-end developer will even avoid using id's for style and will use them just for js. But if this happens a lot, shouldn't we being discussing (as we are ;) ) what can be changed or improved in the system itself, so it wouldn't happen anymore? I don't think this is a problem where just the theme developers are guilty, I think that this is a big situation where people are just point fingers at each other without seek any (real) solution. Maybe improve the theme system in a way the theme developers don't feel the need to to such strange thing? Or that would make this almost impossible to do... I don't know.
Honestly, for me this is probably the biggest problem.. And i solely blame the theme developers because they are changing an existing common tag. The main image <img> tag on the product page is pretty standard for all themes.. almost all themes will have a main image. For you to change id="image" to id="imgMain" or remove it completely is just ignorant theming and holds no purpose.

Also not using the fallback system. This is a huge feature that I personally added back in v0.7.9 and pleaded with Daniel to keep in 1.x. But it is so often ignored. There is plenty of documentation about it. But themers are again ignorant to developer notes. It results in a waste of space, and more work for the developer and end users to constantly patch the theme because a bug fix was made to the payment tpl file or some other less commonly altered tpl file that their theme is unnecessarily overriding because they blindly cloned the entire default folder instead of only the files that changed.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by Qphoria » Thu Sep 19, 2013 1:26 am

rph wrote:
Qphoria wrote: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.
Why not enforce mandatory class/id names instead?
not sure that will work.

Some themes have a <div> for the top and bottom of the module box
some don't need a bottom. It's not just the naming but the amount. And they could be different as I showed... one might use <div> for the title.. one might use <h3> for the title, one might use <p>
another theme might put the title on the bottom of the box instead of the top. That should be left up to the theme maker to choose, but not the module maker to have to adapt.

Image


User avatar
Administrator

Posts

Joined
Tue Jul 22, 2008 3:02 am

Post by JNeuhoff » Thu Sep 19, 2013 2:07 am

intersect wrote: If you're just "skinning" it, it's really easy. Try to change a bit of the page's structure and you'll see how bad this can be. Anything that is not in the footer or header and has to be changed in the HTML will be a lot of work. Try it yourself and you'll understand...
I normally use the Override Engine for this kind, as it also involves changes to the controllers and possibly language files for e.g. the header or footer. In future projects, I'll also consider the usage of DOM or other HTML modifying tools in the overridden controller (the latter does needed changes to the HTML output). If my web theme is more than a simple skinning, I usually create a whole bundle of overriden controller and model classes and language files, along with the theme's CSS, images, and TPL files.

However, in general a web theme is not supposed to do deep structural changes to Opencart.

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 intersect » Thu Sep 19, 2013 2:29 am

JNeuhoff wrote:
intersect wrote: If you're just "skinning" it, it's really easy. Try to change a bit of the page's structure and you'll see how bad this can be. Anything that is not in the footer or header and has to be changed in the HTML will be a lot of work. Try it yourself and you'll understand...
I normally use the Override Engine for this kind, as it also involves changes to the controllers and possibly language files for e.g. the header or footer. In future projects, I'll also consider the usage of DOM or other HTML modifying tools in the overridden controller (the latter does needed changes to the HTML output). If my web theme is more than a simple skinning, I usually create a whole bundle of overriden controller and model classes and language files, along with the theme's CSS, images, and TPL files.

However, in general a web theme is not supposed to do deep structural changes to Opencart.
I'm not referring to behaviors of the system or anything else, just plain "old" HTML (of course, with the proper variables, functions and so on...). As an example, the product page can have the image in the top with full width, the title right under the image, the price in the middle and so on. You can do a lot of things with just HTML. That's the structure that I'm referring to, the page's structure.

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by JNeuhoff » Thu Sep 19, 2013 2:46 am

intersect wrote: I'm not referring to behaviors of the system or anything else, just plain "old" HTML (of course, with the proper variables, functions and so on...). As an example, the product page can have the image in the top with full width, the title right under the image, the price in the middle and so on. You can do a lot of things with just HTML. That's the structure that I'm referring to, the page's structure.
I see. Plain old HTML structure change is usually just a matter of including the structually modified product.tpl file in the theme's product.tpl. I make sure to keep id="..." or class="..." attributes when they are needed in Javascript/JQuery. Never considered this to be a time-consuming or difficult issue.

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 intersect » Thu Sep 19, 2013 9:15 am

JNeuhoff wrote:
intersect wrote: I'm not referring to behaviors of the system or anything else, just plain "old" HTML (of course, with the proper variables, functions and so on...). As an example, the product page can have the image in the top with full width, the title right under the image, the price in the middle and so on. You can do a lot of things with just HTML. That's the structure that I'm referring to, the page's structure.
I see. Plain old HTML structure change is usually just a matter of including the structually modified product.tpl file in the theme's product.tpl. I make sure to keep id="..." or class="..." attributes when they are needed in Javascript/JQuery. Never considered this to be a time-consuming or difficult issue.
That was just an example to make it clear what I was referring to. But, let's suppose that I need that the content top position not between the two side positions, but to take the full width of my container. How can I do this - without have to resort to any css hack - without change all the tpl's that contain the position? I don't think this is possible.

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by Chris_AXA » Fri Sep 20, 2013 9:58 pm

I agree that certain changes have to be made to make extension implementation and theme modification more uniform. Bootstrap integration is a good step because of it's responsive nature and will offer more default core elements that can be used over multiple types of extensions.

I have been working with OC for 2 years now and have become quite familiar with it's structure but there have always been certain small quirks that bothered me. Especially since I try to code my static websites as clean as possible.

There are still cases of some inline CSS in the template files and use of tables that I always have to remove or alter when modding a default template. This also includes unnecessary HTML code like <br>,<b> and other cases of raw HTML characters in the template files (\,|,-, etc.).

Also some Javascript is repeated and pasted in the template files, in the list/grid product view for example. Much cleaner would be 1 external Javascript file (or perhaps even a separate template file for product list) so that any alterations would be simultaneously changed for Category, Manufacturer & Search views.

Overall I feel the way OC is built up is pretty good and easy to get a grip on even for someone with limited PHP knowledge like myself. I am always able to quickly mod the default template to the desires of my clients but I just find myself a lot of times deleting code rather than adding to it. Ideally (most) visual changes should only have to be made from the CSS which also would help with compatibility issues between extensions and 3rd party themes. But then there has to be strict guidelines that have to be upheld by all extension developers and theme makers in regards to element naming and placement of code.

Just my 2 cents...

New member

Posts

Joined
Mon Sep 24, 2012 7:18 pm

Post by pedro1993 » Sun Sep 22, 2013 7:08 am

Qphoria wrote: Also not using the fallback system. This is a huge feature that I personally added back in v0.7.9 and pleaded with Daniel to keep in 1.x. But it is so often ignored. There is plenty of documentation about it. But themers are again ignorant to developer notes. It results in a waste of space, and more work for the developer and end users to constantly patch the theme because a bug fix was made to the payment tpl file or some other less commonly altered tpl file that their theme is unnecessarily overriding because they blindly cloned the entire default folder instead of only the files that changed.
I couldn't agree more, that's why I posted ages ago in this thread that there was a fallback system. As well as it wasting the users server space and the developers time, it is actually a waste for OpenCart's space as well. It actually annoys me when working on an existing OpenCart site, with a poor theme.

For OpenCart & PHP/MySQL support feel free to PM me :)
Click here for my extentions
Did I help you? Donate here to show support


Active Member

Posts

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

Post by pedro1993 » Sun Sep 22, 2013 7:17 am

Can I make a small suggestion that really annoys me in OpenCart right now.

Although this doesn't have anything to do with the front end theme, the admin theme is quite irritating when trying to add a tab using vQmod.

For example in one of my extensions, to change the settings for that extension, you must edit the store settings under admin > system > settings > (whatever store the user selects).

In the admin/view/template/setting/setting.tpl/store_form.tpl the tabs div is laid out like so:

Code: Select all

<div id="tabs" class="htabs"><a href="#tab-general"><?php echo $tab_general; ?></a><a href="#tab-store"><?php echo $tab_store; ?></a><a href="#tab-local"><?php echo $tab_local; ?></a><a href="#tab-option"><?php echo $tab_option; ?></a><a href="#tab-image"><?php echo $tab_image; ?></a><a href="#tab-ftp"><?php echo $tab_ftp; ?></a><a href="#tab-mail"><?php echo $tab_mail; ?></a><a href="#tab-fraud"><?php echo $tab_fraud; ?></a><a href="#tab-server"><?php echo $tab_server; ?></a></div>
Although it is valid HTML, it makes it a nightmare if you have two vQmods trying to edit that one line of code. As a result I have had to use jQuery to add tabs, but I'd be more comfortable using HTML for such a thing!

Wouldn't it be better if it was laid out like so:

Code: Select all

<div id="tabs" class="htabs">
    <a href="#tab-general"><?php echo $tab_general; ?></a>
    <a href="#tab-store"><?php echo $tab_store; ?></a>
    <a href="#tab-local"><?php echo $tab_local; ?></a>
    <a href="#tab-option"><?php echo $tab_option; ?></a>
    <a href="#tab-image"><?php echo $tab_image; ?></a>
    <a href="#tab-ftp"><?php echo $tab_ftp; ?></a>
    <a href="#tab-mail"><?php echo $tab_mail; ?></a>
    <a href="#tab-fraud"><?php echo $tab_fraud; ?></a>
    <a href="#tab-server"><?php echo $tab_server; ?></a>
</div>
I think it does this in other pages in the admin panel, but I could be wrong.

For OpenCart & PHP/MySQL support feel free to PM me :)
Click here for my extentions
Did I help you? Donate here to show support


Active Member

Posts

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

Post by pedro1993 » Sun Sep 22, 2013 7:54 am

Also, same goes for the actions buttons:

Code: Select all

<div class="buttons"><a onclick="$('#form').attr('action', '<?php echo $invoice; ?>'); $('#form').attr('target', '_blank'); $('#form').submit();" class="button"><?php echo $button_invoice; ?></a><a href="<?php echo $insert; ?>" class="button"><?php echo $button_insert; ?></a><a onclick="$('#form').attr('action', '<?php echo $delete; ?>'); $('#form').attr('target', '_self'); $('#form').submit();" class="button"><?php echo $button_delete; ?></a></div>
Just very messy markup.

Peter

For OpenCart & PHP/MySQL support feel free to PM me :)
Click here for my extentions
Did I help you? Donate here to show support


Active Member

Posts

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

Post by Johnathan » Sun Sep 22, 2013 11:56 pm

pedro1993 wrote:Can I make a small suggestion that really annoys me in OpenCart right now.

Although this doesn't have anything to do with the front end theme, the admin theme is quite irritating when trying to add a tab using vQmod.
I'm not disagreeing that the HTML is messy and could use some improvement, but you can still easily add a tab using vQmod in that block of code. You just have to do it like this:

Code: Select all

<file name="admin/view/template/common/header.tpl" error="skip">
	<operation error="skip">
		<search position="replace"><![CDATA[
			<a href="#tab-local"><?php echo $tab_local; ?></a>
		]]></search>
		<add trim="true"><![CDATA[
			<a href="#tab-local"><?php echo $tab_local; ?></a>
			<a href="#new-tab">My New Tab</a>
		]]></add>
	</operation>
</file>

Image Image Image Image Image


User avatar
Administrator

Posts

Joined
Fri Dec 18, 2009 3:08 am


Post by pedro1993 » Mon Sep 23, 2013 8:40 am

Johnathan wrote:
pedro1993 wrote:Can I make a small suggestion that really annoys me in OpenCart right now.

Although this doesn't have anything to do with the front end theme, the admin theme is quite irritating when trying to add a tab using vQmod.
I'm not disagreeing that the HTML is messy and could use some improvement, but you can still easily add a tab using vQmod in that block of code. You just have to do it like this:

Code: Select all

<file name="admin/view/template/common/header.tpl" error="skip">
	<operation error="skip">
		<search position="replace"><![CDATA[
			<a href="#tab-local"><?php echo $tab_local; ?></a>
		]]></search>
		<add trim="true"><![CDATA[
			<a href="#tab-local"><?php echo $tab_local; ?></a>
			<a href="#new-tab">My New Tab</a>
		]]></add>
	</operation>
</file>
Even if all the tabs are confined within the one line?

For OpenCart & PHP/MySQL support feel free to PM me :)
Click here for my extentions
Did I help you? Donate here to show support


Active Member

Posts

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

Post by intersect » Mon Sep 23, 2013 11:45 am

After much (good) discussion, I kept thinking in how the oc's theming system could be improved and I've made a little draft of how it could be to be easier to deal with, for designers and developers.
It's not extensive and is really far from perfect, but it has some ideas to make it better and less prone to problems:

Code: Select all

<!DOCTYPE html>
<html>
<head>
    <!--
        Why not simplify things up? This would echo all the metatags, css's and
        javascripts. This way the designer could add the scripts and styles
        manually or add directly to the system. Something like:
        $something->addStyleSheet('stylesheet/style.css').
        The second option would be great because someone could easily create some
        sort of extension that would merge and minify css's and scripts. It could
        even be built in into the platform itself.
    -->
    <?php echo $head; ?>
</head>
<body>
    <header>
        <img src="<?php echo $logo; ?>" alt="">
        <?php echo $search; ?>
        <?php echo $menu; ?>
    </header>

    <!--
        The breadcrumbs, search, menu and some other things would turn into
        modules. This way a designer could change its position, wrapper and
        anything outside the core output of it without affect anything and would
        make everyone life a lot easier.
    -->
    <?php echo $breadcrumbs; ?>
    <!--
        Everything that would be echoed should have the cleanest output possible.
        Just a div with the class to indicate the kind of element (like module),
        the class to identify it and maybe an ID when needed. This way all the
        wrappers, classes and so on    could be whatever the designer wants or needs,
        but everything could be    still reached by developers in any kind of
        extension.
    -->
    <aside><?php echo $column_top; ?></aside>
    
    <aside><?php echo $column_left; ?></aside>
    
    <!--
        All the pages tpl's would echo here, instead of have it's own full page;
        This by itself, would make things a lot easier and could avoid a lot of
        problems between extensions (vQmod or not) and themes.
        If an "one page model" is not possible, could there be a "content.tpl"
        file. This would not be the ideal situation, but would help a lot
        already.
     -->
    <article><?php echo $content; ?></article>

    <!--
        The modules could have the less code possible and should have just the
        class needed to have the basic style and the class to identify the module.
        For instence, take the account module. In the 2.0 version it would output
        like this:

        <div class="sidebar">
          <ul class="nav nav-tabs nav-stacked">
            <?php if (!$logged) { ?>
            <li><a href="<?php echo $login; ?>"><?php echo $text_login; ?></a></li>
            .
            .
            .
            <?php } ?>
          </ul>
        </div>

        Instead it could be much simpler, like this:

        <div class="oc-module account">
          <ul>
            <?php if (!$logged) { ?>
            <li><a href="<?php echo $login; ?>"><?php echo $text_login; ?></a></li>
            .
            .
            .
            <?php } ?>
          </ul>
        </div>

        This way, the designer could put the wrapper in the module position and target
        all the modules with basic styling and still have unique styles for the
        modules he/she wants. The developer would have no problem using vQmod or any
        modification system, because they would target the module itself and not the
        theme.
        Also, the theming system would be framework agnostic (css/javscript framework),
        even if it has any framework bundled.
    -->
    <aside><?php echo $column_right; ?></aside>
    <aside><?php echo $content_bottom; ?></aside>
    
    <footer><?php echo $footer; ?></footer>
</body>
</html>
Did I made myself clear? If there's any doubt about the proposal, please tell me if there's any.
I know that the oc itself would have to be changed to accomplish this and that if it would even be done, this would happen in version 2.5 or 3.0. Even that way, I would like to know if it is viable and if it wouldn't compromise the MVC structure or anything else in oc. What do you think? Would this help in this situation in your opinion?

http://www.intersect.com.br


User avatar
New member

Posts

Joined
Sat May 19, 2012 6:59 am

Post by pedro1993 » Mon Sep 23, 2013 4:52 pm

It wouldn't compromise the MVC structure as the Controller only calls on the view, and defines the variables sent to the View.

It would be pushing OpenCart to a more HTML5 and less traditional framework. My only concern would be that too much change in OpenCart's template will cause an outbreak in extension, modules and vQmods breaking.

It's a toughy :P
intersect wrote:After much (good) discussion, I kept thinking in how the oc's theming system could be improved and I've made a little draft of how it could be to be easier to deal with, for designers and developers.
It's not extensive and is really far from perfect, but it has some ideas to make it better and less prone to problems:

Code: Select all

<!DOCTYPE html>
<html>
<head>
    <!--
        Why not simplify things up? This would echo all the metatags, css's and
        javascripts. This way the designer could add the scripts and styles
        manually or add directly to the system. Something like:
        $something->addStyleSheet('stylesheet/style.css').
        The second option would be great because someone could easily create some
        sort of extension that would merge and minify css's and scripts. It could
        even be built in into the platform itself.
    -->
    <?php echo $head; ?>
</head>
<body>
    <header>
        <img src="<?php echo $logo; ?>" alt="">
        <?php echo $search; ?>
        <?php echo $menu; ?>
    </header>

    <!--
        The breadcrumbs, search, menu and some other things would turn into
        modules. This way a designer could change its position, wrapper and
        anything outside the core output of it without affect anything and would
        make everyone life a lot easier.
    -->
    <?php echo $breadcrumbs; ?>
    <!--
        Everything that would be echoed should have the cleanest output possible.
        Just a div with the class to indicate the kind of element (like module),
        the class to identify it and maybe an ID when needed. This way all the
        wrappers, classes and so on    could be whatever the designer wants or needs,
        but everything could be    still reached by developers in any kind of
        extension.
    -->
    <aside><?php echo $column_top; ?></aside>
    
    <aside><?php echo $column_left; ?></aside>
    
    <!--
        All the pages tpl's would echo here, instead of have it's own full page;
        This by itself, would make things a lot easier and could avoid a lot of
        problems between extensions (vQmod or not) and themes.
        If an "one page model" is not possible, could there be a "content.tpl"
        file. This would not be the ideal situation, but would help a lot
        already.
     -->
    <article><?php echo $content; ?></article>

    <!--
        The modules could have the less code possible and should have just the
        class needed to have the basic style and the class to identify the module.
        For instence, take the account module. In the 2.0 version it would output
        like this:

        <div class="sidebar">
          <ul class="nav nav-tabs nav-stacked">
            <?php if (!$logged) { ?>
            <li><a href="<?php echo $login; ?>"><?php echo $text_login; ?></a></li>
            .
            .
            .
            <?php } ?>
          </ul>
        </div>

        Instead it could be much simpler, like this:

        <div class="oc-module account">
          <ul>
            <?php if (!$logged) { ?>
            <li><a href="<?php echo $login; ?>"><?php echo $text_login; ?></a></li>
            .
            .
            .
            <?php } ?>
          </ul>
        </div>

        This way, the designer could put the wrapper in the module position and target
        all the modules with basic styling and still have unique styles for the
        modules he/she wants. The developer would have no problem using vQmod or any
        modification system, because they would target the module itself and not the
        theme.
        Also, the theming system would be framework agnostic (css/javscript framework),
        even if it has any framework bundled.
    -->
    <aside><?php echo $column_right; ?></aside>
    <aside><?php echo $content_bottom; ?></aside>
    
    <footer><?php echo $footer; ?></footer>
</body>
</html>
Did I made myself clear? If there's any doubt about the proposal, please tell me if there's any.
I know that the oc itself would have to be changed to accomplish this and that if it would even be done, this would happen in version 2.5 or 3.0. Even that way, I would like to know if it is viable and if it wouldn't compromise the MVC structure or anything else in oc. What do you think? Would this help in this situation in your opinion?

For OpenCart & PHP/MySQL support feel free to PM me :)
Click here for my extentions
Did I help you? Donate here to show support


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 28 guests