How to configure and adapt Aimeos based shops as developer
Forum rules: Always add your Aimeos and PHP version as well as your environment (Linux/Mac/Win)
#4070 by pdanzinger
26 Mar 2017, 16:03
Hi,

I'm currently adapting aimeos for a webshop. Now i want to show some product attributes (more specifically the attribute's image) on the product cards, e.g. in the list view, suggested and recently viewed products, etc.
Since it is always rendered via client/html/templates/common/partials/products-default.php I somehow need to make the attribute data available there.

So far I've adapted the domains that are fetched with the product (added 'attribute' to both client/html/catalog/domains and client/html/basket/related/bought/standard/domains, while setting client/html/catalog/detail/domains to the default from the detail html client), but that only loads the attribute data itself, not the associated media.

Since the "context" variable is not available in views, it's impossible to create managers there, so the only "standard" solution I see right now is adapting clients and templates to load the attribute media data and transfer it to the partial. but that would require overriding at least 6 files (since the partial is used by basket/related/bought, catalog/detail and catalog/lists).
One hack would be to put the context into a global variable and use it in the view. Not very elegant, but nobody has to build upon my code.

Are these the only potential solutions? Or am I missing something?
In case it's relevant: I'm using aimeos 17.3 with TYPO3 7.6.
#4071 by aimeos
26 Mar 2017, 21:15
Aimeos doesn't pass the 3rd level data (references for attributes, media, prices and texts objects) to list views for performance reasons. If you really think you need it and there's enough space in your design of the lists for this, you must fetch that data and pass it to the templates.

Please do never (!) pass the context object into a template or make this object otherwise available in a template. Aimeos makes it as hard as possible to pass that object or data provided by that object to templates for good reasons! Templates are only meant for displaying data and the controllers must provide that data. That separation enforces a clean code structure that can be maintained for years. Shop software is something that is running for years and usually have to be maintained by different people over the time, so this is very important.

To minimize the amount of work, create a decorator, implement the "getBody()" method where you call the underlying object and use "$this->getView()->get( '...' );" to retrieve the assigned product lists afterwards. Unfortunately, there will be three different variable names like "itemsMediaItems", so you have to check for all of them. Then you can use "searchItems( $criteria, ['media'] )" to get the attribute objects including the media data and pass it to the views. In the templates you have to hand your new variable over to the product partial but you adapt the templates in your own project specific extension anyway.
#4078 by pdanzinger
27 Mar 2017, 11:09
Thanks for the fast response.

Regarding the first points, in this instance some attributes are necessary for "non-expert" users to distinguish the products from one another. The performance likely won't be an issue either.

I am aware that passing the context into a template is a violation of the MVC-ish design principles of aimeos, and that even though it's a small shop and I'm certain I will always maintain it myself, it's in no way an ideal solution.

Using one decorator is a good idea. Still, overriding a couple templates is still not ideal for me, since I'd have to manually check each one for changes when upgrading aimeos. But extending the managers seems to be quite complicated, so maybe I'll just go with overriding the templates.
#4084 by aimeos
27 Mar 2017, 16:18
The templates are meant to be overwritten and doesn't change much after the beta phase (2017.04 will be the first stable version for 2017). Major changes will then only occur in the first 2018 release. This means, you can safely upgrade from 2017.04 up to 2017.10 even with modified templates.