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
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
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.