Hello, some questions about spryker product attributes in spryker docs there is a recommendation h

UPWG9AYH2

Hello,

some questions about spryker product attributes

in spryker docs there is a recommendation handling product attributes

The attribute mechanism is only recommended if the information stored is for display purpose only. As soon as you want to program against it, we recommend extending one of the four tables.

What does this exactly mean? As far as i understand:
Just for displaying something like color:black, size:5, score:11 … simple key value pairs are meant that gets iterated by its key value in the corresponding template. You have not really control of styling etc since the keys are generic (the expected key can be there but also can be abscent).

However, if it is some kind of information that is directly addressed and handled extra in a template (like the “description” field), it should be some extra column in the db, so that its definitely addressable in the template? Is that correct?

Another question: what is the recommendation here, saving formatting stuff along the fields? I saw some fields having HTML tags, other not. Like for description etc. especially considering elasticsearch full text search etc.

Best regards

Alberto Reyer

1. Product Attributes
   As the one who implemented the concept on Spryker side, yes it’s correct.
   If an attribute is only displayed put it to attributes. If an attribute will be used for a certain behavior add a column (e.g.: size > 5 will display an additional banner, than size should be an own column in DB).
   In the current project we didn’t created separate columns as we ensure via PIM that all products have a standard set on attributes we can program against and use defensive programming to check if an attribute is available before we use it. But this is mainly due to the fact that at the beginning we weren’t aware which attributes are common and which are specific.

2. Description formatting
   That pretty much depends. I would store formatted text in an abstract formatting language (e.g.: markdown) so the frontend could add additional styling. Putting full formatted HTML in there should be avoided. For putting descriptions into search I would rather remove all markup and only add plain text so the index does not include things which are never searched for or could lead to wrong results (e.g.: typo h3> would show all products with a description including a

<

h3> html tag instead of a product named *h3).

UPWG9AYH2

Thanks a lot for your input. I think this is useful input when it comes to a decision for the product data model and can save a lot of headache especially when it comes to implement logic based on certain attributes

Andriy Netseplyayev

Also, regarding HTML in attributes: you can also think of using Glue API and external frontends at some point. In that case, HTML in the response might be undesirable. But as a part of the product description - if that’s the way of managing it - you can have it..

UPWG9AYH2

In the current project we didn’t created separate columns as we ensure via PIM that all products have a standard set on attributes we can program against and use defensive programming to check if an attribute is available before we use it. But this is mainly due to the fact that at the beginning we weren’t aware which attributes are common and which are specific.

@UL6DGRULR one question. So, what would you do differently when you know the common set of attributes in advance?
For example, we have some kind of “bullet points” which is just a plain list of short product infos … now this could be saved as an attribute (simple comma separated list in an attribute “bullet_points”) and do some defense programming as you already mentioned (in template “if attribute.bulletpoints is not empty …“). Twig would be responsible for disassemble the string and print it as a proper list
But It feels cleaner to have this as an extra column on the product localized attributes table but i noticed also much effort to get this into frontend then … you need to extend the table, the concrete transfer, the storage transfers etc … also the productviewtransfer … also extend all the mappers and logic in between here
Considering this, it seems that doing some defensive checks are much cheaper here in templates but i dont have any experience to estimate the offs on the other side. Since it sounds that you rather would go another way with your latest knowledge, the question
Would you do put this as an extra db column or as an extra attribute?
Best

UPWG9AYH2

One idea (at least for the frontend stuff) i could also think of is to have some kind of “convention” for attribute keys … so if you add an attribute with exact key “bulletpoints”, the editor of this must be aware that the content of this text will not be displayed on the “details” box on the pdp and the content must be a proper formatted list … this is the easiest way i could think of, but also can lead to unexpected behaviour if the user making wrong inputs here

Alberto Reyer

we have some kind of “bullet points”

As they are not used to really programm against but only for display I would put them into the attributes.