Hi Giovanni,
If you have a few designs yo can share to illustrate this requirement, it might help drive the conversation. When I read this I immediately thought of the use of a Vocabulary (called Products) and then categories under it to represent each individual product. Liferay has, out of the box, a portlet called Category Navigation. The best part about this is that the portlet is an Application Display Template (ADT) enabled portlet which means you can use the logic for retrieving the categories for one of more vocabularies and then create your own custom template to render the results. The template, under the hood, is a DDMTemplate, same as you have with a WCM. They can be as simple as just markup with variables for placeholders for where you want to inject the text, or they can be complicated with JS logic and service lookups etc. This to me sounds like it might be the best option for creating a hierarchy .. and if you need a WCM for each product you can set the category on the WCM and then look up the assets that are stamped with that category. From the assets you can get the WCM entries and using Liferays API you can retrieve the markup for that entry using whichever WCM template you want. The beauty is that using something like this for an approach leaverages feature that Liferay gives you and that they support. Read: no real customization. It's also all runtime configuration management from template definitions to creatin the content items.
There are lots of options. Page templates are definitely a good resource, though I personally have not had occasion to use them often -- and I still maintain that I am unsure it would be the right choice for you anyway. Again, if you have a visual you could share, that'd really help
..
Actually I was not thinking to those pages for dynamic contents like news, but for a product catalogue. There will be two types of pages for which I though to adopt page templates: the first one is for presenting a family of products, for which I am thinking to design each page with a series of web contents to introduce the family and, below, the list of all products of that family (by including an asset publisher). For this kind of page, using a page template is convenient because the configuration of the asset publisher is simpler. And, if I need to change the structure or layout of those pages, I can directly act on the page template ad propagate it to all those pages. Otherwise, I will need to edit them one by one.
If you have a few designs yo can share to illustrate this requirement, it might help drive the conversation. When I read this I immediately thought of the use of a Vocabulary (called Products) and then categories under it to represent each individual product. Liferay has, out of the box, a portlet called Category Navigation. The best part about this is that the portlet is an Application Display Template (ADT) enabled portlet which means you can use the logic for retrieving the categories for one of more vocabularies and then create your own custom template to render the results. The template, under the hood, is a DDMTemplate, same as you have with a WCM. They can be as simple as just markup with variables for placeholders for where you want to inject the text, or they can be complicated with JS logic and service lookups etc. This to me sounds like it might be the best option for creating a hierarchy .. and if you need a WCM for each product you can set the category on the WCM and then look up the assets that are stamped with that category. From the assets you can get the WCM entries and using Liferays API you can retrieve the markup for that entry using whichever WCM template you want. The beauty is that using something like this for an approach leaverages feature that Liferay gives you and that they support. Read: no real customization. It's also all runtime configuration management from template definitions to creatin the content items.
The second one is for the product pages. I understand that these ones can be also created like articles, and presented by a display page. But, in this case, will I be free to customise a single product page deviating from the display page layout? I mean, all products will not have the same complexity: some are more complex and need more contents like videos, pictures, a list of technical data, and other dynamic elements. Will a display page allow this kind of flexibility? If so, when page templates are really fundamental and cannot be subsituted by a display page?If I understand you correctly, then you should still be able to achieve this with a single display page. Ideally your Product (Structure) is a superset of all your different views. When the content admin creates a new (product) item, they fill in the fields that are applicable. So in the case of a Video its x,y,z but for a pictures it's a,b,z etc. What you are describing, from what I understand, is the idea that different products will render differently -- but that is where I love Liferay's WCM. You can create a Video Product Template, a Article Product Template, a Summary Video Template etc and in each of them you craft the view using whatever markup you want and choosing the WCM fields you need. With this approach, the single display page is still valid -- you have a layout applied of 70/30, your content renders (based on the template) in the left hand column, your adds and promos and whatever render in the right. The right hand rail is configured as part of the display page so you don't need to worry about it. If you need the content there to be reactive based on the article on the left, then you can use portlets that Liferay provides (like the Asset Publisher) or custom plugins you write to leverage public render parameters like tags and category ids so that they choose their content dynamically as well.
There are lots of options. Page templates are definitely a good resource, though I personally have not had occasion to use them often -- and I still maintain that I am unsure it would be the right choice for you anyway. Again, if you have a visual you could share, that'd really help
..
Hi Giovanni,. But, being such a big product means that there are often several ways to solve the same problem and it often takes quite a bit of experience to understand the subtleties that will help decide which of the several options is the BEST approach in a given case. A lot of it just comes from practice and experience and I think, as developers, we tend to gravitate towards the things we already know which often means trying to force something to do that it was not intended for.
. I think the right answer would start by understanding how many products you currently have and how much they vary from one to another. I have no experience adding products in Amazon so I am not sure how they handle this scenario but I know on some other commerce platforms they use a generic "product attribute" list as the way to hadle these sort of variations. So could do something similar by creating a "product attribute" field on your structure and then marking it as repeatable so that you can add as few or as many as you need. But then you would have to introduce into your template(s) the logic to detect and handle them. I think the main challenge in this case is that your structure is no longer "structured" in that you won't necessaarily know FOR SURE that you have this field or that one.
An alternative might be to have a "Product" structure that contains the fields that are common to all products. So things like a title, description, price, image. Then for each of your concrete product types you can create a new structure for that product type that has a parent structure of "Product". This means that for you "Phone" product you would then add the 6 or whatever fields that you need to describe the phone, where are for the ablum you could create a repeatable field called track. Each product could then use it's own WCM template allowing you to render them completely differently but still leverage the same display page to show them all when the user clicks on an item.
The one thing I mentioned above is important though. The approach you take should take into consideration how many products you have now and also if your catalog will grow, then by how much and how would the pattern you choose look in the future. You don't want one strucutre with a million field options that are all optional, but you also don't want to have 100 structures to choose from when creating content. In truth, I feel, there is a real art to this part of the process and finding the balance can be hard. One thing I like to do is create a matrix with my products across the top and the attributes as rows. I think fill in the matrix to see how much overlap there is between the items. I then use another colour to predict growth and again try to assume the overlaps. At that point you will have a sense of what it would look like and you can strat to decide how you can chunk out your products. My guess is that you will likely end up with a parent structure and then buckets where largely overlapping products are grouped together under a single structure that has a mix of required and optional fields. So for example ..
Product
|
|---- Electronics
|---- Clothing
...
because all clothing have size, colour, etc. So shirts, pants, shorts, sweaters, it makes sense to house them as a single concrete Product type, and then provide multiple templates or logic in the templates to handle the optional fields.
Hopefully this explanation hasn't been too theoretical?
..
I understood what you said and I will talk to that my colleague in order to understand why he insisted on using page templates, since very likely we could avoid them and, therefore, all those limitations that generated that incompatibility with page versioning and stagingIt could be just a case that he is not very familiar with Liferay himself. Liferay is a huge product with so much more than just content managment. In fact I often have to laugh a little under my breath when I hear people comparing it to tools like word press or drupal... or even Adobe Experience manager. Truthully, when I hear these things, it just confirms for me how little the speaker knows about the product
. But, being such a big product means that there are often several ways to solve the same problem and it often takes quite a bit of experience to understand the subtleties that will help decide which of the several options is the BEST approach in a given case. A lot of it just comes from practice and experience and I think, as developers, we tend to gravitate towards the things we already know which often means trying to force something to do that it was not intended for. Just to give you more info about the product pages, I have not designed them yet but the idea is to have that flexibility that you can see comparing some product pages on Amazon's website, for example https://www.amazon.it/gp/product/B01M03MJRQ and https://www.amazon.it/gp/product/B07D8DPBDJ : they have a similar common structure, but they include some other different static or dynamic contents depending on the type of product (for example, a tracklist in the second one).Hmm -- I see. Well, there are a couple of ways to handle this
. I think the right answer would start by understanding how many products you currently have and how much they vary from one to another. I have no experience adding products in Amazon so I am not sure how they handle this scenario but I know on some other commerce platforms they use a generic "product attribute" list as the way to hadle these sort of variations. So could do something similar by creating a "product attribute" field on your structure and then marking it as repeatable so that you can add as few or as many as you need. But then you would have to introduce into your template(s) the logic to detect and handle them. I think the main challenge in this case is that your structure is no longer "structured" in that you won't necessaarily know FOR SURE that you have this field or that one. An alternative might be to have a "Product" structure that contains the fields that are common to all products. So things like a title, description, price, image. Then for each of your concrete product types you can create a new structure for that product type that has a parent structure of "Product". This means that for you "Phone" product you would then add the 6 or whatever fields that you need to describe the phone, where are for the ablum you could create a repeatable field called track. Each product could then use it's own WCM template allowing you to render them completely differently but still leverage the same display page to show them all when the user clicks on an item.
The one thing I mentioned above is important though. The approach you take should take into consideration how many products you have now and also if your catalog will grow, then by how much and how would the pattern you choose look in the future. You don't want one strucutre with a million field options that are all optional, but you also don't want to have 100 structures to choose from when creating content. In truth, I feel, there is a real art to this part of the process and finding the balance can be hard. One thing I like to do is create a matrix with my products across the top and the attributes as rows. I think fill in the matrix to see how much overlap there is between the items. I then use another colour to predict growth and again try to assume the overlaps. At that point you will have a sense of what it would look like and you can strat to decide how you can chunk out your products. My guess is that you will likely end up with a parent structure and then buckets where largely overlapping products are grouped together under a single structure that has a mix of required and optional fields. So for example ..
Product
|
|---- Electronics
|---- Clothing
...
because all clothing have size, colour, etc. So shirts, pants, shorts, sweaters, it makes sense to house them as a single concrete Product type, and then provide multiple templates or logic in the templates to handle the optional fields.
Hopefully this explanation hasn't been too theoretical?
..
Community
Company
Feedback