.. _tutorial/catalog-views: ============= Catalog Views ============= In **django-SHOP**, every URL, which points to a page visible by the customer, is managed by the CMS. This means that we are completely free, in how we organize the structure of our page-tree. There are however a few things to consider, when building a working e-commerce site. The catalog page(s) is where we present the products, we want to sell. In a shop, we can add as many catalog pages to the CMS, but there should be at least one, even if the shop only sells one product exclusively. When editing the CMS page used for the products list view, open **Advanced Settings** and choose **Products List** from the select box labeled **Application**. Then choose a template with at least one placeholder_. Click onto **View on site** to change into front-end editing mode. Locate the main placeholder of the template, and from section **Bootstrap**, add a **Container**-plugin, followed by a **Row**-, followed by a **Column**-plugin. Below that column add a **Catalog List Views**-plugin from section **Shop**. Then publish the page, it should not display any products yet. **Django-SHOP** does not distinguish between categories and a catalog pages. If our shop needs a hierarchy of different categories, we organize them using many catalog pages nested into each other. Each product can be assigned to as many catalog pages as we want. .. _placeholder: http://django-cms.readthedocs.org/en/latest/introduction/templates_placeholders.html#placeholders Assign products to their category ================================= In Django's administration backend, find the list view for products. Depending on the name of a given product type, this can be **Home › My Shop › Commodities**, **Home › My Shop › Products**, or similar. Choose an item of that list to open the product's detail editor. Locate the many-to-many select box labeled **Categories > Cms pages**. Select one or more CMS pages where the given product shall appear on. On reloading the catalog page, the assigned products shall now be visible in their list view. Assure that they have been set to be active, otherwise they won't show up. If we nest categories, products assigned to children will be also be visible on their parents pages. Configure Pagination -------------------- The serializer used to create the list of products for the catalog's view, usually only renders a subset, adding links pointing to other URLs for fetching neighboring subsets of that list. We also name this "pagination". The component rendering the catalog's list view offers three different types of pagination: * Adding a paginator, where the customer can choose the neighboring page manually. * Adding a simple paginator button, where by clicking one can extend the existing list of products. * An automatic paginator, which triggers the extension of catalog's list, whenever the customer scrolls to the end of the page. We name this infinite scroll. .. note:: If manual pagination is selected, **django-SHOP** tries to prevent widows – these are single items spawning over the last row. Say that the grid of the list can show 5✕3 items, then the 16nth item is hidden. If however we want to render 4✕4 items, then it is visible. A side-effect of this feature is, that the 16nth item is rendered again on the following page. .. _tutorial/product-detail-view: Product Detail Views ==================== In **django-SHOP's** frontend, each product can be rendered using their own detail view. However, we neither have to, nor can't create a CMS page for each product. This is, because we have to store the properties of a product, such as a unit price, product code, availability, etc. inside a Django model. It furthermore would be tedious to create one CMS page per product, to render its detail view. Therefore, products have to be assigned to their categories, rather than being children of thereof. This approach allows us to use CMS pages tagged as *Catalog List*, as product categories. Furthermore, we can assign a product to more than one such category. As with regular Django views, the product detail view is rendered by adding the product to the context, and using a Django template to render HTML. If the product has custom properties, they shall be referred by that template. In the merchant implementation, each product type can provide their own template referring exactly the properties of that model. On rendering, **django-SHOP** converts the classname of a product to lowercase. Say, we want to render the detail view of an instance of our class ``SmartCard``. Then we look for a template named #. ``myshop/catalog/smartcard-detail.html`` #. if not found, then ``myshop/catalog/product-detail.html`` #. if not found, then ``shop/catalog/product-detail.html`` Inside this template we refer the properties as usual, for instance .. code-block:: django