Question

I have data I need to display/edit that does not seem to fit naturally with the built-in views that Marionette provides. Let me give an example to illustrate.

Say I want to list/edit books. Each book has one ISBN, one title and 0 or more tags. Basically, the display of the information would be tabular (each word under Tags is a separate tag and could be edited/deleted separately):

+---------+----------------+-----------------------------+
|ISBN     |Title           |Tags                         |
+=========+================+=============================+
|12345678 |My Last Summer  |vacation diary kids          |
+---------+----------------+-----------------------------+
|12354389 |The Day After   |fiction future               |
+---------+----------------+-----------------------------+

If there was only one tag per book, then CompositeView/ItemView would work very nicely. What I am thinking is to create regions dynamically in the last cell of each row and then use CompositeView/ItemView to handle the list of tags. Perhaps this is overkill and having some kind of iterator in the template is the way to go.

I thought about capturing tags and populating a single string with the list of tags for a particular book. I could do that by manipulating the data I receive from the backend and thus making the list of tags into a single data element so that I can use CompositeView/ItemView to deal with with it as a simple table. This does introduce an extra “mapping” and things will get even more complicated to implement the “edit” views.

So I was just hoping to hear if people had bumped into this kind of requirement and what were the approaches that work well with Marionette. Thanks.

Answer 1

There are a number of different ways you could make this work, as you’ve already discovered. Each of the options will be better suited to a specific set of circumstances, but it’s also possible that your circumstances are such that there isn’t a “best” way to accomplish what you want. If that’s the case, just pick one and move on. 🙂

Map The Tags To A Single Value

This is what you’ve suggested already. It would work well in situations where the number of tags is relatively small and you don’t need any custom actions taken when someone clicks on a specific tag. For example, if you’re just setting up each tag as an <a href="#{tag-name}"> link, you could easily do this with the tags mapped down to a simple array.

Iterate The Tag Collection In The Template

Basically the same as the mapping option, except instead of reducing the tags down to a simple array of strings, you would iterate the tag collection in the template as models, and call model.get(…) in order to get the data you need.

If you’re using a template engine like Handlebars, this becomes really easy to do and might produce a much more clean result through the use of sub-templates.

I probably wouldn’t recommend this approach for underscore templates, though, as they tend to get muddy and ugly fast, when doing iteration.

A CollectionView Of CllectionViews, Using A Layout

This is the more complex option but also the most capable.

Configure the itemView for the collection of books as a layout. The layout would have a single region in it, and the region would be populated with another collectionview to render each of the individual tags.

The benefit here is that you can have a lot more code and functionality associated with your individual tag that is being rendered. You’ll have a single view instance for each tag, which means it will be easier to keep that code encapsulated and organized.

The drawback is that you’ll have a view instance for every tag, and more code to write just to get this set up and running.

CollectionView of CompositeViews

The compositeview lets you render a wrapper template around the collection, which may prove to be an advantage over CollectionView.

You would need a CollectionView, still. This CollectionView would render a CompositeView as it’s itemView. The CompositeView would specify an itemViewContainer to render the collection of tags. Each tag gets it’s own view instance, still.

You could get rid of the Layout and region this way. The visual result is the same as using a CollectionView with Layouts, but the amount of code to do it is probably reduced significantly.

---

Personally, I would either do the map/reduce to get the tags down to a simple array, or use a CollectionView Of CompositeViews.