django-cms, django-wikiapp and WYSIWYG editors
bobhaugen
this morning, but now I'm reconsidering. I promised to post my
requirements here, thus this message. It's sortof rambling, sorry.
When I understand all the issues better, I will write something more
coherent.
Looking at my requirements, I think they ~might~ fit django-wikiapp
with a good WYSIWYG editor better than (for example) django-cms.
If I understand the differences between django-cms and django-wikiapp,
they include:
* cms documents are maintained in admin, while wiki articles are
maintained (in Pinax) by Tribe and Project members.
* wiki articles (in Pinax) belong to Tribes and Projects, while cms
docs appear to be "global" to a site.
* wiki articles have version history, comments and tags, while cms
docs don't.
* cms docs are hierarchical, while wiki articles are not.
* both django-cms and django-wikiapp use so-called "simple" markup
formats; neither offers WYSIWYG editing.
* both cms and wiki allow internal hyperlinks between docs, but wikis
make it a bit simpler with WikiWords.
I recognize that all of the above features would be changeable (it's
only code), but they imply some differences in concept and goals
between CMS and wiki. Looks like CMS is aimed at staff writers, while
wikis are aimed at user-generated content.
Here's what I got from my client:
"Archives of Key Circle Documents. Each circle posts agendas, sends
notices, keeps minutes and keeps copies of proposals it adopts. We'd
like a central storage place that's web-based. We can start with
meeting minutes and proposals adopted. A simple ontology that uses our
jargon, that is nested, and is searchable would seem to fit the bill."
"Circles" are something like a combination of Tribes and Projects in
Pinax lingo. The documents will belong to a circle, and be edited by
members of the circle. The ontology could be tags (although tags are
not nested), or I could add hierarchical categories.
I am pretty sure they will want collaborative editing, comments,
version history and WYSIWYG. Markdown, ReST and Textile are pretty
flakey and cranky, at least in django-wikiapp. (Not that the web
WYSIWYG editors are not flakey and cranky...)
In short, I think they want user-generated content.
Aside about WYSIWYG editors:
I understand that TinyMCE is what most Pinheads (is that name still
current?) have been looking at, but somebody named ericdrex mentioned
WYMeditor on http://code.google.com/p/django-hotclub/wiki/WishList
It looks pretty good to me. Has anybody had any experience with it?
Or any deep experience with TinyMCE in a Django app?
Anyway, comments, criticisms and suggestions about any of this are
welcome.
James Tauber
On Oct 14, 2008, at 10:11 PM, bobhaugen wrote:
> I mentioned wanting a CMS for an upcoming Pinax project on #pinax irc
> this morning, but now I'm reconsidering. I promised to post my
> requirements here, thus this message. It's sortof rambling, sorry.
> When I understand all the issues better, I will write something more
> coherent.
>
> Looking at my requirements, I think they ~might~ fit django-wikiapp
> with a good WYSIWYG editor better than (for example) django-cms.
>
> If I understand the differences between django-cms and django-wikiapp,
> they include:
> * cms documents are maintained in admin, while wiki articles are
> maintained (in Pinax) by Tribe and Project members.
Yes, one common different is that CMSes focus more on staff-
maintenance of content whereas Wikis focus more on user-maintenance of
content (although understandably it's a spectrum)
> * wiki articles (in Pinax) belong to Tribes and Projects, while cms
> docs appear to be "global" to a site.
wikiapp supports global wiki articles -- we just haven't hooked it up
that way.
> * wiki articles have version history, comments and tags, while cms
> docs don't.
A CMS could have those things. We would probably add them to django-cms.
> * cms docs are hierarchical, while wiki articles are not.
That's typically true. CMSes tend to have some structure to which
pages are attached whereas Wikis tend to be more flat.
> * both django-cms and django-wikiapp use so-called "simple" markup
> formats; neither offers WYSIWYG editing.
I think django-cms has WYSIWYG editing via TinyMCE and it would be
easy to add to wikiapp.
> * both cms and wiki allow internal hyperlinks between docs, but wikis
> make it a bit simpler with WikiWords.
Yes, at the expense of requiring a flatter structure typically.
> I recognize that all of the above features would be changeable (it's
> only code), but they imply some differences in concept and goals
> between CMS and wiki. Looks like CMS is aimed at staff writers, while
> wikis are aimed at user-generated content.
That's the general distinction, yes; it's very much a spectrum
nowadays, though.
> Here's what I got from my client:
>
> "Archives of Key Circle Documents. Each circle posts agendas, sends
> notices, keeps minutes and keeps copies of proposals it adopts. We'd
> like a central storage place that's web-based. We can start with
> meeting minutes and proposals adopted. A simple ontology that uses our
> jargon, that is nested, and is searchable would seem to fit the bill."
>
> "Circles" are something like a combination of Tribes and Projects in
> Pinax lingo. The documents will belong to a circle, and be edited by
> members of the circle. The ontology could be tags (although tags are
> not nested), or I could add hierarchical categories.
>
> I am pretty sure they will want collaborative editing, comments,
> version history and WYSIWYG. Markdown, ReST and Textile are pretty
> flakey and cranky, at least in django-wikiapp. (Not that the web
> WYSIWYG editors are not flakey and cranky...)
>
> In short, I think they want user-generated content.
Because of the spectral nature of CMS versus Wiki, we may end up with
a hybrid.
> Aside about WYSIWYG editors:
> I understand that TinyMCE is what most Pinheads (is that name still
> current?) have been looking at, but somebody named ericdrex mentioned
> WYMeditor on http://code.google.com/p/django-hotclub/wiki/WishList
>
> It looks pretty good to me. Has anybody had any experience with it?
> Or any deep experience with TinyMCE in a Django app?
I don't have experience with either so am open to either.
> Anyway, comments, criticisms and suggestions about any of this are
> welcome.
James
Nicola Larosa
> Aside about WYSIWYG editors:
> I understand that TinyMCE is what most Pinheads (is that name still
> current?) have been looking at, but somebody named ericdrex mentioned
> WYMeditor on http://code.google.com/p/django-hotclub/wiki/WishList
I don't yet have much experience with WYSIWYG editors; however, I
evaluated what's available, and rejected both TinyMCE and FCKEditor
because of their code bloat.
WYMEditor seems leaner, with a good focus, and it's based on jQuery, so
less reinventing the wheel there. I'm going to use it in the next days.
As an aside, I used and like markItUp! . It's not WYSIWYG, it uses the
"simple" markup languages that you don't seem to like. :-) It does have a
preview command, though.
--
Nicola Larosa - http://www.tekNico.net/
The policy-makers at the Federal Reserve System can expand the money
supply, which leads to price inflation, which hurts the average citizen,
yet the public does not rise up in arms to tell Congress to keep the
Federal Reserve System from expanding the money supply.
- Gary North, June 2008
bobhaugen
> As an aside, I used and like markItUp! . It's not WYSIWYG, it uses the
> "simple" markup languages that you don't seem to like. :-) It does have a
> preview command, though.
impression.
It's not that I don't like the simple markup languages.
I was one of the very early users of Ward Cunningham's original wiki
http://c2.com/ . I liked that markup just fine. But it was
predictable. Markdown, ReST and Textile are not (at least in the
Pinax wiki). For example, getting hyperlink labels to work according
to the documentation is usually beyond me. (That's true, at least for
me, in the Python ReST online trial editor, too, so I don't think it's
just the Pinax wiki...)
And even if they were reliable, my experience with wiki
implementations (which I did for a living for 2 years) said that most
users much prefer WYSIWYG. I was a JotSpot consultant, where you
could select simple markup or WYSIWYG (or HTML) as a user preference.
I tried to get people to use the simple markup because it was more
reliable than the WYSIWYG editor, but almost nobody followed my advice.
Eduardo O. Padoan
I would love a contribution to add WYSIWYG to wikiapp. In fact, there
needs very little changes to wikiapp to add this features.
--
Eduardo de Oliveira Padoan
http://djangopeople.net/edcrypt/
http://stopforwarding.us/etiq.html
bobhaugen
wrote:
> needs very little changes to wikiapp to add this features.
gets there first.
Might try WYMeditor as a first step.
-Bob Haugen
Milan Andric
Bob,
I wouldn't go with TinyMCE, it's not tiny at all. Here's a couple
editors I have book marked ... check them out.
http://delicious.com/milo/wysiwyg
I'm interested in doing something like this also. We could make it
part of the Chicago Djangonauts contribution!
So now thinking requirements, we need to find a wysiwyg editor that
can render wiki markup right? So that it's compatible with wikiapp?
Also there's a little known feature with wiki that allows grouping.
I've never played with it, but that is a supposed solution to the wiki
are completely flat problem. I remember seeing support for it in
wikiapp but I could be wrong. We could look into that too.
--
Milan
bobhaugen
> I'm interested in doing something like this also. We could make it
> part of the Chicago Djangonauts contribution!
> So now thinking requirements, we need to find a wysiwyg editor that
> can render wiki markup right? So that it's compatible with wikiapp?
user selected for the article.
Don't know how that works with the WYSIWYG editors which look to me
(at first glance) like they want to be global, or maybe for all
textareas by user preference. And they want to control the text area,
putting their controls around it. Which is not the same as the simple
markups where you get a plain text area and then select which markup
you want applied.
In the case of my upcoming project, I won't care because I will just
make whatever WYSIWYG editor global. But for Pinax and wikiapp, it's
trickier. (Unless I am missing something...?)
Milan Andric
Using a wysiwyg editor in wikiapp or your app for that matter should
be completely optional. It sound like the kind of thing that would be
in settings.py, like settings.WIKI_USE_WYSIWYG. So If you use this
setting in wikiapp then you don't get the select markup dropdown,
wikiapp will set that for you depending on the setting. That's how I
imagine it would work.
--
Milan
James Tauber
On Oct 15, 2008, at 6:42 PM, Milan Andric wrote:
> Using a wysiwyg editor in wikiapp or your app for that matter should
> be completely optional. It sound like the kind of thing that would be
> in settings.py, like settings.WIKI_USE_WYSIWYG. So If you use this
> setting in wikiapp then you don't get the select markup dropdown,
> wikiapp will set that for you depending on the setting. That's how I
> imagine it would work.
Yes, in fact I would also like a site developer to be able to control
the available markup languages via settings anyway.
James
Eduardo O. Padoan
>
> On Wed, Oct 15, 2008 at 8:46 AM, bobhaugen <bob.h...@gmail.com> wrote:
>>
>> On Oct 15, 6:44 am, "Eduardo O. Padoan" <eduardo.pad...@gmail.com>
>> wrote:
>>> I would love a contribution to add WYSIWYG to wikiapp. In fact, there
>>> needs very little changes to wikiapp to add this features.
>>
>> Any tips? I'll probably do it in a couple of weeks if nobody else
>> gets there first.
>>
>> Might try WYMeditor as a first step.
>>
>
> Bob,
>
> I wouldn't go with TinyMCE, it's not tiny at all. Here's a couple
> editors I have book marked ... check them out.
> http://delicious.com/milo/wysiwyg
>
> I'm interested in doing something like this also. We could make it
> part of the Chicago Djangonauts contribution!
>
> So now thinking requirements, we need to find a wysiwyg editor that
> can render wiki markup right? So that it's compatible with wikiapp?
We could easely add a "html" choice for wikiapp's markups
> Also there's a little known feature with wiki that allows grouping.
> I've never played with it, but that is a supposed solution to the wiki
> are completely flat problem. I remember seeing support for it in
> wikiapp but I could be wrong. We could look into that too.
This feature is used on cloud27, wikis are grouped by projects and
tribes. By I think that Bob wants deeper hierarchies. On moinmoin this
is done putting slashes in the article name :/
Eduardo O. Padoan
Its already possible, just define WIKI_MARKUP_CHOICES.
http://code.google.com/p/django-wikiapp/source/browse/trunk/docs/install.txt#17
> James
bobhaugen
wrote:
> > I've never played with it, but that is a supposed solution to the wiki
> > are completely flat problem. I remember seeing support for it in
> > wikiapp but I could be wrong. We could look into that too.
>
> This feature is used on cloud27, wikis are grouped by projects and
> tribes. By I think that Bob wants deeper hierarchies. On moinmoin this
> is done putting slashes in the article name :/
since I don't think they understand them. Then add hierarchical
categories if need be. But in either case, the article space can be
flat, while one presentation can be a tree.
bobhaugen
Here's a tidbit from #pinax irc that's related to this thread:
http://oebfare.com/logger/pinax/2008/10/16/
14:49 jtauber
although we are talking about breaking the markup stuff out of blog
and wiki into a common app
14:51 Alex_Gaynor
that's probably a good idea
14:51 Alex_Gaynor
move the rendering out to python land as well, that way certain markup
can be optional
14:51 _newman_
jtauber, i've already started that and blog doesn't rely on wiki for
markup anymore (or shouldn't)
14:51 jtauber
_newman_: yes, I know you have -- hence my comment :)
14:52 jtauber
Alex_Gaynor: it is already optional, as edcrypt pointed out to me
14:52 Alex_Gaynor
oh
14:52 _newman_
what we might want to do is provide a setup of templates that don't
use all the other tags
14:52 Alex_Gaynor
I thought it didn't work without creole or something
14:52 jtauber
you can control the markup languages supported in settings.py
14:53 jtauber
see thread on pinax-users
14:53 jtauber
we definitely need to make sure that, for example, if we allow WYSIWYG
wikis then it will just work for blogs too
14:53 jtauber
or comments, etc
Milan Andric
Bob, well good to know, but there's little design talk so it's not
very helpful. Sounds like we have some thinking to do.
--
Milan
bobhaugen
Interesting post and even more interesting comments here:
http://www.37signals.com/svn/posts/1330-introducing-wysihat-an-eventually-better-open-source-wysiwyg-editor
Including Ian Bicking's recommended WYSIWYG editor:
http://trac.xinha.org/
More fodder for thinking and discussion...
Wes Winham
over all of the other wysiwyg editors I've tried. I'm actually using
it in a production document management system. I will admit that it
has a bit more of a learning curve than tinyMCE, but my users are to
the point where they're willing to spend a couple minutes to avoid the
unpredictability of tinyMCE when dealing with lists and such.
It works great for me because the content we manage is designed to be
uniform, so basic html plus some site-wide CSS does a wonderful job of
making editing just about the content, and not about the formatting.
I've run in to a couple bugs in ff 3 on linux, but it works well in
ie6, which is unfortunately where most of my users live. As a JQuery
user, I also really like the idea of being able to write any needed
plugins in jquery in the future, and having looked through the source,
I was actually able to get a handle on how things were working, which
is far from true for tinyMCE. It's about 4k lines with pretty decent
commenting and less than 2k of actual lines of code. Furthermore,
looking at their trac timeline, you know it's an active project (I
threw up a bug and got a response from a commiter within a couple of
days) and it has a consistent vision to be a simple editor focused
much more on just working very well for basic stuff than on adding a
lot of features and trying to mix css in to your html.
So I guess +1 for WYMEditor
-Wes
> Interesting post and even more interesting comments here:http://www.37signals.com/svn/posts/1330-introducing-wysihat-an-eventu...
bobhaugen
I just pointed the main client of my current Pinax project at Cloud27,
to see which features he thought we should adopt.
Sure enough, he copied and pasted from a Word doc into a Cloud27 blog
post.
I swear, I did not ask him to do this. I mean, people will.
Regardless.
You can see the results here:
http://cloud27.com/blog/post/worklaw/2008/10/HLTFIgnoresFS/
Short version:
"System Message: ERROR/3 (<string>, line 3)
Unexpected indentation."
So can WYMEditor handle copy-n-paste from Word? Can any of the
candidate WYSIWYG editors? Reliably?
Nicola Larosa
> You can see the results here:
> http://cloud27.com/blog/post/worklaw/2008/10/HLTFIgnoresFS/
>
> Short version:
> "System Message: ERROR/3 (<string>, line 3)
> Unexpected indentation."
That's a ReST error, the blog is parsing the text as ReStructuredText
(docutils) markup, it does not seem a problem with WYMEditor.
> So can WYMEditor handle copy-n-paste from Word? Can any of the
> candidate WYSIWYG editors? Reliably?
I don't know. It would seem likely, though.
--
Nicola Larosa - http://www.tekNico.net/
Tell me, and I will forget;
show me, and I may remember;
involve me, and I will understand.
- Confucius, 450 B.C.
James Tauber
>> So can WYMEditor handle copy-n-paste from Word? Can any of the
>> candidate WYSIWYG editors? Reliably?
Does anyone know what format the text is on the clip-board if you copy
from Word? I assume it's not full Word but something like RTF, and
then when you paste it, that's what's received by the control you
paste to.
I'd be surprised if javascript WYSIWYG editors could handle a paste
from a rich text format unless it's actually just HTML. Certainly
cutting and pasting styled HTML into WYMEditor works which was a small
victory :-)
/me goes to try Pages to WYMEditor
James
greg newman
in my experience never gets completely stripped out of the copy.
The only failsafe is to copy and paste from word to notepad or
textedit and convert to plain text. Then copy and paste that back
into the wysiwyg editor. Sometimes, you'll get lucky pasting from
word and other times you have problems where it can break the html and/
or css markup in the page.
greg newman
http://20seven.org
James Tauber
On Oct 28, 2008, at 6:10 PM, James Tauber wrote:
Interesting. Pasting from Pages (with bold text, heading and list)
kept font and block information but lost everything else (list bullet,
heading semantics). Clicking on WYMEditor's show html button resulted
in:
<p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px
Helvetica">This is a <strong>bold</strong> demonstration:</span></p><p
style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica">alpha</
span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px
Helvetica">beta</span></p><p style="margin: 0.0px 0.0px 0.0px 0.0px;
font: 12.0px Helvetica">Interesting</span></p><p style="margin: 0.0px
0.0px 0.0px 0.0px; font: 18.0px Helvetica"><strong>New Section</
strong></span></p></p>
Remember: WYSIAYG: What you see is ALL you get.
James
greg newman
better results with Pages.
greg newman
http://20seven.org
On Oct 28, 2008, at 6:10 PM, James Tauber wrote:
Eduardo O. Padoan
>
> bobhaugen wrote:
>> You can see the results here:
>> http://cloud27.com/blog/post/worklaw/2008/10/HLTFIgnoresFS/
>>
>> Short version:
>> "System Message: ERROR/3 (<string>, line 3)
>> Unexpected indentation."
>
> That's a ReST error, the blog is parsing the text as ReStructuredText
> (docutils) markup, it does not seem a problem with WYMEditor.
Blog/Wiki needs a preview. I have talked about it with dougn on irc
sometime ago.
Eduardo O. Padoan
<eduardo...@gmail.com> wrote:
> On Tue, Oct 28, 2008 at 7:38 PM, Nicola Larosa <nicola...@gmail.com> wrote:
>>
>> bobhaugen wrote:
>>> You can see the results here:
>>> http://cloud27.com/blog/post/worklaw/2008/10/HLTFIgnoresFS/
>>>
>>> Short version:
>>> "System Message: ERROR/3 (<string>, line 3)
>>> Unexpected indentation."
>>
>> That's a ReST error, the blog is parsing the text as ReStructuredText
>> (docutils) markup, it does not seem a problem with WYMEditor.
>
> Blog/Wiki needs a preview. I have talked about it with dougn on irc
> sometime ago.
(And I'm bringing this up because, with a preview, we could catch this
errors before trying to save. But validating the markup when trying to
save would be nice too.)
James Tauber
>
> Blog/Wiki needs a preview. I have talked about it with dougn on irc
> sometime ago.
Yes. Any more thoughts on breaking out the common "markup" pieces of
both as that might be the place to implement preview as well.
James
Wes Winham
through and strips out all of that junk. The big downside is that you
lose tables (or at least I have in everything I've tested from Open
Office) and you seem to lose most other formatting (bold, italics
etc.). All of the WYSIWYG editors I've used (WYMEditor, tinyMCE,
FCKeditor) have failed pretty miserably when it comes to copying and
pasting from word. WYMeditor opts to strip out the formatting and
tinyMCE and FCKeditor opt to pick up all of the style cruft.
For my purposes, I prefer stripping out formatting over generating
cruft that's difficult to maintain and modify over multiple revisions,
but I can definitely see uses where pasting correctly the first time
is all that really matters. I'm not sure which approach is better for
a general wysiwyg editor. The good thing about WYMEditor is that with
it's jquery roots and small codebase, it seems very possible that
someone will contribute the functionality that improve word pasting
recognition. Until then though, I'm not sure who the winner (best
loser?) is in regards to pasting from word.
-wes
roberto
I 've just joined this group.
I 've read this topic and I am not sure if the discussion about which
editor to integrate is already close (with WYMEditor as the winner) or
if we still have a little chance to continue investigating a bit.
I am asking because maybe we can have a look at kupu (the one which is
used in plone). I mean these guys develop with python so maybe there
is a reason to have it chosen.
Let me know f I can give a hand on this. I am a newbie python-django-
pinax dev but I would like to give some help to such a generous
community.
Roberto
bobhaugen
> I 've read this topic and I am not sure if the discussion about which
> editor to integrate is already close (with WYMEditor as the winner) or
> if we still have a little chance to continue investigating a bit.
with WYMEditor, and I like it too. If I understand their approach, it
might end up being the least buggy because the fewest tricks with the
content.
By the way, I just tried cut-n-paste from Open Office to WYMEditor
including simple formatting and a table, and it worked fine.
http://files.wymeditor.org/wymeditor/trunk/src/examples/01-basic.html
Anybody got Word running to try some experiments?
Re kupu, you'd need to make more of a case than Plone using it to get
me interested in yet another candidate.
bobhaugen
http://dojocampus.org/explorer/#Dijit_Editor_Basic
Accepts my Open Office past nicely. I know the Dojo guys tried to
accomodate Word once upon a time.
Can anybody with Microsoft Word do some tests of the various WYSIWYG
demos and report back? Please?
Hubertus Groepper
Word 2008 for Mac here, testing WYMeditor at http://
files.wymeditor.org/wymeditor/trunk/src/examples/01-basic.html
Pasting a simple document including a small table works ok as far as
I can tell. I didn't use the "paste from word" option but pasted
directly into a new paragraph. Basic formatting was pretty close to
the original Word file, though background colors and line styles on
the table were off. The generated markup (if that is what you get
when you hit the html icon) seems generally correct. No font-tags
etc., but some/many unneeded <p>s. Inside the table <td>s, everything
was contained in <p class="MsoNormalCxSpMiddle">. With the "paste
from word" option, all formatting is lost.
Pasting that same doc into the Dojo Editor looks even nicer (esp. for
the table), but some lines were pushed too much to the left and out
of the editor area. There is no way to see what markup is produced,
maybe I missed that option.
All in all, both look far more usable than TinyMCE (though I didn't
test that for a while).
hth
hubertus
Patrick
I have checked dozens of editors. The js based never strip any (or
most) of the Microsoft markup. FCK and TinyMCE also do a dreadful job
and unfortunately if you have large profiles or information sheets,
many paste from word. There is only one (for pay) editor that (as far
as I know) can handle paste from word directly and that is PinEdit.
But it's a full industrial strength editor and it costs a few 100 $.
However they did an excellent job with that (one of their
objectives).
Other than that: from FCK to Tiny, From NicEdit to JQuery.. they never
do it well. And I agree with Newman: we used a variety of editors in
Plone.. and had exactly that problem: sometimes it works OK sometimes
it doesn't and breaks your CSS or html.
The alternative is a an html field, with say linebreaks etc.. I
imagine that's the way facebook does it ?