19 Jun
2009
19 Jun
'09
12:16 p.m.
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
19 Jun
19 Jun
3:19 p.m.
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 <vincent(a)massol.net> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:30 p.m.
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/
20 Jun
20 Jun
11:51 a.m.
On Jun 19, 2009, at 7:30 PM, Sergiu Dumitriu wrote:
This is general, ie whenever someone calls the rendering to parse and
run transformations. For example whenever getRenderedContent() is
called.
Vincent Massol wrote:
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.
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).
Yes, good idea.
Thanks
-Vincent
WDYT?
Looks good.
5626
days inactive
5627
days old
3 comments
3 participants
participants (3)
-
Pascal Voitot -
Sergiu Dumitriu -
Vincent Massol