How to Use Containers in to Customize the UI
- Containers create new sections to help organize how the information is displayed
- At the moment you cannot move older information to the new sections, although it sounds like this feature is on the list of features the devs would like to add
- The bind attribute is which table C/A will use, e.g. ca_objects
- Element code is the section of the mysql table, e.g. .condition, the data is saved, in this example, the container would save information to ca_objects.condition
- In order to use the container, like any metadata component, C/A needs to know which element it falls under.
- The container allows for binding only to a particular subtype
- More than one element can be bound to a container, e.g. ca_objects and ca_storagelocations
- Subcontainers are useful for creating line breaks
- Some of the elements of a container are not visible until after the initial creation of the item, IE, after saving the container for the first time, the display will provide additional options, e.g., “Can be used in display”
- For subcontainers include a line number as part of the element code (e.g. condition_reports_1) to help keep items organized
- Map out the basics of the design before creating it
Containers are a useful tool to create a well thought out layout in CollectiveAccess and these metadata elements can use them bundle relevant information together. For instance, by creating a container for condition reports, multiple reports can be entered into the system easily. The reason for writing up this tutorial is because I had a difficult time to create containers when I first started.
Containers work the best when you are first creating an installation before making the system live or for new areas that you would like to expand into, e.g. creating a separate section for an archives. This fact is due to because as of this writing, March 2016, CollectiveAccess cannot utilize existing records as part of a container. However, the developers have stated moving records from one field to another using the UI is a goal.
Like every other metadata element, a container needs to be bound to particular element in order to be used. It took me a while to realize that bind attribute should be considered which table I am storing the information in, e.g. ca_objects, and Element Code is the section of the table that I want to create. Therefore, in the screenshot, this section of the database will be ca_objects.treatment. Another detail of containers is that some of the specific choices for the container will not be listed until after the container is saved. [Insert Image A]
In order to have multiple items in a row, you need to set the line breaks to zero which will look like: [insert Image B]
By combining zero line breaks set to zero in some subcontainers and not in others, the overall design can be more efficient.
As mentioned above, I have found sketching out what I wanted has helped me design the overall look of the container. The last two images were from my testbed installation, when I recreated the container and the relevant elements in the the working database, I was able to improve upon the layout even more, as seen in this image: