Level 6

Solved

Best Practices on detail pages

Forum|Forum|10 years ago
October 16, 2015
5 replies
1775 views

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

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

Best answer by Peter_Puzanovs

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

Peter_Puzanovs

Accepted solution

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

varshsr

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.

A

Anonymous

You can see your answer right here in the forum : magento tutorial

G

gopalKa

Adobe 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.

smacdonald2008

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.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded