1
votes

I am working on a component that is essentially a building tool. I can't go into a lot of detail as to what it is, however the greatest parallel I can draw is that of a product list builder. The concept being that the author wants to create custom lists of products. These lists will live in a singular place and be referenced from many different pages within our content.

work flow:

  1. create && build /content/myproductList
  2. content/mySite/myPage/jcr:content/specialListView #property list points to /content/myproductList

Currently everything is pretty hunky dory and is working fine. The authors wanted the list building to be drag and drop, just like the rest of the site. So I created components to represent the list items and they can just open up a new builder, and drag/drop/reorder the list as much as they like and it will be refreshed within the 'specialListView'.

There is a huge flaw in my design and I want to see if I can overcome it. The flaw is etched in the way that I create the list item components. Essentially all of the items are structurally identical(in terms of markup), they just differ in content. So what I did was created a base component to control the markup and basic workflows (dialog, etc). Then I created a new component for each list item, these components have nothing but cq:template nodes that hold their information.

ex structure:

components/lists
   | defaultItem
       | defaultItem.jsp
       | dialog.xml
   | customeItem1
       | .content.xml (resourceSuperType = components/lists/defaultItem)
       | _cq_template.xml (has custom information)
   | customeItem2
       | .content.xml (resourceSuperType = components/lists/defaultItem)
       | _cq_template.xml (has custom information)
   ...etc for 25+ items

By setting it up this way, we now have a workflow where the authors can drag and drop the components directly onto the page and not need to configure them or open dialogs and choose the correct dataset/etc. However, this seems extremely long winded and bulky. Scalability is an issue as well (what if they want to create 100 new items tomorrow -- sadly this is my reality).

What I'm proposing is to find a way to normalize this down so that I have a set of data (the list items) and 1 component to act as my structure.

something like:

/etc/data/lists/items
            item 1
               - nt:unstructured
               - label=foo
               - type=defaultItem
               ...etc
            ... etc, etc for all 25+ items

/apps/myapp/components/lists
            defaultItem
             | defaultItem.jsp
             | dialog.xml

This is where I get stuck. If I have a structure like this, it makes it very difficult to have item1,item2,item3,...etc show up in the sidekick as drag and drop elements. I'm guessing I will need to get into the portion of JS that generates the sidekick items, but I'm not sure how to approach it from there (haven't messed with customizing the sidekick yet). Just looking for guidance if anyone has dealt with anything like this before.

[sidenote] If you're curious why I'd like to move it to the second design, it's because eventually the authors would like a control panel that would allow them to create items on their own. It would be much easier and a lot more lightweight to have a system that alters a singular node and it's properties rather than one that has to manage creating/altering full component structures. It also decouples the 'item components' that the authors would make from the actual components that the developers create. This is important because the the component code we create is versioned/etc, whereas these faux components would go unchecked and we would need another way to manage them.

1

1 Answers

2
votes

As you already described, creating a new component for each product will result in a big overhead. Beside you will create components, which are linked only to one resource, so not re-usable anymore.

First you need to see a difference between the content and components. In this case your defaultItem is the component and the products the content. In AEM the contentfinder is created to display, search, drag and drop your content into the page. The sidekick for components.

The solution will be the following:

  1. Create a custom contentfinder tab which loads all your products; Loading products can be done by creating a servlet which returns all relevant products in a json format
  2. Create a generic component (eg. defaultItem) which can display your product into the page by setting a reference link to the product;
  3. Configure the contentfindertab to create the defaultitem component when dragging the product into the page Take care about the CQ.wcm.ContentfinderTab.getResultsBoxConfig. At itemsDDNewParagraph you can configure the new component type (defaultItem) and the property to link the component to the product.

How to create a contentfinder tab: http://helpx.adobe.com/experience-manager/kb/CustomCFTab.html

Note: when dropping a product from the contentfindertab into the page, use the ALT button