0

I have been trying to create a rich data model that has strong hierarchies -- let's say that a "Team" has "Members" -- both are pieces. I have succeeded in creating the joins, and the _members object is available to the Team. However, I would like to automatically display those members in a widget on the Show page of the Team. Inside show.html (a from team-pages, extended from apostrophe-pieces-pages), I would like to do something like:

apos.singleton(data.piece, 'members', 'members-widgets', data.piece._members)

I know the members widget works properly -- I can include it in other areas and update it as a normal pieces widget.

I have been unable to figure out a way to automatically include the members objects that I already have. I've tried several different ways, and have not figured out a way that works. Is this possible? Am I going about this entirely the wrong way?

1 Answers1

0

I'm the software architect of Apostrophe at P'unk Avenue.

Widgets were originally intended as a mechanism for allowing users to edit content of various types. Even in the case of a "members widget," this is generally true: the content comes from elsewhere the editor decides which individual members to display, or elects to display members with a particular tag, or elects to display all members.

By contrast, on the "show page," there is nothing to edit — as you say, you already have the members, and you can just implement rendering them right there by looping over data.piece._members. There are no choices to be made, so there is no widget to edit.

Of course, code reuse is a good thing, and I understand why it can be desirable to have the same presentation on a "show page" and in a widget.

One simple way to achieve this is to create a memberMacros.html file in the members module, and just import that macro file from both the widget's widget.html and the show.html file:

{# In show.html #}
{% import "members:memberMacros.html" as memberMacros %}
{{ memberMacros.output(data.piece._members) }}  

{# in widget.html #}
{% import "members:memberMacros.html" as memberMacros %}
{{ memberMacros.output(data.widget._pieces) }}  

I think this addresses your use case well.

There are other use cases for overriding fields of a widget which may eventually lead us to support limited overrides of widget fields on a per-template basis. However there's also a cost associated with that because that data would need to be JSONified and passed back and forth via the widget editor. So we would probably never recommend it for the "main content" of the widget. It makes more sense to use a nunjucks macro file that is shared by the widget and the show page.

Tom Boutell
  • 7,281
  • 1
  • 26
  • 23
  • That makes sense. I'm coming back to look at Apostrophe after a couple years off, and didn't think about Macros (I also think they've been changed a bit since I used it? Not sure). Thanks, I'll try that out. Definitely sounds like it addresses my use case. I've just been working with different componentized CMSs, and so I was thinking about it in a different way. – Michael Rehse May 01 '17 at 14:11