Just to note, this is not a persistent tile. I am using standardtiles.field
The “top story “ relation field I have is part of the dexterity type’s schema, not a tile schema.
In mosaic, I am choosing to add a tile for a field. That’s why I was poking around in standardtiles.field call where I manually lookup the reference and hack an existingcontent tile together, and render that.
The endgame is a layout that supports changing the ‘top story’ on my main page without visiting the mosaic editor, only the ‘top story’ field through the main page’s properties
Thanks for the endgame. This discussion went into too complex options. Customizing field tile is not trivial in that use case. (I may have merged, but not documented support for that.)
Probably the easiest solution is a new custom tile copied from the existingcontent tile code (or inherit it if that works) but reads the target content value from the dedicated field of your content type.
Exactly. I want a user to place "The Top Story" onto the page using mosaic (presentation) and then choose what the top story is through a reference field (data). Replace the word "Story" with "News Item" in the previous sentence for a more OOTB experience.
This is the path I was hacking with standardtiles.field: Dereference / lookup then render an existingcontent tile.
I really think it makes sense to treat a field tile 'that happens to be a reference' as an existingcontent tile and this is the basis of the whole idea.
Need to learn that - I have no clue.
I'm actually more of a fan of:
It's not trivial at all, but I'm willing to work on it if it fits the architecture. If it breaks architecture rules for standardtiles.field to dereference reference fields (repeating the work in z3cform) I'll drop the idea.
But I do feel that reference fields should 'just work'. If I reference content through a field, and drop that field into my layout, the field should render the referenced content. Otherwise, reference fields feel really broken in Mosaic.
and lo and behold - RelationChoice fields (all of them) now print Hello World.
From here, it's obvious what to do.
Comments:
I wish I could provide a 'template' attribute to the 'adapter' registration in ZCML so I could properly use browserlayers to switch out templates.
I could not find the existing adapter registration that pulls the textfield display widget, so I had to work backwards through providedBy(self.field) and such. This seems sloppy. The only way I got a 'more specific adapter' than the z3cform built-in was by using my browserlayer interface for the request.
@datakurre - could an adapter like this be registered in mosaic to handle RelatedItemsWidget (and RelationList, which I also need)
And...... It works, but it's not a 'tile' Just a template and a widget.
After making it work, I think this is a better answer.
But if a custom tile is not the right answer, at least there is now a possible OOTB solution for relation fields. It's a template that uses the portal catalog to get the object. Then renders title(s) description(s) and Lead Image(s)