Frontend Code Cleanup Effort

[opal_froot]

I've worked a lot with Prestashop and have developed my own base installation. The problem I had straight away with prestashop is working with the default style and tpl's.

I mean the CSS has been globbed and optomised to a point of being bad to decode and work with. Surely if the approach to coding here is 'modular' there should be a modular approach to pagination and page styling ? Anyway this is something I have begun to tackle - each page has its own sets of images, JS, and CSS. The next step is to work on smart caching and globbing of these files.

My second woe was dealing with the default TPL files. The use of SMARTY is fine if you like using the features of smarty over straightforward PHP. For example to produce a loop within a TPL i need to write a little piece of code to do this, this then fills in the blanks (via search and replace!!) and caches the file. I could achieve the same with a similar php loop - 1 language, less confusion and less processing overhead. If you look at how other systems do this many wont use a template engine like SMARTY - its slow and incumbent. Something like Drupal's phptemplate which is lean and mean (passes a master array of variables to each template file which in turn does what it likes with the vars).

I feel Prestashop has a ton of great features but there is the risk it will spiral a little like oscommerce did (over time due to lack of focus the codebase became very messy and unmanageable) . If anyone wants to help with moving away from SMARTY and completing the code for conditional style and JS includes ( with caching/globbing ) please get in touch .

I'd be interested to see what others think about my suggestions.

PS Other things to consider :
A form API ( for backend form production and handling - currently very messy)

[tomerg3]

I personally like Smarty, it makes life much easier for people that are not proficient with coding.

It's also very good design to separate php code from the actual page design.

It takes a little getting used to, but you can pretty much do anything you want in php using smarty.

[Kaihaku]

I've worked a lot with Prestashop and have developed my own base installation. The problem I had straight away with prestashop is working with the default style and tpl's.

I mean the CSS has been globbed and optomised to a point of being bad to decode and work with. Surely if the approach to coding here is 'modular' there should be a modular approach to pagination and page styling ? Anyway this is something I have begun to tackle - each page has its own sets of images, JS, and CSS. The next step is to work on smart caching and globbing of these files.

I certainly agree. I don't understand why global.css is not better formatted. PrestaShop is already difficult to theme because of its approach to modules, the confusing state of the global.css only increases that disadvantage. Better descriptions, commented divisions, and even division via @import could vastly improve the situation.

My second woe was dealing with the default TPL files. The use of SMARTY is fine if you like using the features of smarty over straightforward PHP. For example to produce a loop within a TPL i need to write a little piece of code to do this, this then fills in the blanks (via search and replace!!) and caches the file. I could achieve the same with a similar php loop - 1 language, less confusion and less processing overhead. If you look at how other systems do this many wont use a template engine like SMARTY - its slow and incumbent. Something like Drupal's phptemplate which is lean and mean (passes a master array of variables to each template file which in turn does what it likes with the vars).

I'm still new to Smarty. I was asking about the advantages and disadvantages of Smarty in my initial thread here but no answer was given. There doesn't seem to be much consensus on it.

I feel Prestashop has a ton of great features but there is the risk it will spiral a little like oscommerce did (over time due to lack of focus the codebase became very messy and unmanageable).

Interesting. I wonder if others share this view?

If anyone wants to help with moving away from SMARTY and completing the code for conditional style and JS includes ( with caching/globbing ) please get in touch .

If only I had the time. Good luck!

I'd be interested to see what others think about my suggestions.

Sounds great to me. PrestaShop has great features, an awesome backend, and a handy frontstore but it could use some polishing under the hood.

[opal_froot]

I personally like Smarty, it makes life much easier for people that are not proficient with coding.

It's also very good design to separate php code from the actual page design.

It takes a little getting used to, but you can pretty much do anything you want in php using smarty.

I agree SMARTY is convenient however writing a loop in SMARTY is less convenient than writing a loop in PHP. The overhead of the search replace mechanism smarty uses is also taxing. Finally as for code seperation - this doesn't really hold water - you still apply logic within a theme file which indicates lack of seperation - all your doing here is seperating logic into a seperate syntax/construct.

To show what I'd like to be able to do.

The theme file is object buffered and passed a global theme variable such as (passed from the relevant php file) :

array{
 'css' =>array('your_css'),
 'js' =>array('your_js'),
 'header'=>header_content,
 'body'=>body_content,
 'footer'=>footer_content
}

(simplistic I know).

All the formatting and logical operations are done before the global var is passed hence we end up with a them file that looks like :

<html>
 <head>
    {prepare css + js inclusions + cache if not already done so}
 </head>
 ......
 ......
 ......
 ......
</html>

(simplistic again)

Just think this would make things a lot cleaner. Anyway thanks for the input look forward to hopefully getting more feedback.

[Kaihaku]

I spent a significant amount of time this week working on a custom template for PrestaShop; one quite different from the default featuring better screen reader support, a fluid "holy grail" style layout to match displays from monitors to iPads, and easily resizeable text.

Having broken apart and reassembled PrestaShop styling several times in this process, I feel the need to affirm that the current styling system is a great disadvantage.

[lp.boe]

I just wanted to give a big thumbs up to your effort. I am currently suffering a great depression over the impracticality of Prestashop theming. The fact that it out of the box looks like what it does is screaming for a proper overhaul of the basic layout concepts. Just the effort you have to go through to strip down the design to a minimalistic, simple, imageless layout.. the headers of boxes are friggin' gifs!

It breaks my heart to say so dear Prestashop developers, but it's just horrible! I feel it might just be one most pressing issue right now to. If they can't put this greenpink fetish of theirs away, include two themes with the package. One clean you can really build off, and the one now as an example of a possible approach to theming.

One thing is discussed here to rebuild the entire structure of the layout, and even get rid of the Smarty. I think Smarty is a good thing. It lowers the skills required to modify and build themes, which allows more people get involved in theming, which in my logic is very positive for a opensource software. Advanced users are advanced enough to either work around things, or like you are doing, just rewrite the whole thing, hehe.

Not that advanced users should be neglected, absolute flexibility and possibility within certain boundries should always be top priority

I have forgotten what I initially wanted to point out atleast 10 times since I started replying, so I'm just gonna go ahead and post this, subscribe to this thread and get back to this. Cuz this really needs some attention.

Would love to see what you're working on, or atleast hear how you're thinking of organizing the whole thing.

Keep up the good work!

[MrBaseball34]

I don't like Smarty as it makes you learn two different syntax's, when only one is needed. I'd much rather they do something like the method that CodeIgniter uses to pass variables to the views (templates).

And as far as the themeing engine is concerned, Drupal has an excellent themeing engine (PHPTemplate) and it would greatly benefit the PS designers to check it out, it is freely available.

Also, many, many users would like to see a huge modification in the upgrade process, as well.
See my post here: http://www.prestashop.com/forums/viewreply/277624/

[lp.boe]

After alot of thought I'm starting to see your point about SMARTY MrBaseball34, and not being familiar with PHPTemplate I'd very much like to hear your ideas on how this could be implemented, and how this would work in terms of working with theming. I'd do some reading up on it but time is unfortunately a resource I am in short of.

I'm also very interested to hear your estimates on what kind of funding would be needed for such an operation

Keep in touch!

[MrBaseball34]

Personally, I've begun undertaking writing my own e-commerce solution in CodeIgniter. I have not begun on anything visual as yet so I don't know if I'm going to use something like PHPTemplate or something else or even roll my own. I don't really have a lot of time and this will take a long time to build but at least I am taking great aim at making it into a framework that has pluggable modules as well as pluggable templates.

The MVC architecture of CodeIgniter allows you to do those things without even thinking about it. It makes you adhere to rules that help out in the long run to make your system more configurable. I will not use Smarty, per the statement above. And the DB backend will also be pluggable so you can switch from PostgreSQL to mySQL to MSSQL to Oracle with nothing but changing a configuration file.

I also plan on supporting HTML5 and CSS3 from the ground up as it allows a lot of things that aren't currently available. Browser innovations are moving so fast that the market needs to force people to upgrade. When you include backwards compatibility, people get complacent and don't upgrade their browsers. There is absolutely NO reason to use IE6 today so why even support it?

Now, forward thinking like this could make Prestashop a very viable solution but this means that the entire codebase would need to be rewritten. I don't think they are up to that task and don't think they will take the time. They have sunk into their own ways of doing things and just like osCommerce, will sink into oblivion because of their lack of flexibility with the market. Other cart software with that forward thinking posture, like TomatoCart are going to quickly eat up their market share and then where will they be, just another abandoned SourceForge download.

[rocky]

I was also considering rewriting the default PrestaShop theme using HTML5 and CSS3, then adding a module with a configuration page that lets you change the CSS colours, gradients and rounded borders in the theme without modifying any graphic files. I was planning to use PIE.htc to enable compatibility with IE6 though, since it still had a large market share. Until that share drops, clients will want it supported. Let me know if you need any help in your endeavour.