I have a custom dexterity content type which includes a relation field. When I add that field to my mosaic layout it returns a uid instead of the actual link to the related field.
Here's the code as it shows up in the mosaic layout editor. The 'instructor' field is a relation field. I'm guessing I'll need a special relation tile or something.
I have tried to get this working with a 'normal tile' (and I also tried with theme fragments tile )for long without luck, I am pretty sure there are some bugs.
... which means you should keep an eye on the different versions of the 'sub-packages'.
I'm having some serious usability issues with Mosaic, and at this point can't see how I'd ever recommend it to anybody.
I'd love to contribute to the Mosaic user story, and really appreciate David's recent comparisons to other widely used site/layout builders... There's a lot there to emulate.
Ran updates to be able to test v2.x on a test site and still problems.*
Can't add links in a text field.
Select text. Hit 'link' icon in TinyMCE bar, panel opens, insert URL in external link field. Hit Apply. Sometimes three times before the panel goes away. Nothing changes. No link.
Indeed, I can't even do it manually, since the <> tab is not in the MCE bar (is there in v2 but still...)
So I don't mean to hijack your topic David, but does anybody have an idea why this is happening? Pointers?
*I posted an issue on problems with the site update over a week ago, and have had no input on that at all.
which includes my current buildout.cfg and tracebacks
Not sure where else to go with Plone questions.
Can I buy someone a beer to take a look at this issue? Or ???
Sorta feeling lonely out here!
Thx and remember
"Resilience is the new optimism"
(I'm trying, I'm trying... Uh, politics!?)
pf
Hmm. Well, that's weird. Immediately after describing this Mosaic problem, I went back to the site, in the same browser I'd been using all along, and was able to add a link with no problem at all.
Loki? Coyote? Mercury retrograde!?
WTH?
OK. It is not working in Safari, throws this error when I hit the Edit button to edit the page.
TypeError: undefined is not an object (evaluating 'f.createRange') logged-in.js:7548
I also get a whole string of these as the page is loading initially:
patterns.Patternslib Base: This pattern without a name attribute will not be registered!
Hmm. The same errors come up in Chrome and Forefox, but indeed, I'm able to make the link work there... Some weird Safari glitch?
Who knows!?!
Too much for my aching brain!
The default field tile implementation should render the configured display widget of the field in question. If the result is different from the dexterity content default view and issue with example content type schema should be filed into plone.app.standardtiles. (It's curious that it renders UUIDs, because the relation field should store "Relations" by default, not UUID.)
I use both from z3c.relationfield.schema.ReationChoice and RelationList in my schema without specifying a widget. Maybe that's the issue.
Field is:
top_story = RelationChoice(
title=_(u"Top Story"),
description=_(u'Top Story being displayed on this Subsite.'),
required=False,
source=CatalogSource(portal_type=['story']),
)
I played with this a little today, trying a hack inside standardtiles field.py and got "results", albeit wrong results (main template was rendered), but the concept held water.
def __call__(self):
...
if widget is not None:
if plone.app.z3cform.interfaces.IRelatedItemsWidget.providedBy(widget):
return self._render_reference(widget.value)
return self._wrap_widget(widget.render())
def _render_reference(self, uid):
""" take a uid from a reference field, de-reference it to existingcontent and render"""
from zope.component import getMultiAdapter
existingcontentview = getMultiAdapter((self.context, self.request),
name='plone.app.standardtiles.existingcontent')
existingcontentview.data['content_uid'] = uid
return existingcontentview()
Figured I'd duplicate the existing content view behavior at least.
Not really sure what you are trying to do here.
Please dont change what the reference widget stores (it will brek a lot of stuff)
If you have your own template.pt for the tile, why not just find the content with plone api?
In your view.py, something like:
def get_relitems(self):
linked = self.data['relateditems'] // or whatever your field is called
linked_items = self.context.portal_catalog(UID=linked)
return linked_items (or linked_items[0] if you have relateionChoice and are sure there is only one related item)
Or maybe (in some cases… maybe this is needed if you want the image later)
linked_items[0].getObject()
Then in your template.pt you can use normal stuff like
To answer myself, this seems to be handled by value converters in plone.app.z3cform (UUIDs from widget are transformed to objects for the field and other way around).
I believe that this is the current standard behavior for related items field. The responsible package is plone.app.z3cform that does register the interactive input widget for related items field, but only registers very generic display widget for it.
The generic field tile from plone.app.standardtiles does its best to find the currently configure display widget for the field. So, registering a proper display widget for those fields should make the trick.
The opposite. I was wondering, why I see UUIDs when RelationObjects are stored. Yet, that was correct behavior, because there is z3c.form converter registered to do the conversion.
How can I check (for my tiles) that RealationObjects are stored.
When I (for example) do: view/data/relationField , I get the uuid. Does that mean this has passed through the converters. If so, is it possible to read it another way (as 'raw')?
Later I realised that RelationValues make no sense on tiles, because RelationValue should be traversable to use the benefits of relation catalog (like back rerferences).
But now I am again puzzled on what makes RelationField to successfully save UUID on a tile instead of just raising some kind of adaptation error... I don't know right now.
