Jump to content

Edit History

theillo

theillo

So it's been 2.5 years since this was posted.

I'm in the process of trying to upgrade my custom PS 1.6 theme to PS 1.7

Which is a lot of work by the way. There is 0 backwards compatibility. Hundreds of developer hours are needed to make this upgrade, if you have a custom theme (a theme that it once took hundreds of hours to design in the first place)

It was supposed to be for the sake of "better software design", which I'm okay with, and why I ultimately decided to make the investment and upgrade my shop.

There are certainly many improvements to the software design, and there are some really good new features in PS 1.7

That being said, there are also some major flaws, and much of the code is anything but modular, it violates several software design principles, and even goes against the very architecture it's build on (this architecture was my reason for choosing prestashop in the first place, many years ago)

One example, the {render} command totally destroys the MVC architecture. Suddenly the template file (view) acts as a controller by using this command. 

Right of the bat, that's the biggest flaw, and the documentation can back it up, pretty much admitting that {render} was a workaround created only for the checkout page and for the login form. Here's a quote from the documentation:

Quote

Some elements coming from the controller might need to be passed to this function. So far, it is only used for forms (customer information and checkout).

https://devdocs.prestashop.com/1.7/themes/reference/smarty-helpers/#render

Way to go, that's good "documentation"! Some elements might need to be passed to this function. Alright, makes things perfectly clear for any developer unfamiliar with the matter. Thanks a lot! Way to improve the software design! [/sarcasm]


And just to give one more example: This whole concept of {block} is a good idea, but why  would you keep the naming conventions so inconsistent that block names are used multiple times in different files (e.g. block cart_summary appears twice in checkout.tpl) but then they're referring back to differently named template files (e.g. cart-detailed.tpl is the template file for the block cart_overview. Why not use cart_overview.tpl ?). That might seem like a petty minor flaw, and I wouldn't complain, but things like that are quite noticable thoughout the entire code.

Who's making these decisions that give me a headache multiple times a day???

As a Theme developer I'm not only super confused trying to untangle this mess and make it work for my customizations, but I also have very little creative freedom, especially when it comes to the login form for example, and the checkout page. 

The login and account creation forms are totally entangled with the variables they require from their controller, so how the heck can I display them again? 

It was specifically stated in the documentation:

Quote

This reduce code to the minimum, without any repetition.

https://devdocs.prestashop.com/1.7/themes/reference/template-inheritance/

When you're making a platform like this, and you're trying to allow for creative freedom, then shouldn't you consider these things? 

For example: Why dump all form elements into ONE file "_partials/form-fields.tpl"? Is it really neccessary to load the whole tpl file containing every possible form element every time? 

Plus: you're not even doing it! The contact page and the password recovery page do not even make use at all of the form-fields.tpl.

And also: If there's a form field I don't want to use, or for whatever creative design decision, I wanna change the order of my fields... Guess what? I can't! Because it's pretty much determined for me and has all been packed into ONE variable, which the theme is for-looping over. What's the point of making MVC, when you could just let the controller spit out the HTML code? That's bascially what's happening as you pack all this design related information into one big array, and then loop over it to render the HTML code.

Just take a look at checkout/checkout-process.tpl 

{foreach from=$steps item="step" key="index"}
  {render identifier  =  $step.identifier
          position    =  ($index + 1)
          ui          =  $step.ui
  }
{/foreach}

Does this look like a VIEW? A template file? Should a Web Designer really have to deal with this? There's not a single line of HTML code in this.

Looks more like CONTROLLER logic to me. VIEW is HTML, CSS, and maybe some JavaScript. You're literally using a templating language to run complex controller logic, that should stay in PHP. You discourage the use of overrides, then please make it possible to NOT use overrides. This is not a matter of "there aren't enough hooks". It's a matter of not implementing the MVC architecture properly. Separation of concerns.

Again: Who's making these decisions? Who's considering the creative freedom for module developers and theme designers? Who's considering how self-documenting the code is? (Because let's face it: Even though some effort was put into it, the documentation is basically non-existent. Why don't we just write code that can be quickly deciphered by humans? Then we don't have to worry about creating  documentation, either, because it would be self explanatory and self evident from the code alone) 

 

And these are just some of the many problems I'm stuck on. If anything, PS 1.7 has more complicated software design, because it's extremely difficult for a developer who's unfamiliar with the system, to understand it quickly. I've been developing stuff for prestashop for 6 years now, why is it that I can't quickly do a simple theme upgrade? It was only 1.6 to 1.7, not 2.0, or is it??

 

The reason I came across this threat, is because I'm also trying to get my simple, convenient one page checkout working again.

I wanna make sales, so I wanna keep things as eeeeassy as possible for my customers. The only button I want them to press is the "PAY NOW" button. 

Maybe that's another software design principle that the prestashop development team forgets about: K.I.S.S.!

 

Does anyone familiar with the architecture have a recommendation for me?

I only wanna get my login form on the checkout page, and the payment form.

How can I get a one page checkout, where I only have "create your account or log in" (reusing my original login form from the login page) and then the payment module with credit card info?

When I use include, trying to re-use my login form template file, I'm missing the form field definitions. When I use render, I'm missing some UI variable which I have no clue where that comes from, because render is CONTROLLER LOGIC and not VIEW logic. 

theillo

theillo

So it's been 2.5 years since this was posted.

I'm in the process of trying to upgrade my custom PS 1.6 theme to PS 1.7

Which is a lot of work by the way. There is 0 backwards compatibility. Hundreds of developer hours are needed to make this upgrade, if you have a custom theme (a theme that it once took hundreds of hours to design in the first place)

It was supposed to be for the sake of "better software design", which I'm okay with, and why I ultimately decided to make the investment and upgrade my shop.

There are certainly many improvements to the software design, and there are some really good new features in PS 1.7

That being said, there are also some major flaws, and much of the code is anything but modular, it violates several software design principles, and even goes against the very architecture it's build on (this architecture was my reason for choosing prestashop in the first place, many years ago)

One example, the {render} command totally destroys the MVC architecture. Suddenly the template file (view) acts as a controller by using this command. 

Right of the bat, that's the biggest flaw, and the documentation can back it up, pretty much admitting that {render} was a workaround created only for the checkout page and for the login form. Here's a quote from the documentation:

Quote

Some elements coming from the controller might need to be passed to this function. So far, it is only used for forms (customer information and checkout).

https://devdocs.prestashop.com/1.7/themes/reference/smarty-helpers/#render

Way to go, that's good "documentation"! Some elements might need to be passed to this function. Alright, makes things perfectly clear for any developer unfamiliar with the matter. Thanks a lot! Way to improve the software design! [/sarcasm]


And just to give one more example: This whole concept of {block} is a good idea, but why  would you keep the naming conventions so inconsistent that block names are used multiple times in different files (e.g. cart_overview appears multiple times) but then they're referring back to differently named template files (e.g. cart-detailed.tpl is the template file for the block cart_overview. Why not use cart_overview.tpl ?). That might seem like a petty minor flaw, and I wouldn't complain, but things like that are quite noticable thoughout the entire code.

Who's making these decisions that give me a headache multiple times a day???

As a Theme developer I'm not only super confused trying to untangle this mess and make it work for my customizations, but I also have very little creative freedom, especially when it comes to the login form for example, and the checkout page. 

The login and account creation forms are totally entangled with the variables they require from their controller, so how the heck can I display them again? 

It was specifically stated in the documentation:

Quote

This reduce code to the minimum, without any repetition.

https://devdocs.prestashop.com/1.7/themes/reference/template-inheritance/

When you're making a platform like this, and you're trying to allow for creative freedom, then shouldn't you consider these things? 

For example: Why dump all form elements into ONE file "_partials/form-fields.tpl"? Is it really neccessary to load the whole tpl file containing every possible form element every time? 

Plus: you're not even doing it! The contact page and the password recovery page do not even make use at all of the form-fields.tpl.

And also: If there's a form field I don't want to use, or for whatever creative design decision, I wanna change the order of my fields... Guess what? I can't! Because it's pretty much determined for me and has all been packed into ONE variable, which the theme is for-looping over. What's the point of making MVC, when you could just let the controller spit out the HTML code? That's bascially what's happening as you pack all this design related information into one big array, and then loop over it to render the HTML code.

Just take a look at checkout/checkout-process.tpl 

{foreach from=$steps item="step" key="index"}
  {render identifier  =  $step.identifier
          position    =  ($index + 1)
          ui          =  $step.ui
  }
{/foreach}

Does this look like a VIEW? A template file? Should a Web Designer really have to deal with this? There's not a single line of HTML code in this.

Looks more like CONTROLLER logic to me. VIEW is HTML, CSS, and maybe some JavaScript. You're literally using a templating language to run complex controller logic, that should stay in PHP. You discourage the use of overrides, then please make it possible to NOT use overrides. This is not a matter of "there aren't enough hooks". It's a matter of not implementing the MVC architecture properly. Separation of concerns.

Again: Who's making these decisions? Who's considering the creative freedom for module developers and theme designers? Who's considering how self-documenting the code is? (Because let's face it: Even though some effort was put into it, the documentation is basically non-existent. Why don't we just write code that can be quickly deciphered by humans? Then we don't have to worry about creating  documentation, either, because it would be self explanatory and self evident from the code alone) 

 

And these are just some of the many problems I'm stuck on. If anything, PS 1.7 has more complicated software design, because it's extremely difficult for a developer who's unfamiliar with the system, to understand it quickly. I've been developing stuff for prestashop for 6 years now, why is it that I can't quickly do a simple theme upgrade? It was only 1.6 to 1.7, not 2.0, or is it??

 

The reason I came across this threat, is because I'm also trying to get my simple, convenient one page checkout working again.

I wanna make sales, so I wanna keep things as eeeeassy as possible for my customers. The only button I want them to press is the "PAY NOW" button. 

Maybe that's another software design principle that the prestashop development team forgets about: K.I.S.S.!

 

Does anyone familiar with the architecture have a recommendation for me?

I only wanna get my login form on the checkout page, and the payment form.

How can I get a one page checkout, where I only have "create your account or log in" (reusing my original login form from the login page) and then the payment module with credit card info?

When I use include, trying to re-use my login form template file, I'm missing the form field definitions. When I use render, I'm missing some UI variable which I have no clue where that comes from, because render is CONTROLLER LOGIC and not VIEW logic. 

theillo

theillo

So it's been 2.5 years since this was posted.

I'm in the process of trying to upgrade my custom PS 1.6 theme to PS 1.7

Which is a lot of work by the way. There is 0 backwards compatibility. Hundreds of developer hours are needed to make this upgrade, if you have a custom theme (a theme that it once took hundreds of hours to design in the first place)

It was supposed to be for the sake of "better software design", which I'm okay with, and why I ultimately decided to make the investment and upgrade my shop.

There are certainly many improvements to the software design, and there are some really good new features in PS 1.7

That being said, there are also some major flaws, and much of the code is anything but modular, it violates several design principles, and even the very architecture it's build on (this architecture was my reason for choosing prestashop in the first place, many years ago)

One example, the {render} command totally destroys the MVC architecture. Suddenly the template file (view) acts as a controller by using this command. 

Right of the bat, that's the biggest flaw, and the documentation can back it up, pretty much admitting that {render} was a workaround created only for the checkout page and for the login form. Here's a quote from the documentation:

Quote

Some elements coming from the controller might need to be passed to this function. So far, it is only used for forms (customer information and checkout).

https://devdocs.prestashop.com/1.7/themes/reference/smarty-helpers/#render

Way to go, that's good "documentation"! Some elements might need to be passed to this function. Alright, makes things perfectly clear for any developer unfamiliar with the matter. Thanks a lot! Way to improve the software design! [/sarcasm]


And just to give one more example: This whole concept of {block} is a good idea, but why  would you keep the naming conventions so inconsistent that block names are used multiple times in different files (e.g. cart_overview appears multiple times) but then they're referring back to differently named template files (e.g. cart-detailed.tpl is the template file for the block cart_overview. Why not use cart_overview.tpl ?). That might seem light a petty minor flaw, and I wouldn't complain, but things like that are quite noticable thoughout the entire code.

Who's making these decisions that give me a headache multiple times a day???

As a Theme developer I'm not only super confused trying to untangle this mess and make it work for my customizations, but I also have very little creative freedom, especially when it comes to the login form for example, and the checkout page. 

The login and account creation forms are totally entangled with the variables they require from their controller, so how the heck can I display them again? 

It was specifically stated in the documentation:

Quote

This reduce code to the minimum, without any repetition.

https://devdocs.prestashop.com/1.7/themes/reference/template-inheritance/

When you're making a platform like this, and you're trying to allow for creative freedom, then shouldn't you consider these things? 

For example: Why dump all form elements into ONE file "_partials/form-fields.tpl"? Is it really neccessary to load the whole tpl file containing every possible form element every time? 

Plus: you're not even doing it! The contact page and the password recovery page do not even make use at all of the form-fields.tpl.

And also: If there's a form field I don't want to use, or for whatever creative design decision, I wanna change the order of my fields... Guess what? I can't! Because it's pretty much determined for me and has all been packed into ONE variable, which the theme is for-looping over. What's the point of making MVC, when you could just let the controller spit out the HTML code? That's bascially what's happening as you pack all this design related information into one big array, and then loop over it to render the HTML code.

Just take a look at checkout/checkout-process.tpl 

{foreach from=$steps item="step" key="index"}
  {render identifier  =  $step.identifier
          position    =  ($index + 1)
          ui          =  $step.ui
  }
{/foreach}

Does this look like a VIEW? A template file? Should a Web Designer really have to deal with this? There's not a single line of HTML code in this.

Looks more like CONTROLLER logic to me. VIEW is HTML, CSS, and maybe some JavaScript. You're literally using a templating language to run complex controller logic, that should stay in PHP. You discourage the use of overrides, then please make it possible to NOT use overrides. This is not a matter of "there aren't enough hooks". It's a matter of not implementing the MVC architecture properly. Separation of concerns.

Again: Who's making these decisions? Who's considering the creative freedom for module developers and theme designers? Who's considering how self-documenting the code is? (Because let's face it: Even though some effort was put into it, the documentation is basically non-existent. Why don't we just write code that can be quickly deciphered by humans? Then we don't have to worry about creating  documentation, either, because it would be self explanatory and self evident from the code alone) 

 

And these are just some of the many problems I'm stuck on. If anything, PS 1.7 has more complicated software design, because it's extremely difficult for a developer who's unfamiliar with the system, to understand it quickly. I've been developing stuff for prestashop for 6 years now, why is it that I can't quickly do a simple theme upgrade? It was only 1.6 to 1.7, not 2.0, or is it??

 

The reason I came across this threat, is because I'm also trying to get my simple, convenient one page checkout working again.

I wanna make sales, so I wanna keep things as eeeeassy as possible for my customers. The only button I want them to press is the "PAY NOW" button. 

Maybe that's another software design principle that the prestashop development team forgets about: K.I.S.S.!

 

Does anyone familiar with the architecture have a recommendation for me?

I only wanna get my login form on the checkout page, and the payment form.

How can I get a one page checkout, where I only have "create your account or log in" (reusing my original login form from the login page) and then the payment module with credit card info?

When I use include, trying to re-use my login form template file, I'm missing the form field definitions. When I use render, I'm missing some UI variable which I have no clue where that comes from, because render is CONTROLLER LOGIC and not VIEW logic. 

×
×
  • Create New...