Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Best Practices on detail pages

Avatar

Level 6

Hi,

I'm new to AEM development and I have some doubts on the flow for developing websites using it.

Let's say we have a company site, that has the following structure:

  • Home
    • Products
      • Prod1
      • Prod2
    • Services
      • Service1
      • Service2
    • Contact

On the Products page we will list the child product pages and display some information about the product.

Let's say that I'd like to start with the Products page, for me it is not clear what would be the best practice  on where I would grab the product information from. What is the better:

  • Extend the page dialog component to add the product properties, so I can consider when listing the product that the properties will come directly from the page;
  • Consider that the product's properties would be stored in a component in a node under the product detail page; For me using this approach leads me to start by the product detail page instead of the product list. Am I wrong with this?

Any considerations on this will be helpfull.

Thanks,

Francisco

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi Francisco,

  • Extend the page dialog component to add the product properties, so I can consider when listing the product that the properties will come directly from the page;
  • Consider that the product's properties would be stored in a component in a node under the product detail page; For me using this approach leads me to start by the product detail page instead of the product list. Am I wrong with this?

It's very common in CQ5 to use second approach, where first you create component first.

Then you create parsys where this component can be drag and dropped.[https://docs.adobe.com/docs/en/cq/5-5/howto/components_develop.html]

Your first approach is valuable when you want to achieve greater re usability of components.

  • Product could be a page
  • Dialog would contain multifield xtype type associated with the selector
  • Multiple products could be selected(e.g. + - and ability to add multple pages)

This approach would allow you to reuse product pages (e.g. product would not need to be recreated on each page as a component)

 

Both cases are valid. It really depends how often certain component will be used.

 

Thanks,

Peter

View solution in original post

5 Replies

Avatar

Correct answer by
Community Advisor

Hi Francisco,

  • Extend the page dialog component to add the product properties, so I can consider when listing the product that the properties will come directly from the page;
  • Consider that the product's properties would be stored in a component in a node under the product detail page; For me using this approach leads me to start by the product detail page instead of the product list. Am I wrong with this?

It's very common in CQ5 to use second approach, where first you create component first.

Then you create parsys where this component can be drag and dropped.[https://docs.adobe.com/docs/en/cq/5-5/howto/components_develop.html]

Your first approach is valuable when you want to achieve greater re usability of components.

  • Product could be a page
  • Dialog would contain multifield xtype type associated with the selector
  • Multiple products could be selected(e.g. + - and ability to add multple pages)

This approach would allow you to reuse product pages (e.g. product would not need to be recreated on each page as a component)

 

Both cases are valid. It really depends how often certain component will be used.

 

Thanks,

Peter

Avatar

Level 5

Assuming you have a PIM and e-commerce in place 

Then make AEM lightweight 

- Just import the high level catalogues to lay down the menu etc

- Create product list templates/components that uses the catalogue sku id to layout its sub products dynamically -  ajax- rest call consuming the json from PIM with paginatioan

- Create product detail template/ component that uses particular sku id to layout product details via ajax-rest call consuming json from PIM 

- Create cart and checkout template/components that uses e-commerce REST for carting state and sessions , transactions etc

Overall AEM just acts as a front end to layout the catalogue and carting experience

- if the AEM template / html with ajax calls are cached in dispatcher and assuming the PIM json are cached as well  the entire flow should be fast and this does not require all the product informations to be synced into AEM.

Avatar

Employee

Are the product information authored or imported? Either way , I think, if you follow the approach provided at http://docs.adobe.com/docs/en/aem/6-0/administer/ecommerce.html, you would have the products nodes away from the pages. If you are importing manually, you can use scaffold pages for this use case. Then the actual pages can refer to these nodes. The reason is most of the time , you would update product data but not changing anything else in the page. But any modification to any node under cq:page would trigger umpteen workflows and listeners. This is a performance hog.  Rather , you can store product data in unstructured nodes and then refer (or rollout..see catalog rollout) to these nodes from your pages. For ex.,You can just point to the product nodes in page properties. The implementation approach is your choice. 

Avatar

Level 10

Also - take a look at the sample AEM web site:

http://localhost:4502/siteadmin#/content/geometrixx/en/products

Notice that you can setup a similiar structure and use page components to display product information.