[xwiki-devs] [Rendering] Two ideas using Transformation
Hi, Need 1: Be able to prevent some macros from execution in some contexts. For example in the comments field prevent usage of script and html macros Proposed solution: Use a Rendering Transformation with a high priority that removes (or that generate an error) those macros (the list of macros can be retrieved from a config file or from some execution context) Need 2: Ensure that renderers generate valid content (eg valid XHTML for the WYSIWYG editor). For example if the user uses the HTML macro and puts invalid HTML the WYSIWYG editor should still work Proposed solution: Use a Rendering Transformation with a low priority that traverses the XDOM to validate it (for example remove inline elements that are placed in a standalone context). WDYT? Thanks -Vincent
Now the search engine works but yesterday when I search "Rest" for example, I got only some pages concerning recent Releases... But Vincent, you're right, the site is really slow... thks anyway guys Pascal On Fri, Jun 19, 2009 at 12:16 PM, Vincent Massol <[email protected]> wrote:
Hi,
Need 1: Be able to prevent some macros from execution in some contexts. For example in the comments field prevent usage of script and html macros Proposed solution: Use a Rendering Transformation with a high priority that removes (or that generate an error) those macros (the list of macros can be retrieved from a config file or from some execution context)
Need 2: Ensure that renderers generate valid content (eg valid XHTML for the WYSIWYG editor). For example if the user uses the HTML macro and puts invalid HTML the WYSIWYG editor should still work Proposed solution: Use a Rendering Transformation with a low priority that traverses the XDOM to validate it (for example remove inline elements that are placed in a standalone context).
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Vincent Massol wrote:
Hi,
Need 1: Be able to prevent some macros from execution in some contexts. For example in the comments field prevent usage of script and html macros Proposed solution: Use a Rendering Transformation with a high priority that removes (or that generate an error) those macros (the list of macros can be retrieved from a config file or from some execution context)
How do you mark when should macros be disabled? An idea would be to push some settings in comentsinline.vm before rendering the comments.
Need 2: Ensure that renderers generate valid content (eg valid XHTML for the WYSIWYG editor). For example if the user uses the HTML macro and puts invalid HTML the WYSIWYG editor should still work Proposed solution: Use a Rendering Transformation with a low priority that traverses the XDOM to validate it (for example remove inline elements that are placed in a standalone context).
When do you want to enable this feature? Just for the WYSIWYG, or in general? If we enable it globally, we can solve an often reported problem: broken layout, caused by invalid content (most often the panels are pushed to the bottom of the page, or become invisible altogether).
WDYT?
Looks good. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Jun 19, 2009, at 7:30 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
Hi,
Need 1: Be able to prevent some macros from execution in some contexts. For example in the comments field prevent usage of script and html macros Proposed solution: Use a Rendering Transformation with a high priority that removes (or that generate an error) those macros (the list of macros can be retrieved from a config file or from some execution context)
How do you mark when should macros be disabled? An idea would be to push some settings in comentsinline.vm before rendering the comments.
Yes, that's why I said "from some execution context". The Execution Context sounds like the best place for this. The Transformation has access to it. commentsinline.vm would simply need to ensure to reset the value after the rendering has been executed so that it doesn't impact whoever comes after.
Need 2: Ensure that renderers generate valid content (eg valid XHTML for the WYSIWYG editor). For example if the user uses the HTML macro and puts invalid HTML the WYSIWYG editor should still work Proposed solution: Use a Rendering Transformation with a low priority that traverses the XDOM to validate it (for example remove inline elements that are placed in a standalone context).
When do you want to enable this feature? Just for the WYSIWYG, or in general?
This is general, ie whenever someone calls the rendering to parse and run transformations. For example whenever getRenderedContent() is called.
If we enable it globally, we can solve an often reported problem: broken layout, caused by invalid content (most often the panels are pushed to the bottom of the page, or become invisible altogether).
Yes, good idea. Thanks -Vincent
WDYT?
Looks good.
participants (3)
-
Pascal Voitot -
Sergiu Dumitriu -
Vincent Massol