Not Considering

Proper mechanism for easily detecting XPM mode in DXA - server side

Often times when rendering in views there is a need to know what context is the application in (XPM or not). For example, this can be to:

  • render additional html tags to be editable for elements which only have 1 visual representation on the page, typical for embedded schemas, like link text and link url
  • omitting or including different js/css files to make the content more XPM compatible
  • etc.

In my understanding there is no out of the box solution for this, only some hacks. For example like appending query strings, but this specific approach is done at a client side so too late for the optional fields example. In other words, I would need to render all the fields and then remove them from the DOM if not in XPM context, which is crazy.

"WebRequestContext.IsPreview" should do this, but as the note on the property says, this is always true for staging.

Atila Sos
Parents

  • We could use more examples of the use cases described. For example, how are you adjusting the styles for XPM and what elements are you introducing in the XPM (Staging) markup? Are you showing more content, adding fields, or showing other use cases?

    Going forward we are looking to make it easier to edit items in the context of pages in the new Graphene-based Experience Manager. Though we may change how changes work "inline" within the XPM-enabled page markup.

    For example, rather than directly editing content within the HTML markup or Document Object Model (DOM) for a webpage "inline," we may introduce markup and a GUI interaction that opens the fields to edit in a side panel or component form editor.

    We're interested in your specific use cases so that rather than needing to necessarily add nodes to expose fields, perhaps we could design and build an interaction that reduces the need for XPM-specific markup. This can help align future-planned extensibility between XPM and CME.

Comment

  • We could use more examples of the use cases described. For example, how are you adjusting the styles for XPM and what elements are you introducing in the XPM (Staging) markup? Are you showing more content, adding fields, or showing other use cases?

    Going forward we are looking to make it easier to edit items in the context of pages in the new Graphene-based Experience Manager. Though we may change how changes work "inline" within the XPM-enabled page markup.

    For example, rather than directly editing content within the HTML markup or Document Object Model (DOM) for a webpage "inline," we may introduce markup and a GUI interaction that opens the fields to edit in a side panel or component form editor.

    We're interested in your specific use cases so that rather than needing to necessarily add nodes to expose fields, perhaps we could design and build an interaction that reduces the need for XPM-specific markup. This can help align future-planned extensibility between XPM and CME.

Children
No Data