17 Jan
2009
17 Jan
'09
10:07 a.m.
Hi,
Just realized that our new WYSIWYG editor will only work fine with our
xwiki 2.0 syntax since other wiki syntaxes are less powerful and won't
be able to express some complex structures (like embedding a document
inside a table cell) or simply like styling a portion of text.
Of course this is not a problem of the wysiwyg editor per see but in
practice it means that users using it for other syntaxes when they
save will get a different rendered result.
So I"m tempted to say that our GWT editor will only work for the xwiki
2.0 syntax and that for the other syntaxes users will have to use the
wiki editor.
WDYT?
Thanks
-Vincent
17 Jan
17 Jan
10:51 a.m.
On Jan 17, 2009, at 10:07 AM, Vincent Massol wrote:
Hi,
Just realized that our new WYSIWYG editor will only work fine with our
xwiki 2.0 syntax since other wiki syntaxes are less powerful and won't
be able to express some complex structures (like embedding a document
inside a table cell) or simply like styling a portion of text.
Of course this is not a problem of the wysiwyg editor per see but in
practice it means that users using it for other syntaxes when they
save will get a different rendered result.
So I"m tempted to say that our GWT editor will only work for the xwiki
2.0 syntax and that for the other syntaxes users will have to use the
wiki editor.
Option 2:
* Add the notion of Syntax Capability in the rendering
* Modify that WYSIWYG editor so that it enables toolbar entries based
on syntax capabilities only
Option 2 is probably nicer but more complex too.
I think I'm still for the simple thing for now which is option 1.
WDYT?
Thanks
-Vincent
http://xwiki.com
http://xwiki.org
http://massol.net
10:54 a.m.
Some questions arising in my head:
do you want to make the WYSIWYG the cornerstone of XWiki online editing or
is it only the XWiki2.0 syntax editor?
do you want to make multi-syntax a key feature of XWiki or is it only a
facility provided so that people can use easily XWiki and when they are used
to it, they will naturally begin to use XWIki2.0 syntax?
If WYSIWYG is used only with XWiki2.0 syntax, it might look like you are
strongly encouraging people to use XWIki2.0 syntax instead of other
syntaxes. Is it a good or bad strategy? I don't know... to be discussed :)
Pascal
On Sat, Jan 17, 2009 at 10:07 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi,
Just realized that our new WYSIWYG editor will only work fine with our
xwiki 2.0 syntax since other wiki syntaxes are less powerful and won't
be able to express some complex structures (like embedding a document
inside a table cell) or simply like styling a portion of text.
Of course this is not a problem of the wysiwyg editor per see but in
practice it means that users using it for other syntaxes when they
save will get a different rendered result.
So I"m tempted to say that our GWT editor will only work for the xwiki
2.0 syntax and that for the other syntaxes users will have to use the
wiki editor.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:36 a.m.
On Jan 17, 2009, at 10:54 AM, Pascal Voitot wrote:
Some questions arising in my head:
do you want to make the WYSIWYG the cornerstone of XWiki online
editing or
is it only the XWiki2.0 syntax editor?
do you want to make multi-syntax a key feature of XWiki or is it
only a
facility provided so that people can use easily XWiki and when they
are used
to it, they will naturally begin to use XWIki2.0 syntax?
If WYSIWYG is used only with XWiki2.0 syntax, it might look like you
are
strongly encouraging people to use XWIki2.0 syntax instead of other
syntaxes. Is it a good or bad strategy? I don't know... to be
discussed :)
IMO we must strongly encourage people to use the xwiki 2.0 syntax and
the other syntaxes are only a facility (at least for now and the
foreseeable future IMO). Reasons:
1) it's hard to fix all parsers for all syntaxes
2) other syntaxes are all way less powerful than the xwiki syntax.
3) there are issues with links in other syntaxes. For ex the ability
to link to multi wikis which doesn't exist in most syntaxes so they'll
only offer a very small subset of xwiki linking features and you
wouldn't be able to link between wikis. Unless we extend other
syntaxes of course (need to find syntax for doing that and write link
parsers for that)
4) the new wysiwyg only works well with the 2.0 syntax
5) We'd need to write syntax renderers for all syntaxes if we want
them to be equal to the xwiki 2.0 one but if we do so then we have the
issues raised in 2).
As time progresses we'll probably improve other syntax support but
right now we must encourage people to use the xwiki 2.0 syntax as much
as possible and consider the other syntaxes as migration strategies IMO.
WDYT?
Thanks
-Vincent
Pascal
On Sat, Jan 17, 2009 at 10:07 AM, Vincent Massol
<vincent(a)massol.net> wrote:
> Hi,
>
> Just realized that our new WYSIWYG editor will only work fine with
> our
> xwiki 2.0 syntax since other wiki syntaxes are less powerful and
> won't
> be able to express some complex structures (like embedding a document
> inside a table cell) or simply like styling a portion of text.
>
> Of course this is not a problem of the wysiwyg editor per see but in
> practice it means that users using it for other syntaxes when they
> save will get a different rendered result.
>
> So I"m tempted to say that our GWT editor will only work for the
> xwiki
> 2.0 syntax and that for the other syntaxes users will have to use the
> wiki editor.
>
> WDYT?
>
> Thanks
> -Vincent
12:11 p.m.
On Sat, Jan 17, 2009 at 11:36 AM, Vincent Massol <vincent(a)massol.net> wrote:
On Jan 17, 2009, at 10:54 AM, Pascal Voitot wrote:
It might even become crazy to support...
*One wiki to rule them all, one wiki to find them, one wiki to bring them
all, and in the darkness bind them.*
We know the end of the story :) So, Maybe, it would be better to propose an
nice API to add a new syntax parser. Some people might be interested in
developping the parser for their own needs and provide it to the community.
Some questions arising in my head:
do you want to make the WYSIWYG the cornerstone of XWiki online
editing or
is it only the XWiki2.0 syntax editor?
do you want to make multi-syntax a key feature of XWiki or is it
only a
facility provided so that people can use easily XWiki and when they
are used
to it, they will naturally begin to use XWIki2.0 syntax?
If WYSIWYG is used only with XWiki2.0 syntax, it might look like you
are
strongly encouraging people to use XWIki2.0 syntax instead of other
syntaxes. Is it a good or bad strategy? I don't know... to be
discussed :)
IMO we must strongly encourage people to use the xwiki 2.0 syntax and
the other syntaxes are only a facility (at least for now and the
foreseeable future IMO). Reasons:
1) it's hard to fix all parsers for all syntaxes
2) other syntaxes are all way less powerful than the xwiki syntax.
for this point, I trust you :)
3) there are issues with links in other syntaxes. For ex the ability
to link to multi wikis which doesn't exist in most syntaxes so they'll
only offer a very small subset of xwiki linking features and you
wouldn't be able to link between wikis. Unless we extend other
syntaxes of course (need to find syntax for doing that and write link
parsers for that)
If you extend other syntaxes, I'm not sure their creator will be happy
and you won't be compliant anymore with the real syntax.
The problem is also that other syntaxes will continue their evolution. If
you want to keep compliance, you will have to support these modifications.
It's an endless and non-sense work...
Being a "meta-something" (meta-wiki in our case) is always nice on paper but
it's rarely a possible project...
Finally, xwiki2.0 syntax might be the most powerful syntax today but
tomorrow, will it be true?Could it happen that the wysiwyg proposes a
feature for a specific syntax that is not supported by xwiki2.0?
4) the new wysiwyg only works well with the 2.0 syntax
It could evolve progressively so that this dependency is lazier and so that
one could add another syntax to the wysiwyg, deactivate unsupported features
from the interface etc...
5) We'd need to write syntax renderers for all syntaxes if we want
them to be equal to the xwiki 2.0 one but if we do so then we have the
issues raised in 2).
As time progresses we'll probably improve other syntax support but
right now we must encourage people to use the xwiki 2.0 syntax as much
as possible and consider the other syntaxes as migration strategies IMO.
I think you are writing "xwiki", not "xwiki for confluence users" for
example... So it's certainly better to promote your syntax which corresponds
to your vision, your architecture and your way of thinking...
But to bring compatibility with other syntaxes, I don't know what's the best
way: to write converters or to support the syntax directly in the editor...
The second option is quite sexy but it might be impossible to support. I
would say: "This is a marketing choice! What other syntax do we need to
support so that people tend to use our product and increase our market
share?"... Oh sorry I forgot this is an opensource project :)... But maybe,
you could think about supporting one or 2 other well-chosen syntaxes
which are commonly used to attract some people to XWiki and bring their new
ideas to our community!
Pascal
WDYT?
Thanks
-Vincent
Pascal
On Sat, Jan 17, 2009 at 10:07 AM, Vincent Massol
<vincent(a)massol.net> wrote:
> Hi,
>
> Just realized that our new WYSIWYG editor will only work fine with
> our
> xwiki 2.0 syntax since other wiki syntaxes are less powerful and
> won't
> be able to express some complex structures (like embedding a document
> inside a table cell) or simply like styling a portion of text.
>
> Of course this is not a problem of the wysiwyg editor per see but in
> practice it means that users using it for other syntaxes when they
> save will get a different rendered result.
>
> So I"m tempted to say that our GWT editor will only work for the
> xwiki
> 2.0 syntax and that for the other syntaxes users will have to use the
> wiki editor.
>
> WDYT?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:46 p.m.
Hi,
On Sat, Jan 17, 2009 at 12:11 PM, Pascal Voitot <pascal.voitot.dev(a)gmail.com
wrote:
> On Sat, Jan 17, 2009 at 11:36 AM, Vincent Massol <vincent(a)massol.net>
wrote:
>
> >
> > On Jan 17, 2009, at 10:54 AM, Pascal Voitot wrote:
> >
> > > Some questions arising in my head:
> > > do you want to make the WYSIWYG the cornerstone of XWiki online
> > > editing or
> > > is it only the XWiki2.0 syntax editor?
> > > do you want to make multi-syntax a key feature of XWiki or is it
> > > only a
> > > facility provided so that people can use easily XWiki and when they
> > > are used
> > > to it, they will naturally begin to use XWIki2.0 syntax?
> > >
> > > If WYSIWYG is used only with XWiki2.0 syntax, it might look like you
> > > are
> > > strongly encouraging people to use XWIki2.0 syntax instead of other
> > > syntaxes. Is it a good or bad strategy? I don't know... to be
> > > discussed :)
> >
> > IMO we must strongly encourage people to use the xwiki 2.0 syntax and
> > the other syntaxes are only a facility (at least for now and the
> > foreseeable future IMO). Reasons:
> > 1) it's hard to fix all parsers for all syntaxes
>
>
> It might even become crazy to support...
>
> *One wiki to rule them all, one wiki to find them, one wiki to bring them
> all, and in the darkness bind them.*
>
> We know the end of the story :) So, Maybe, it would be better to propose an
> nice API to add a new syntax parser. Some people might be interested in
> developping the parser for their own needs and provide it to the community.
>
>
> >
> > 2) other syntaxes are all way less powerful than the xwiki syntax.
>
>
> for this point, I trust you :)
>
>
> >
> > 3) there are issues with links in other syntaxes. For ex the ability
> > to link to multi wikis which doesn't exist in most syntaxes so they'll
> > only offer a very small subset of xwiki linking features and you
> > wouldn't be able to link between wikis. Unless we extend other
> > syntaxes of course (need to find syntax for doing that and write link
> > parsers for that)
>
>
> If you extend other syntaxes, I'm not sure their creator will be happy
> and you won't be compliant anymore with the real syntax.
> The problem is also that other syntaxes will continue their evolution. If
> you want to keep compliance, you will have to support these modifications.
> It's an endless and non-sense work...
> Being a "meta-something" (meta-wiki in our case) is always nice on paper
> but
> it's rarely a possible project...
> Finally, xwiki2.0 syntax might be the most powerful syntax today but
> tomorrow, will it be true?Could it happen that the wysiwyg proposes a
> feature for a specific syntax that is not supported by xwiki2.0?
>
>
> >
> > 4) the new wysiwyg only works well with the 2.0 syntax
>
>
> It could evolve progressively so that this dependency is lazier and so that
> one could add another syntax to the wysiwyg, deactivate unsupported
> features
> from the interface etc...
>
>
> >
> > 5) We'd need to write syntax renderers for all syntaxes if we want
> > them to be equal to the xwiki 2.0 one but if we do so then we have the
> > issues raised in 2).
> >
> > As time progresses we'll probably improve other syntax support but
> > right now we must encourage people to use the xwiki 2.0 syntax as much
> > as possible and consider the other syntaxes as migration strategies IMO.
> >
>
> I think you are writing "xwiki", not "xwiki for confluence users"
for
> example... So it's certainly better to promote your syntax which
> corresponds
> to your vision, your architecture and your way of thinking...
> But to bring compatibility with other syntaxes, I don't know what's the
> best
> way: to write converters or to support the syntax directly in the editor...
> The second option is quite sexy but it might be impossible to support. I
> would say: "This is a marketing choice! What other syntax do we need to
> support so that people tend to use our product and increase our market
> share?"... Oh sorry I forgot this is an opensource project :)... But maybe,
> you could think about supporting one or 2 other well-chosen syntaxes
> which are commonly used to attract some people to XWiki and bring their new
> ideas to our community!
>
> Pascal
>
>
I tend to agree with Pascal on this, on paper having our WYSIWYG editor
support every imaginable syntax is quite sexy, but in practice it means far
too big of a workload + it doesn't highlight all the work we've done to make
the XWiki 2.0 syntax ine of the most powerful wiki syntaxes available as of
today.
Making the new WYSIWYG editor work fine for the new syntax is already a
heavy task - and we're using our great new parser! So with parsers we know
less about and that might be buggy the tast of supporting them would become
daunting.
Thus it seems to me that both from a marketing PoW (pushing the new XWiki
2.0 syntax) and the technical one (using our development resources wisely)
it's better to tell our users that other syntaxes will work only with the
wiki editor for now and that they need to convert them to the XWiki 2.0
syntax to use the new editor (conversion works already, to the extent of
available parsers).
We can re-open the discussion in the future if demands for other syntaxes
support arises at a later stage. As of today, I think we'd better not do it.
Guillaume
>
>
> >
> > WDYT?
> >
> > Thanks
> > -Vincent
> >
> > > Pascal
> > >
> > > On Sat, Jan 17, 2009 at 10:07 AM, Vincent Massol
> > > <vincent(a)massol.net
wrote:
> > >
> > >> Hi,
> > >>
> > >> Just realized that our new WYSIWYG editor will only work fine with
> > >> our
> > >> xwiki 2.0 syntax since other wiki syntaxes are less powerful and
> > >> won't
> > >> be able to express some complex structures (like embedding a document
> > >> inside a table cell) or simply like styling a portion of text.
> > >>
> > >> Of course this is not a problem of the wysiwyg editor per see but in
> > >> practice it means that users using it for other syntaxes when they
> > >> save will get a different rendered result.
> > >>
> > >> So I"m tempted to say that our GWT editor will only work for the
> > >> xwiki
> > >> 2.0 syntax and that for the other syntaxes users will have to use the
> > >> wiki editor.
> > >>
> > >> WDYT?
> > >>
> > >> Thanks
> > >> -Vincent
> > _______________________________________________
> > 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
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype ID : wikibc
http://guillaumelerouge.com/
2:55 p.m.
On Jan 17, 2009, at 12:11 PM, Pascal Voitot wrote:
No we would be compliant. Only in one direction.
Yes that's option 2 I proposed.
Yes if we had to choose another syntax to support we would probably
pick mediawiki IMO since lots of xwiki users are coming from there.
The first step is to implement the link parser for the mediawiki
syntax. Once this is done we're already covering about 80% of the
mediawiki syntax.
Back to the topic I think it's not too hard for the GWT editor to work
based on syntax capabilities. The editor dev team should have this in
mind but I don't think it's our priority. Once the first final release
of the GWT editor is done in march then we could introduce this for
other syntaxes.
-Vincent
On Sat, Jan 17, 2009 at 11:36 AM, Vincent Massol
<vincent(a)massol.net> wrote:
We have that already and we're not developing the other parsers.
They're already developed. Only problem is that they're buggy.
On Jan 17, 2009, at 10:54 AM, Pascal Voitot wrote:
It might even become crazy to support...
*One wiki to rule them all, one wiki to find them, one wiki to bring
them
all, and in the darkness bind them.*
We know the end of the story :) So, Maybe, it would be better to
propose an
nice API to add a new syntax parser. Some questions arising in my head:
do you want to make the WYSIWYG the cornerstone of XWiki online
editing or
is it only the XWiki2.0 syntax editor?
do you want to make multi-syntax a key feature of XWiki or is it
only a
facility provided so that people can use easily XWiki and when they
are used
to it, they will naturally begin to use XWIki2.0 syntax?
If WYSIWYG is used only with XWiki2.0 syntax, it might look like you
are
strongly encouraging people to use XWIki2.0 syntax instead of other
syntaxes. Is it a good or bad strategy? I don't know... to be
discussed :)
IMO we must strongly encourage people to use the xwiki 2.0 syntax and
the other syntaxes are only a facility (at least for now and the
foreseeable future IMO). Reasons:
1) it's hard to fix all parsers for all syntaxes Some people might be interested in
developping the parser for their own needs and provide it to the
community.
Sure. All we need is to write a tutorial.
2) other
syntaxes are all way less powerful than the xwiki syntax.
for this point, I trust you :)
3) there are issues with links in other syntaxes. For ex the ability
to link to multi wikis which doesn't exist in most syntaxes so
they'll
only offer a very small subset of xwiki linking features and you
wouldn't be able to link between wikis. Unless we extend other
syntaxes of course (need to find syntax for doing that and write link
parsers for that)
If you extend other syntaxes, I'm not sure their creator will be happy
and you won't be compliant anymore with the real syntax. The problem is also that other syntaxes will continue
their
evolution. If
you want to keep compliance, you will have to support these
modifications.
It's an endless and non-sense work...
That's fine and ok since this is a community effort. It's not like
we're deciding to write parsers for all syntaxes.
Being a "meta-something" (meta-wiki in our
case) is always nice on
paper but
it's rarely a possible project...
It's really not far since there are already those other parsers
existing. Right now the main thing missing is the link parsers.
Finally, xwiki2.0 syntax might be the most powerful
syntax today but
tomorrow, will it be true?Could it happen that the wysiwyg proposes a
feature for a specific syntax that is not supported by xwiki2.0?
No since we're developing it with xwiki 2.0 syntax in mind.
Also it doesn't matter if some other syntax becomes more powerful
since that would work with the WYSIWYG editor (provided it's a
superset of the xwiki 2.0 syntax). Also we can have a xwiki 3.0 syntax
so there's no problem there.
4) the new
wysiwyg only works well with the 2.0 syntax
It could evolve progressively so that this dependency is lazier and
so that
one could add another syntax to the wysiwyg, deactivate unsupported
features
from the interface etc... 5) We'd
need to write syntax renderers for all syntaxes if we want
them to be equal to the xwiki 2.0 one but if we do so then we have
the
issues raised in 2).
As time progresses we'll probably improve other syntax support but
right now we must encourage people to use the xwiki 2.0 syntax as
much
as possible and consider the other syntaxes as migration strategies
IMO.
I think you are writing "xwiki", not "xwiki for confluence users"
for
example... So it's certainly better to promote your syntax which
corresponds
to your vision, your architecture and your way of thinking...
But to bring compatibility with other syntaxes, I don't know what's
the best
way: to write converters or to support the syntax directly in the
editor...
The second option is quite sexy but it might be impossible to
support. I
would say: "This is a marketing choice! What other syntax do we need
to
support so that people tend to use our product and increase our market
share?"... Oh sorry I forgot this is an opensource project :)... But
maybe,
you could think about supporting one or 2 other well-chosen syntaxes
which are commonly used to attract some people to XWiki and bring
their new
ideas to our community!
Pascal
>
> WDYT?
>
> Thanks
> -Vincent
>
>> Pascal
>>
>> On Sat, Jan 17, 2009 at 10:07 AM, Vincent Massol
>> <vincent(a)massol.net> wrote:
>>
>>> Hi,
>>>
>>> Just realized that our new WYSIWYG editor will only work fine with
>>> our
>>> xwiki 2.0 syntax since other wiki syntaxes are less powerful and
>>> won't
>>> be able to express some complex structures (like embedding a
>>> document
>>> inside a table cell) or simply like styling a portion of text.
>>>
>>> Of course this is not a problem of the wysiwyg editor per see but
>>> in
>>> practice it means that users using it for other syntaxes when they
>>> save will get a different rendered result.
>>>
>>> So I"m tempted to say that our GWT editor will only work for the
>>> xwiki
>>> 2.0 syntax and that for the other syntaxes users will have to use
>>> the
>>> wiki editor.
>>>
>>> WDYT?
>>>
>>> Thanks
>>> -Vincent
2:46 p.m.
Hi Vincent,
I remember we talked about this when I started to work on the WYSIWYG.
Therefor I implemented the new editor having in mind that it should be
as much as possible independent of the storing syntax. The diagrams I
had attached to XWIKI-2497 show that:
* you can define a SyntaxValidator for a specific syntax (like
XWikiSyntaxValidator for xwiki/2.0) to disable/enable features in
particular contexts. This validator is loaded based on the syntax
configuration parameter. See editwysiwygnew.vm for:
var Wysiwyg0 = {
...
syntax: "$doc.syntaxId",
...
};
* each plugin has access to the configuration object and thus can decide
based on the syntax parameter what to do. It can expose no features or
expose features based on the storing syntax. So you can put the bold
feature on the tool bar and the text plugin can associate a different
behavior based on the syntax.
All this is already implemented. Of course it needs to be improved. But
anyone willing to customize the behavior of the editor based on the
storing syntax should be able to do it.
So for me the question is: are we going to support other syntaxes on the
client side (custom WYSIWYG behavior) or just on the server side
(parser/renderer)? I guess the answer is: just on the server side for
the moment since the new editor is still not ready and it should work
perfectly with xwiki/2.0 syntax first.
Thanks,
Marius
Vincent Massol wrote:
Hi,
Just realized that our new WYSIWYG editor will only work fine with our
xwiki 2.0 syntax since other wiki syntaxes are less powerful and won't
be able to express some complex structures (like embedding a document
inside a table cell) or simply like styling a portion of text.
Of course this is not a problem of the wysiwyg editor per see but in
practice it means that users using it for other syntaxes when they
save will get a different rendered result.
So I"m tempted to say that our GWT editor will only work for the xwiki
2.0 syntax and that for the other syntaxes users will have to use the
wiki editor.
WDYT?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:58 p.m.
On Jan 17, 2009, at 2:46 PM, Marius Dumitru Florea wrote:
Hi Vincent,
I remember we talked about this when I started to work on the WYSIWYG.
Therefor I implemented the new editor having in mind that it should be
as much as possible independent of the storing syntax. The diagrams I
had attached to XWIKI-2497 show that:
* you can define a SyntaxValidator for a specific syntax (like
XWikiSyntaxValidator for xwiki/2.0) to disable/enable features in
particular contexts. This validator is loaded based on the syntax
configuration parameter. See editwysiwygnew.vm for:
var Wysiwyg0 = {
...
syntax: "$doc.syntaxId",
...
};
* each plugin has access to the configuration object and thus can
decide
based on the syntax parameter what to do. It can expose no features or
expose features based on the storing syntax. So you can put the bold
feature on the tool bar and the text plugin can associate a different
behavior based on the syntax.
All this is already implemented. Of course it needs to be improved.
But
anyone willing to customize the behavior of the editor based on the
storing syntax should be able to do it.
Great stuff! :)
So for me the question is: are we going to support
other syntaxes on
the
client side (custom WYSIWYG behavior) or just on the server side
(parser/renderer)? I guess the answer is: just on the server side for
the moment since the new editor is still not ready and it should work
perfectly with xwiki/2.0 syntax first.
Yep.
Re other syntaxes, I think it'll happen progressively depending on the
user demand and depending on contributions too. What we need to do
though is write some rendering tutorials to explain how to introduce
new syntaxes , new parsers, new macros and new renderers.
Thanks
-Vincent
Thanks,
Marius
Vincent Massol wrote:
> Hi,
>
> Just realized that our new WYSIWYG editor will only work fine with
> our
> xwiki 2.0 syntax since other wiki syntaxes are less powerful and
> won't
> be able to express some complex structures (like embedding a document
> inside a table cell) or simply like styling a portion of text.
>
> Of course this is not a problem of the wysiwyg editor per see but in
> practice it means that users using it for other syntaxes when they
> save will get a different rendered result.
>
> So I"m tempted to say that our GWT editor will only work for the
> xwiki
> 2.0 syntax and that for the other syntaxes users will have to use the
> wiki editor.
>
> WDYT?
>
> Thanks
> -Vincent
>
5724
days inactive
5724
days old
8 comments
4 participants
participants (4)
-
Guillaume Lerouge -
Marius Dumitru Florea -
Pascal Voitot -
Vincent Massol