What about before programming in Prestashop?

I am computer scientist and programmer web. Since childhood always liked because you do not solve problems but find simple and practical solutions to problems previously solved... You can say that I like my job and I spend quite a few hours of my life even after finishing the day (one never can tell that he knows everything).

I've been 10 years working in the web world that surrounds to java and implement from scratch with php Prestashop was not complicated to me, but have to devote time to familiarize yourself and get to know all classes, drivers, etc... It's like throw yourself 10 years playing an only car and, suddenly, take another. You know what serves each pedal and although you get the car to do what you want, you're aware that costs you dominate a little operation (the clutch is harder or softer, or marches are shorter or longer...) and you don't feel as safe as you would be on your old car.

I remember that before making my first module serious for Prestashop (which by the way was for Alabaz, is called megacanones and I am very proud :)), had to make several simple modules to perform tests on the basis of what was learning (installation, translations, hooks, classes, drivers and overrides...). I based mostly on Prestashop manuals, code that was found in the other modules depending on the theme that was investigating (by the way, living the open source, is the best way to learn and I think that it is the main reason why it was created).

Once you see that the "car" seems to work, then you already do the actual approach of the module that you want to really.

Develop a module for PrestaShop involves many hours of planning and research

Previously, there must be an outlet of requirements and be captured on paper, typically performed when you interview with a famous (what, how, when...) only that in this case for our module. It would be something like the planes where to look if you see that the tower is distorted. Above all, must be very clear what is the purpose of the module, which processes should be done to achieve this, what data gets and what and how are their results (database, screen...).

Subsequently, it is possible that we are adding more requirements or you go correcting certain points of them, but there is already a basis on which to work and always will be small changes.

Continuing with the module of megacanones an example of this socket's requirements would be the following (slightly condensed):

1. a cannon is an increase in the price of the product. This increase, may be included in the price displayed or included then. You should also have the option of adding a tax. The canon also must contain a text that defines it. (this point is the clearest to know which input data need)

2. the canon should be visible at the time of purchase and should be added next to the product to make the purchase, showing that it added together with the product in the cart and checkout to make customer aware at all times of what is paying (at this point the processes that perform the data entered are reflected).

3. in addition you must leave on the invoice, in the email and the order (this last point reflects quite well what commenting on who and how of the results, as there are three different ways to translate it).

We have not even started to touch code to make our module and there in our planning duty several hours employed... And which are missing, then it is useful to perform a comprehensive study (capturing it in paper also) of:

• data/results must be maintained and where will perform their display and conservation (forms either backoffice or the frontoffice, any specific page of prestashop... etc). In this part, it is even recommended to do a design (on paper) of the form itself or the display.
• prestashop pages affect our functionality, which templates are used, and what hooks are available, and already more expert mode, classes and controllers.
• This task also with other sites to take into account, such as other modules, mail... If necessary clear.
• Above all, try to include all the functionality of prestashop so something does not escape us and the module does not work correctly. For example, if we are doing a feature on the checkout it must be borne in mind that prestashop has an option by default for a step or 5 steps and depending on this, run some drivers and classes.

Once we have clarified these points, just have to add to the document that we are conducting our own study of what we are going to perform. At this stage, we are already looking at critical points from our perspective and expertise and, therefore, to define the most feasible solution to perform each of the features; whether to engage in a hook, make an override... or simply to define our own classes and data contained therein (without developing them clear).

For example (without reaching very technical aspects), in the module megacanon that I said this could be identified:

• the data of the Canyon. Class defined by us => Canon.php
• It was to have a form to enter the canon data and associate it with the product (backoffice form): this part is to implement with the hook adminproductsextra and a helperform form.
• Its main display was on the page of the product (frontoffice): Product.php, ProductController.php, product.tpl
• It should be added to the cart along with the product: Cart.php and CartController.php
• but then should be displayed together with the product in the cart, checkout, orders, invoices and mail... etc. (this part left as I can be extended too).

You should always seek the best solution even when not all the same

This latest study is always very personal, as every developer has their preferences and their methodologies (even if some are not more correct), and there will always be someone who sees it and says - "I would do it as well". We must of course, be open to opinions, tastes and even any comments, because it is possible that all this will help us to improve or see a problem with which we had not counted. For example, I am not in favour of overwriting templates smarty (tpl) already defined by prestashop; in part, it is the easiest way and in time would cost not only, but we are a little caught and limited to any modification of this template externally.

A clear example of what comment is the display of the canon in the cart, in which the simplest, was by overriding the related template and add two or three simple lines in which was canon and its amount. At the end, and as I said, due to my way of thinking (probably someone had chosen the other option), took advantage of a hook that had already set to do it all by javascript, which made me write more code and even considerably bent my effort and my time; but my goal was not finished before independence this part a bit of prestashop.

Everything that a priori seems a waste of time, will provide us with much subsequent programming of the module because we are reflecting on the role that we are going to play / create later. Obviously, it is possible that at the time of the development itself, we find any problem or doubt that we had not arisen, and we obliged to vary part of requirements and/or approach to solving this problem. But I guarantee that it will always be a problematic small compared to any other form of programming (from ensayo-prueba - error is fine when you are learning but then use loses effectiveness when because the system it dominates a little).

I've tried not reach technicalities because I want that this post is already read not by computer, but by people who like this world of Prestashop and stings them the interest and the curiosity to go one step further.

I hope your comments.

A greeting,

Fees for products in Prestashop module

This module allows the allocation of cannons or options extras to our products PrestaShop, configuring them completely Depending on our needs and our products.

Ver pantallas

€360.25

AWPrime €435.90 info View more