[Your opinion] Skeleton Theme in v.1.5

[Patric]

Hi,

This topic is intended to collect your reactions about the Preview the Skeleton Theme in v.1.5, by Vincent Augagneur article from the first issue of our newsletter for the Developers.

This article is also readable on our blog:
http://www.prestashop.com/blog/article/prestashop_v15_revealeddiscover_the_skeleton_theme_by_vincent_augagneur/

So, do not hesitate to let us know your opinion about that in this topic.

Note : any out of place message will be immediately deleted.

----------------------------
About the Developer Newsletter

To subscribe to our monthly newsletter for the Developers, please fill the Newsletter form located on our homepage selecting "A developer" or "A web-agency" in the "You are" field.

Read the first edition of this newsletter.

[Dreamtheme]

Skeleton theme is a good idea, however it have to be backward compatible with old themes and easy and fast to develop, otherwise it make no sense. My suggestion is to implement some horizontal and vertical menus and slideshow in prestashop and let users using live edit function not just to edit the position but to edit the width and height of elements, change colors and change images or just to implement theme editor.

[Vincent Augagneur]

Hi,

Live edit feature is only for module position (move module and delete module).
You are talking about the theme editor that is not directly linked to the skeleton theme.
It seems to me that the theme editor, would rather a module that permit to edit the theme in live.

Vincent

[Guest]

As a front-end developer, would like to know more about this skeleton.

As a starter, I am not going to recommend any 960.gs or any so called "framework" they just bloat your code and can cause more problems than fix them. What I feel when I read skeleton, I see the 1.4 theme as a skeleton also. But badly designed one, really badly. Unless you can get the global variables and smarty variables actually to work in 1.5 with smarty v3 to work better than now.

This would be greater advancement than forcing people to stick to your semantics and not actually able to do really anything else than just styling. Some of us actually would like to work on template from scratch and not forced to have as an example, breadcump.tpl file called on each internal page separately. Also hint.. google for why not xhtml

I hope truly that you guys will get out of the fixed hook positioning (hard coded mostly) and able to call stuff outside category.tpl as an example. So the pages could be targeted pre-render and it would not matter if my header.tpl is calling some smarty variable or is it footer.tpl like it is now. Some variables are just not accessible from certain tpl files what I've noted, or just then original versions of tpl files and modules have huge flaws.

[Krystian Podemski]

Hello,

Skeleton In my opinion, it must be something completely new. No need to maintain backward compatibility.

The use of any framework, CSS is not a good idea. It is better to write a good basic template PrestaShop.

Me the most to implement the following functionality:

- the module where you want
- Lots of templates for the page (something like wordpress)

[Patric]

As this topic concerns the integrators more than the developers, I move it into this forum.

[uddhava]

I have looked into the 960gs a bit and it looks like a really nice css framework that is easily understandable and readable. It forces the default template into a fixed framework within a 960px size. So far so good. It can really help theme developers. But it also create complications as far as i can see it. It is not backwards compatible with older themes. Lets hope it is future compatible also from that point on.

But i am wondering for the most part if Prestashop really needs a fixed theme framework that obviously is tightly interwoven with the core structure. Does that mean that all new theme have to follow the same rigid framework? If so, i think PS should rather follow the path of Wordpress. The core of wordpress is highly seperated and there are many third-party frameworks (like Genesis) that build upon that. They have their own themes and follow their own make-up. Any framework will work with Wordpress.

Now wordpress is obviously not a shop cms. And wordpress also does not have so many modules/plugins coming with it. But wordpress can be updated by 1 click of a button. I think PS can learn something from that....
And WP also has the ability to choose a different template on a per-page basis. I can create 10 pages each with a diffferent layout and style. No need for framework or skeleton themes.

So i like that PS is getting somewhat more serious in coding a decent theme. But what i really dont like is the overall complexity and interdependency that the core code has on its modules and the current theme that make it hard to upgrade, unclear and daunting. I hope i can help out here and there whenever i find something. But practically the PS team needs to improve on its help on the forum, provide quality help documents (in proper english) and give more insight in coming new features. The new developers blog is already a big start.

I hope the PS team would also take time to through the current code and improve it instead of adding multiple new features at a killing rate. Whenever i look into the hook naming in the backend i get sore eyes... A lot of english is translated the "french way". I mean in french it might be called Module Paiement. But in english it is Payment Module. (and not Module Payment)...

[Guest]

Still against implementing any grid system to them. But as principle like with all programmings languages etc. Learn the basics before playing around with frameworks. And still grids ain't frameworks.

Like Uddhava pointed out the rigid framework is too tight. Comparison to WP is good, which is still bit more rigid to what I've used to. But hey, we got too many CMS's out there and all of us have our own preferences.

As normal layout folding process goes, you build html and css maybe even js at this point. You then start to implement it to application, modifying the css for plugins that you could not have tested before actual first stage implementation. At this point, Prestashop is in knee deep ****. If you don't use PS own ID's and even structural elements. Javascripts will fail, then off you go modifying the javascripts. All templates should work without javascript, I understand Web 2.0 is here and bit of a gimmick. But PS's methods are obstructive, when whole world outside is going towards non-obstructive design.

For next generation the HTML5 doctype should be introduced, also HTML5 input fields etc. Could be taken already in use, not to mean that would use sections, article etc.. tags, as they are not backwards compatible directly with older browsers, without using html5shiv or similar js that creates the elements. Obviously we all want to go towards and use css3 and all available things we can. That would be great. But this should be left for the template designers/front-end developers to choose and not for Prestashop team. Why HTML5 doctype, as it sets even older browsers to standards mode and then don't need to worry about things really. But this should be up to template developers also, not prestashop team.

So as a conclusion, clear structure to new template. Clearly state what id's are required for possible js effects. Then let us do the rest, also all available variables to pre-processing. So can actually use some of them already in header.tpl as an example and not to wait call for category.tpl for example. Obviously 1.5 will need some theme. But you should not force us to use it. Flexibility flexibility.... and the idea of possible page templates like front-page, single etc.. is not a bad idea at all. All CMS's what I've used has it in some form. Maybe not always as easy to access as would like to, but it is possible without modifying the core. We want Flexibility !!!

[uddhava]

If you don’t use PS own ID’s and even structural elements. Javascripts will fail, then off you go modifying the javascripts.

Is that true? Could you give an example where the ID in the template is set for Javascript?
I am just planning to build a new theme based upon the 960gs framework and i dont want to find out that all my time is wasted on troubleshooting ID problems.

[Guest]

If you don’t use PS own ID’s and even structural elements. Javascripts will fail, then off you go modifying the javascripts.

Is that true? Could you give an example where the ID in the template is set for Javascript?
I am just planning to build a new theme based upon the 960gs framework and i dont want to find out that all my time is wasted on troubleshooting ID problems.

Responded in PM

[Guest]

On request of uddhava, lets post this also public so at least I have some standing ground.

This is from blockcart and ajax-cart.js, so this is when you have ajax cart enabled,
the jquery selector:

$(’body#product p#add_to_cart input’)

This clearly shows the problem, ok the body#product is not bad at all, but next part p#add_to_cart input is bit bad. To defence why like this, html 4.01 strict and xhtml 1.1 does not allow <input> element to be direct child of <form> and it needs an block level element as parent to validate. HTML5 will accept input elements without containing parent elements so we are heading here for the right direction.

Use of

is common, but on a shaky ground with semantics. Is input element really a paragraph? Oh well, that is not the discussion here. Problem here is already that lets except that I might use

, no semantic meaning for that. As if I would do something like this to an app that requires target, would target the button itself directly. Exception of course if we had a list of products. Then would target the parent .class which would repeat for each element and construct the selector like .list-item .add-to-cart where .add-to-cart would be my input button for adding. Or just directly go for the .add-to-cart, depends bit from scenario. If I worked on someone else project, I might use the first one just in case if some generic classes like .remove and .add might be used and some other element might have the same class.

EDIT! All in favour of just selecting the .add-to-cart. My mind just wanders around and comes back to topic after a while. More writing and less thinking of different scenarios for me.

[uddhava]

I read somewhere that for javascript you do not use .class but ID. And thats how far my knowlegde goes of javascript and html ;-)

So as a conclusion, clear structure to new template. Clearly state what id’s are required for possible js effects. Then let us do the rest, also all available variables to pre-processing. So can actually use some of them already in header.tpl as an example and not to wait call for category.tpl for example.

And here we come back to a major pain point for Prestashop; The lack of developer information on any topic, including theming. (lets hope the new dev forum will continue and both?! wiki's will be extended)

[Guest]

I read somewhere that for javascript you do not use .class but ID. And thats how far my knowlegde goes of javascript and html

On the basis id's are unique values per page and multiple same classes can be on same page. And both can be used to select elements with css and Javascript. getElementsByClassName has been introduced to Javascript during the later years and the support between browser varies (Looking at some compatibility tables, onlye IE9 from IE browsers support it), thats why use ID's instead of classes with js. But javascript frameworks has brought this option more available to developers.

[uddhava]

I had a few days to get to know the 960gs system. And i also meditated upon the news that PS announced with this skeleton theme. And my conclusion till now is that this 'news' is actually not newsworthy. Let me explain.

The new theme in PS 1.5 will be using 960gs and jQuery UI. Thats wonderful, but not really news. If i decided to use inuetCSS on my theme then so what? Doesnt seem newsworthy to me, even after a few days of pondering. If i read between the lines i think these are first humble beginnings from the PS team to streamline and standardize the theming. I think what we really need, summarizing from the posts above, is more detailed reference information on how PS uses globals smarty variables and ID's and classes in combo with JS.
Then also from the post above we need :
* more flexible hook positioning (from within the template files with a smarty shortcode)
* strict adherence to webstandards for html(5), xhtml as mentioned by Lazylegs
* per product (group) + per category templating
* well defined list of globally available smarty variables that are available to ALL modules
* poor breadcrumb.tpl. Only gets called from other tpl files instead of its own hook... aaaahh
* and the list will go on

So lets get going on getting these points across and make PS even better.

[cobolian]

Just a really simple theme : less .js, less .css, no picts, no framework. Something to work on.

[uddhava]

Like a skeleton... Only bones :vampire:

[Guest]

So as really short conclusion,

Lets forget the template at the moment and concentrate on bringing data more accessible for templates and developers.

[NemoPS]

I agree with lazy legs. Skeleton theme should be just the barebones of a theme, with minimum graphics made just to esplain the various variables and commands available to the designer. Of course, there MUST be some kind of developer's guide made by the prestateam by now. Such missing is a bit of a drawback to prestashop.

[Vincent Augagneur]

Hello everybody,

We have taken into consideration all your comments and we will take into account in developing the theme skeleton. A solid foundation, but clean. This theme will be (of course) accompanying of a technical documentation. A person dedicated to the documentation we join us. He is currently working on updating all the documentation and wiki.

Vincent

[stevenjm]

my honest opinion is to get rid of smarty altogether. write better php and use template tags that we can embed in a main template file and include files for the other pages.

much easier to work with and as long as prestashop remains based around smarty it remains too hard for most to theme effectively.

[shoulders]

as an amateur webdeveloper this template upgrade sole goal should be to allow the easy transistion between prestashop versions without having to spend hours upgrading template files, even between major versions ie 1.4 --> 1.5.

i wrote up my idea to have a similiar system to the a joomla template framework, see this link.

http://forge.prestashop.com/browse/PSCFI-1625