[xwiki-devs] [VOTE] Don't include the JavaScript extensions when rendering a document in WYSIWYG edit mode
29 Jan
2010
29 Jan
'10
3:04 p.m.
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
WDYT? Should we limit the WYSIWYG in order to make the editing safer?
I'm +0.
Thanks,
Marius
29 Jan
29 Jan
3:19 p.m.
Marius Dumitru Florea wrote:
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
WDYT? Should we limit the WYSIWYG in order to make the editing safer?
I'm +1 to remove JSX inclusion in WYSIWYG edit mode.
I've never seen the value of executing the extensions in the WYSIWYG.
Making the extensions be responsible for their behavior inside the
WYSIWYG frame sounds like unneeded pain.
Jerome.
I'm +0.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:26 p.m.
New subject: [xwiki-devs] [VOTE] Don't include the JavaScript extensions when rendering a document in WYSIWYG edit mode
On Jan 29, 2010, at 3:04 PM, Marius Dumitru Florea wrote:
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
Before deciding isn't there a possibility to protect the DOM? Is there no way to do
that?
We're going to do something a little similar for the rendering is there's invalid
HTML entered:
http://jira.xwiki.org/jira/browse/XWIKI-3782
Thanks
-Vincent
WDYT? Should we limit the WYSIWYG in order to make the editing safer?
I'm +0.
Thanks,
Marius
3:33 p.m.
New subject: [xwiki-devs] [VOTE] Don't include the JavaScript extensions when rendering a document in WYSIWYG edit mode
Vincent Massol wrote:
On Jan 29, 2010, at 3:04 PM, Marius Dumitru Florea
wrote:
What do you mean protect the DOM ?
If you mean prevent DOM modifications by the extensions, I think it is a
hard problem, and it does not really make sense (what the point of
including extensions to not discriminate vs. view mode if in the end
they cannot affect the DOM ?)
But maybe that's not what you mean.
Jerome.
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
Before deciding isn't there a possibility to protect the DOM? Is there no way to do
that?
We're going to do something a little similar for the rendering is there's invalid
HTML entered:
http://jira.xwiki.org/jira/browse/XWIKI-3782
Thanks
-Vincent
WDYT? Should we limit the WYSIWYG in order to
make the editing safer?
I'm +0.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:38 p.m.
New subject: [xwiki-devs] [VOTE] Don't include the JavaScript extensions when rendering a document in WYSIWYG edit mode
On Jan 29, 2010, at 3:33 PM, Jerome Velociter wrote:
Vincent Massol wrote:
No I meant protect the DOM when in wysiwyg edit mode.
I have no idea if it's possible. We have the same issue for the XDOM when a
transformation makes a change in other parts of the XDOM and we need to protect it (by
adding markers around the changes). The way I plan to implement this is to implement a
TransformationXDOM which is an extension of the default XOM implementation and that
automatically adds markers when a change is done outside of its zone.
Thanks
-Vincent
On Jan 29, 2010, at 3:04 PM, Marius Dumitru
Florea wrote:
What do you mean protect the DOM ?
If you mean prevent DOM modifications by the extensions, I think it is a
hard problem, and it does not really make sense (what the point of
including extensions to not discriminate vs. view mode if in the end
they cannot affect the DOM ?)
But maybe that's not what you mean. Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
Before deciding isn't there a possibility to protect the DOM? Is there no way to do
that?
Jerome.
>
> We're going to do something a little similar for the rendering is there's
invalid HTML entered:
> http://jira.xwiki.org/jira/browse/XWIKI-3782
>
> Thanks
> -Vincent
>
>> WDYT? Should we limit the WYSIWYG in order to make the editing safer?
>>
>> I'm +0.
>>
>> Thanks,
>> Marius
3:46 p.m.
New subject: [xwiki-devs] [VOTE] Don't include the JavaScript extensions when rendering a document in WYSIWYG edit mode
Vincent Massol wrote:
On Jan 29, 2010, at 3:33 PM, Jerome Velociter wrote:
OK.
How do you handle (mark?) content deletion?
Even if it's possible to implement this in JavaScript somehow (though I
think it's pretty hard - you have to arbitrate and decide who you think
is modifying the DOM for every modification : an extension ? or the
normal behavior of the WYSIWYG ? + the fact that you have to observe
change on potentially a very big DOM tree, and that every key stroke
will trigger one more event to be handled, this slowing down the editor,
etc.) I think it's over-engineering for the little value it brings.
Still +1 to remove JSX inclusions.
Jerome.
Vincent Massol wrote:
No I meant protect the DOM when in wysiwyg edit mode.
I have no idea if it's possible. We have the same issue for the XDOM when a
transformation makes a change in other parts of the XDOM and we need to protect it (by
adding markers around the changes). The way I plan to implement this is to implement a
TransformationXDOM which is an extension of the default XOM implementation and that
automatically adds markers when a change is done outside of its zone. On Jan 29, 2010, at 3:04 PM, Marius Dumitru
Florea wrote:
What
do you mean protect the DOM ?
If you mean prevent DOM modifications by the extensions, I think it is a
hard problem, and it does not really make sense (what the point of
including extensions to not discriminate vs. view mode if in the end
they cannot affect the DOM ?)
But maybe that's not what you mean. Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
Before deciding
isn't there a possibility to protect the DOM? Is there no way to do that?
Thanks
-Vincent
Jerome.
> We're going to do something a little similar for the rendering is there's
invalid HTML entered:
> http://jira.xwiki.org/jira/browse/XWIKI-3782
>
> Thanks
> -Vincent
>
>> WDYT? Should we limit the WYSIWYG in order to make the editing safer?
>>
>> I'm +0.
>>
>> Thanks,
>> Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:03 p.m.
New subject: [xwiki-devs] [VOTE] Don't include the JavaScript extensions when rendering a document in WYSIWYG edit mode
Vincent Massol wrote:
On Jan 29, 2010, at 3:33 PM, Jerome Velociter wrote:
I don't think this is possible. DOM changes can come from different
places: the editor, in-line JavaScript, JavaScript extensions (including
third-party JavaScript libraries). Catching DOM mutations is not
possible in IE, and how can we detect the entity behind the DOM mutation
(especially when it's a third-party JavaScript library)? Moreover, I'm
not sure it's possible to wrap all the JavaScript DOM API to be able to
detect for instance when a DOM node is added to the document.
Note that a macro would still be able to generate in-line JavaScript
(though the best practice is to have this code in a JavaScript extension).
Thanks,
Marius
Vincent Massol wrote:
No I meant protect the DOM when in wysiwyg edit mode.
I have no idea if it's possible. We have the same issue for the XDOM when a
transformation makes a change in other parts of the XDOM and we need to protect it (by
adding markers around the changes). The way I plan to implement this is to implement a
TransformationXDOM which is an extension of the default XOM implementation and that
automatically adds markers when a change is done outside of its zone. On Jan 29, 2010, at 3:04 PM, Marius Dumitru
Florea wrote:
What
do you mean protect the DOM ?
If you mean prevent DOM modifications by the extensions, I think it is a
hard problem, and it does not really make sense (what the point of
including extensions to not discriminate vs. view mode if in the end
they cannot affect the DOM ?)
But maybe that's not what you mean. Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
Before deciding
isn't there a possibility to protect the DOM? Is there no way to do that?
Thanks
-Vincent
Jerome.
> We're going to do something a little similar for the rendering is there's
invalid HTML entered:
> http://jira.xwiki.org/jira/browse/XWIKI-3782
>
> Thanks
> -Vincent
>
>> WDYT? Should we limit the WYSIWYG in order to make the editing safer?
>>
>> I'm +0.
>>
>> Thanks,
>> Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
3:43 p.m.
New subject: [xwiki-devs] [VOTE] Don't include the JavaScript extensions when rendering a document in WYSIWYG edit mode
On Fri, Jan 29, 2010 at 3:04 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
Would XSKINX-14 (Let extensions declare a list of web actions (view, edit,
etc.) it should be pulled for) fix at least some of the issues?
WDYT? Should we limit the WYSIWYG in order to make the
editing safer?
I'm +0.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:24 p.m.
New subject: [xwiki-devs] [VOTE] Don't include the JavaScript extensions when rendering a document in WYSIWYG edit mode
Marta Girdea wrote:
On Fri, Jan 29, 2010 at 3:04 PM, Marius Dumitru Florea
<
mariusdumitru.florea(a)xwiki.com> wrote:
Not necessarily. Take for instance XWIKI-4665. I think the user should
be able to jump to a page even when in edit mode as long as the focus is
not on the rich text area. When the focus is on the rich text area the
shortcut key is triggered for the inner (edited) document and the jump
to page feature should be disabled.
XSKINX-14 could be a solution if the inner (edited) document were loaded
with a different action (right now the action is edit).
Thanks,
Marius
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
Would XSKINX-14 (Let extensions declare a list of web actions (view, edit,
etc.) it should be pulled for) fix at least some of the issues? WDYT? Should we limit the WYSIWYG in order to
make the editing safer?
I'm +0.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:43 p.m.
Marius Dumitru Florea wrote:
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
WDYT? Should we limit the WYSIWYG in order to make the editing safer?
FYI, I get a JavaScript exception ("XWiki is not defined") if I edit
Main.AllDocs when javascript.vm template is not imported in WYSIWYG
editing mode. Should the live table macro check if the XWiki JavaScript
object is present?
Thanks,
Marius
I'm +0.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:48 p.m.
Marius Dumitru Florea wrote:
Marius Dumitru Florea wrote:
Yes It should. Thanks for catching this.
Jerome.
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
WDYT? Should we limit the WYSIWYG in order to make the editing safer?
FYI, I get a JavaScript exception ("XWiki is not defined") if I edit
Main.AllDocs when javascript.vm template is not imported in WYSIWYG
editing mode. Should the live table macro check if the XWiki JavaScript
object is present?
Thanks,
Marius
I'm +0.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
3:58 p.m.
On 01/29/2010 03:48 PM, Jerome Velociter wrote:
Marius Dumitru Florea wrote:
Errr, no? If the XWiki object is not defined, then how will it work? I
think the XWiki object is defined in the parent frame, so this would be
better:
if (typeof(XWiki) == 'undefined') {
if (typeof(window.parent.XWiki) != 'undefined') {
XWiki = window.parent.XWiki;
} else {
// Critical, what now?
}
}
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
FYI, I get a JavaScript exception ("XWiki is
not defined") if I edit
Main.AllDocs when javascript.vm template is not imported in WYSIWYG
editing mode. Should the live table macro check if the XWiki JavaScript
object is present?
Yes It should. Thanks for catching this.
4:03 p.m.
Sergiu Dumitriu wrote:
On 01/29/2010 03:48 PM, Jerome Velociter wrote:
Correct, I spoke too fast. I thought the livetable did not check for the
XWiki namespace presence but it does. (Indeed it would not work if not)
Marius Dumitru Florea wrote:
Errr, no? FYI, I get a JavaScript exception ("XWiki is
not defined") if I edit
Main.AllDocs when javascript.vm template is not imported in WYSIWYG
editing mode. Should the live table macro check if the XWiki JavaScript
object is present?
Yes It should. Thanks for catching this. If the XWiki object is not defined, then how will it
work? I
think the XWiki object is defined in the parent frame, so this would be
better:
if (typeof(XWiki) == 'undefined') {
if (typeof(window.parent.XWiki) != 'undefined') {
XWiki = window.parent.XWiki;
} else {
// Critical, what now?
}
}
4:08 p.m.
On 01/29/2010 03:04 PM, Marius Dumitru Florea wrote:
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
WDYT? Should we limit the WYSIWYG in order to make the editing safer?
I'm +0.
+1
If some script should be executed in edit mode, I think a possible
solution would be to add a new field to the JSX class to tell if the
extension should be used in edit mode, too. By default it should be
false. The problem is that this doesn't fix file extensions, and those
are the ones that cause problems now. So, at least for file extensions,
they should always be disabled in edit mode.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
4:13 p.m.
On 01/29/2010 04:08 PM, Sergiu Dumitriu wrote:
On 01/29/2010 03:04 PM, Marius Dumitru Florea wrote:
Actually we can use a parameter for file extensions too, in the extra
params parameter.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
WDYT? Should we limit the WYSIWYG in order to make the editing safer?
I'm +0.
+1
If some script should be executed in edit mode, I think a possible
solution would be to add a new field to the JSX class to tell if the
extension should be used in edit mode, too. By default it should be
false. The problem is that this doesn't fix file extensions, and those
are the ones that cause problems now. So, at least for file extensions,
they should always be disabled in edit mode.
3 Feb
3 Feb
12:41 p.m.
Two more reasons:
* JavaScript is mostly used to create dynamic HTML pages with rich user
interaction. IMO pages shouldn't be dynamic when edited and they
shouldn't respond to user interaction as in view mode (e.g.
http://jira.xwiki.org/jira/browse/XWIKI-4665 ).
* Currently, there is a lot of JavaScript code included in view mode
which is rarely used inside the page content (at least for content
pages, e.g. those holding documentation). Since the WYSIWYG editor edits
only the page content I think it's good to not include all this
JavaScript code and thus reduce the loading time of the editor.
I'd like to make this change for 2.2RC1. Anyone against it?
Thanks,
Marius
Marius Dumitru Florea wrote:
Hi devs,
Right now JavaScript extensions are included when a document is rendered
in WYSIWYG edit mode. This has both advantages and disadvantages.
Pro: If the output of a macro depends on a JavaScript extension, then
the result of rendering that macro will be the same in view mode and
(WYSIWYG) edit mode.
Con: If the JavaScript extension is not aware of the edit mode then it
can modify the DOM document outside of the read-only macro markers which
leads to unwanted changes in the content of the edited document (i.e.
the modifications done by the JavaScript extension are saved). Such an
example is http://jira.xwiki.org/jira/browse/XWIKI-4665 .
WDYT? Should we limit the WYSIWYG in order to make the editing safer?
I'm +0.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5435
days inactive
5440
days old
15 comments
5 participants
participants (5)
-
Jerome Velociter -
Marius Dumitru Florea -
Marta Girdea -
Sergiu Dumitriu -
Vincent Massol