Sparx Enterprise Architect offers the possibility to define custom layouts for list views in the package browser and to save these definitions. When exporting a Project file (*.eap) via xmi, these definitions are not included in the export-file and thus lost. I wonder whether there exists a way to transfer columns layout definitions between two EA-Projects.
Many thanks in advance for every hint!
As Geert suggested the layout is stored in the registry.
[HKEY_CURRENT_USER\Software\Sparx Systems\EA400\EA\OPTIONS]
holds a key PKG_BRWSE_LAYOUTS with the comma separated list of profile names (so you better don't use comma in your profile name ;-).
The detailed information is stored in
[HKEY_CURRENT_USER\Software\Sparx Systems\EA400\EA\EA1200Workspace\BCGPGrids\EA_ELEMENT_LIST_<name>BCGPGrid-0]
where <name> is the according profile name.
For a sample layout here they looked like
"Columns"=hex:11,00,01,00,00,00,01,00,00,00,01,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,01,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,00,00,00,00,01,00,00,00,01,00,00,00,01,00,00,00,01,00,00,00
"ColumnWidth"=hex:11,00,16,00,00,00,04,01,00,00,50,00,00,00,50,00,00,00,50,00,\
00,00,50,00,00,00,50,00,00,00,50,00,00,00,50,00,00,00,50,00,00,00,50,00,00,\
00,50,00,00,00,50,00,00,00,50,00,00,00,50,00,00,00,50,00,00,00,50,00,00,00
"ColumnOrder"=hex:08,00,00,00,00,00,01,00,00,00,06,00,00,00,02,00,00,00,0d,00,\
00,00,0e,00,00,00,0f,00,00,00,10,00,00,00
"Groupping"=hex:00,00
"LastFieldChooserPos"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00
"IsFieldChooserVisible"=dword:00000000
"IsFieldChooserThemed"=dword:00000001
"SortColumns"=hex:00,00
I have to leave that to you to decipher the coding used here. But for a pure ex-/import you probably don't need to do that.
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:
create && build /content/myproductList
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.
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:
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
Create a generic component (eg. defaultItem) which can display your
product into the page by setting a reference link to the product;
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