Search code examples
plonedexterityplone-4.xarchetypes

Plone best practice for embedding of objects by uid

I have a Plone 4 site where I currently use the following method to embed objects (e.g. images, videos, tables …) in user-editable HTML content:

  • I have a custom transform browser which takes HTML text and transforms all a and img elements which refer to an element by UID (i.e., which have an href="…/resolveuid/abc123…" or src="…/resolveuid/abc123…").
  • My view templates read the text field and let that browser transform it;
  • the browser has a Python dict TYPE2TEMPLATE which has portal_type keys and template_id values;
  • for each a or img which refers to an object by UID,
    • the object is fetched by o = brain._unrestrictedGetObject()
    • the template id t_id is taken from the TYPE2TEMPLATE dict
    • the "embed" method is fetched by method = o.unrestrictedTraverse(t_id)
    • that method is called (in some cases with some keyword arguments), and the result - which is contained in one top HTML element - replaces the "raw" a or img element.

Now that I'm developing an additional customization package (which contains new object types, now using Dexterity), I wonder whether there is some more "plonish" way. Is there, for example, some embed action?

Solution

  • i don't know of a package that does the same and what you're doing sounds sane to me ;-)

    i just would use https://pypi.python.org/pypi/plone.outputfilters instead of your transform BrowserView.

    if it's possible to explicitly mark links that should not be auto-embedded (eg via span.noEmbed a.internal-link selector) this could become a useful addon.

    i guess for portal_type=='File' you'll need to check the mimetype too in order to decide if you're embedding a video file or something else...

    other products i know of embed content outside of your plone site (eg. collective.embedly)

    another approach would be a to use a tinymce plugin to genereate the proper embed html when editing the html-body of your page (i personally would not go this route because there are different tiny versions to support for 4.3 and 5.0 and we're not sure if tiny woun't be replaced as default editor in the future)