Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
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.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"?
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.I can't call the modules I need in the places I need. Isn't this a limitation?
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 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?)Why can't I build a theme from the scratch?
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 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.
-Ryan
Why not enforce mandatory class/id names instead?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.
-Ryan
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: 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.
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: 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".
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: 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 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: 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 thebeing on the same line. But even still, the indents are there.Code: Select all
<td><select> </select></td>
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: 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 isChanging it toCode: Select all
<?php echo $price; ?>
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.Code: Select all
<?php echo '<b>' . $price . '</b>'; ?>
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: 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.
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.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:
and another theme could haveCode: 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 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.Code: Select all
<div class="boxLeft"> <p><?php echo $heading_title; ?></p> <div> --module_code_call_goes_here-- </div> </div>
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.
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.
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...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.
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: 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 didn't know that MVC had this big limitation. I'll have to study it more so I can really understand...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.
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: 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 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...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.
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.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.
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.
not sure that will work.rph wrote:Why not enforce mandatory class/id names instead?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.
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.
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.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...
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
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.JNeuhoff wrote: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.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...
However, in general a web theme is not supposed to do deep structural changes to Opencart.
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.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.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
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.JNeuhoff wrote: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.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 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...
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.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.
For OpenCart & PHP/MySQL support feel free to PM me
Click here for my extentions
Did I help you? Donate here to show support
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>
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>
For OpenCart & PHP/MySQL support feel free to PM me
Click here for my extentions
Did I help you? Donate here to show support
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>
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
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: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.
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?Johnathan wrote: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: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.
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>
For OpenCart & PHP/MySQL support feel free to PM me
Click here for my extentions
Did I help you? Donate here to show support
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>
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?
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
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:Did I made myself clear? If there's any doubt about the proposal, please tell me if there's any.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>
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
Users browsing this forum: No registered users and 49 guests