You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Jürgen Ragaller <ra...@apache.org> on 2007/10/06 13:59:49 UTC
tinyMCE
Hi
From our last weeks editor teaching event we received two feedbacks
regarding tinyMCE:
1) If a user navigates away, the page remains locked and changes made
in tinymce are lost - this leads to frequent use of force checkin...
2) the german name of the Submit Button is «Einreichen» - identical
to the workflow name; should rather be save («Sichern»)
For 1) I suggest to add the tinymce plugin «autosave» to
tiny_config.js (a popup is shown when the user navigates away - it
has the option to save or cancel (just as it is done in bitflux).
For 2) I'd suggest to use «Save»
WDYT?
Jürgen Ragaller
ragaller@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: tinyMCE
Posted by Jörn Nettingsmeier <ne...@apache.org>.
solprovider@apache.org wrote:
> On 10/11/07, Jörn Nettingsmeier <ne...@apache.org> wrote:
>> while you're on the soapbox anyway, could you elaborate on how you are
>> going to merge (or avoid or whatever) simultaneous edits?
> I expect the design will mature.
>
> The first (current) version journals -- every save creates a new
> revision. This avoids locking and ignores the merge problem without
> losing data -- the "other" version is available, but any merging is
> manual.
fair enough.
> The next improvement will mark documents with unresolved branches.
> Each revision has a parent revision. Admins will have a view to find
> and fix documents with conflicts. A conflict document (translation)
> has two revisions with the same parent.
>
> Your design is the ultimate goal.
<snip>
> Obviously this level of merging is not appropriate for every element
> in every doctype:
> ORIGINAL: <myElement employee="Paul" salary="100000"/>
> EDIT1: <myElement employee="Paul" salary="200000"/>
> EDIT2: <myElement employee="Jorn" salary="100000"/>
> MERGE: <myElement employee="Jorn" salary="200000"/>
for some reason, i like this algorithm very much :-D
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: tinyMCE
Posted by so...@apache.org.
On 10/11/07, Jörn Nettingsmeier <ne...@apache.org> wrote:
> solprovider@apache.org wrote:
> > On 10/7/07, Jürgen Ragaller <ra...@apache.org> wrote:
> > The topic of this thread was preventing editors from easily and
> > frequently leaving documents locked. Removing locks eliminates that
> > issue.
> while you're on the soapbox anyway, could you elaborate on how you are
> going to merge (or avoid or whatever) simultaneous edits? if i
> understand the problem correctly, this requires intimate knowledge about
> the xml grammars involved, hence a new merging (or clash detection)
> algorithm would have to be written for every custom xml format. that
> sounds non-trivial to me.
> for wikis, this is not too hard, because you have just one very limited
> grammar to deal with. but for arbitrary xml formats?
> Jörn Nettingsmeier
I expect the design will mature.
The first (current) version journals -- every save creates a new
revision. This avoids locking and ignores the merge problem without
losing data -- the "other" version is available, but any merging is
manual.
The next improvement will mark documents with unresolved branches.
Each revision has a parent revision. Admins will have a view to find
and fix documents with conflicts. A conflict document (translation)
has two revisions with the same parent.
Your design is the ultimate goal. Some doctypes can automatically
merge revisions if the sets of changed fields do not intersect. Some
fields may be configured for SVN-like merging. Any problems revert to
marking a conflict. Knowledge of the XML format is only needed if the
default merge algorithm is not appropriate. The default is likely
elements within two levels from the root. Some doctypes may consider
every element to be a "field". Some may allow each property to be a
"field". An example of that last option:
ORIGINAL: <myElement x="1" y="A"/>
EDIT1: <myElement x="2" y="A"/>
EDIT2: <myElement x="1" y="B"/>
MERGE: <myElement x="2" y="B"/>
Obviously this level of merging is not appropriate for every element
in every doctype:
ORIGINAL: <myElement employee="Paul" salary="100000"/>
EDIT1: <myElement employee="Paul" salary="200000"/>
EDIT2: <myElement employee="Jorn" salary="100000"/>
MERGE: <myElement employee="Jorn" salary="200000"/>
With the original design, each doctype can have a specific edit screen
so a field like "employee" may not be changed. I would prefer
configuring the new doctype without programming. The configuration
would mark what is a "field" for merging and which fields may not be
changed. The merge code is easy; designing a configuration system
easily understood by humans will be a challenge.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: tinyMCE
Posted by Jörn Nettingsmeier <ne...@apache.org>.
solprovider@apache.org wrote:
> On 10/7/07, Jürgen Ragaller <ra...@apache.org> wrote:
> The topic of this thread was preventing editors from easily and
> frequently leaving documents locked. Removing locks eliminates that
> issue.
while you're on the soapbox anyway, could you elaborate on how you are
going to merge (or avoid or whatever) simultaneous edits? if i
understand the problem correctly, this requires intimate knowledge about
the xml grammars involved, hence a new merging (or clash detection)
algorithm would have to be written for every custom xml format. that
sounds non-trivial to me.
for wikis, this is not too hard, because you have just one very limited
grammar to deal with. but for arbitrary xml formats?
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: tinyMCE
Posted by so...@apache.org.
On 10/7/07, Jürgen Ragaller <ra...@apache.org> wrote:
> Am Oct 7, 2007 um 1:22 schrieb solprovider@apache.org:
> > The 1.3 specifications include no locks. Globally distributed
> > applications cannot have any locking. Two people edit on one server,
> > another is editing on another server, and a third is editing a local
> > repository while disconnected from the network. Lenya cannot mature
> > while using that obsolete paradigm.
>
> I don't think that lenyas checkout/locking mechanism for a cms is an
> obsolete paradigm.
>
> Checkout (Lock) informs editors working together on their site about
> other people working on the same document already. Working
> collaboratively on a website requires a lot of coordination
> (editorial work) - a single server providing information about who is
> doing what supports the team; lenya 2.0 helps with the features:
> notification, overviews for admin and checkout.
>
> If two people accidentially work on the same document, they would
> have to merge their text somehow (a svn approach); this makes more
> sense for program code then for cms text (for program code it's
> difficult already...).
>
> Disconnected work requires only a connection for the checkout /
> checkin; in between the offline work (in open office for example) is
> possible.
> Jürgen Ragaller
Start with your last statement. Pretend everybody works disconnected.
What was the purpose of the locking system?
People want to work on the same document. The only purpose of the
locking system is to prevent people from being productive. A merge
may be needed, but that is true whenever several people want to edit
the same document. Think Wiki. Temporary locking does not prevent
material from being overwritten by the next editor.
Locking annoys people trying to work. Locking often gets stuck; the
most common support request with any locking system is to have
something unlocked. Locking is useless in a distributed environment
because too many people will bypass it.
The topic of this thread was preventing editors from easily and
frequently leaving documents locked. Removing locks eliminates that
issue.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: tinyMCE
Posted by Jürgen Ragaller <ra...@apache.org>.
Hi, solprovider
thanks for the feedback
Am Oct 7, 2007 um 1:22 schrieb solprovider@apache.org:
> Dialog boxes are not safe workflow. Browsers and computers still
> crash accidentally and deliberately. Somebody will bypass any
> interface-based process.
Point taken - but I think at the moment the javascript solution is a
good pragmatic way to go.
>
> The 1.3 specifications include no locks. Globally distributed
> applications cannot have any locking. Two people edit on one server,
> another is editing on another server, and a third is editing a local
> repository while disconnected from the network. Lenya cannot mature
> while using that obsolete paradigm.
I don't think that lenyas checkout/locking mechanism for a cms is an
obsolete paradigm.
Checkout (Lock) informs editors working together on their site about
other people working on the same document already. Working
collaboratively on a website requires a lot of coordination
(editorial work) - a single server providing information about who is
doing what supports the team; lenya 2.0 helps with the features:
notification, overviews for admin and checkout.
If two people accidentially work on the same document, they would
have to merge their text somehow (a svn approach); this makes more
sense for program code then for cms text (for program code it's
difficult already...).
Disconnected work requires only a connection for the checkout /
checkin; in between the offline work (in open office for example) is
possible.
Jürgen Ragaller
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: tinyMCE
Posted by so...@apache.org.
Dialog boxes are not safe workflow. Browsers and computers still
crash accidentally and deliberately. Somebody will bypass any
interface-based process.
The 1.3 specifications include no locks. Globally distributed
applications cannot have any locking. Two people edit on one server,
another is editing on another server, and a third is editing a local
repository while disconnected from the network. Lenya cannot mature
while using that obsolete paradigm.
While trying to adapt Kupu to this requirement, I developed a
"virtual:" protocol. The VirtualModule, VirtualTransformer, and
VirtualSourceFactory classes are in the 1.3 branch, but may disappear
if no new need is found. While documents can be cached and edited in
memory, the documents are saved to a virtual ID. This is similar to
Flow Continuations with the additional functionality that these
documents are also accessible to XMAP operations: <map:generate
src="virtual:..." />. I could not decide when or how to clear the
cache for forgotten documents: 1 hour? 24 hours? When a certain
quantity of memory is used? I finally realized the algorithm was
broken.
After discarding Kupu, I researched other editors. Some had the same
issues. Others may have licensing issues. The final choice was
Xinha, a fork of HTMLArea. License is a BSD -- free for any use as
well as license is included (which I need to add to the 1.3 licenses
folder.) I have already customized for XHTML, need to fix a bug (adds
extra fields to submission), need to add Lenya-1.3-specific link
handling functions, and will improve the look later.
HTH,
solprovider
On 10/6/07, Jürgen Ragaller <ra...@apache.org> wrote:
> Good evening, Jörn
> Am Oct 6, 2007 um 21:33 schrieb Joern Nettingsmeier:
> > Jürgen Ragaller wrote:
> >> Hi
> >> From our last weeks editor teaching event we received two
> >> feedbacks regarding tinyMCE:
> >> 1) If a user navigates away, the page remains locked and changes
> >> made in tinymce are lost - this leads to frequent use of force
> >> checkin...
> >> 2) the german name of the Submit Button is «Einreichen» -
> >> identical to the workflow name; should rather be save («Sichern»)
> >> For 1) I suggest to add the tinymce plugin «autosave» to
> >> tiny_config.js (a popup is shown when the user navigates away - it
> >> has the option to save or cancel (just as it is done in bitflux).
> >> For 2) I'd suggest to use «Save»
> >> WDYT?
> > just a quick ACK - thanks for the feedback.
> > i'll see if i can look into this tomorrow, but no promises.
> > what kind of warning do you want?
> > something like this?:
> > "you are trying to navigate away from a page you are currently
> > editing. your changes will be lost if you proceed. [return to
> > editor] [abandon changes]"
> The autosave plugin has a message pretty similar to the one you
> wrote: "The changes you made will be lost if you navigate away from
> this page."
> But the problem with a simple "OK" is: no checkin is invoked (yet) so
> the user was warned about the loss of work but the result is still a
> locked page.
> I think it would be better to either not allow a user to navigate
> away from the page at all but rather force the user to use the Save
> or Cancel buttons (display just a warning with a ok button); OR If it
> is allowed to navigate away, a cancel event has to be invoked to
> unlock the page.
> The luxury version would be a window featuring 3 Options: 1) cancel
> (nothing happens, user stays in editor ) 2) discard changes (unlock
> document and go to the requested page) 3) save changes (save changes
> and go to the requested page).
> I think the autosave plugin shows how it could be done.
> Thanks, Jörn
> > regards,
> > jörn
> > jörn nettingsmeier
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: tinyMCE
Posted by Jürgen Ragaller <ra...@apache.org>.
Good evening, Jörn
Am Oct 6, 2007 um 21:33 schrieb Joern Nettingsmeier:
> hi jürgen!
>
> Jürgen Ragaller wrote:
>> Hi
>> From our last weeks editor teaching event we received two
>> feedbacks regarding tinyMCE:
>> 1) If a user navigates away, the page remains locked and changes
>> made in tinymce are lost - this leads to frequent use of force
>> checkin...
>> 2) the german name of the Submit Button is «Einreichen» -
>> identical to the workflow name; should rather be save («Sichern»)
>> For 1) I suggest to add the tinymce plugin «autosave» to
>> tiny_config.js (a popup is shown when the user navigates away - it
>> has the option to save or cancel (just as it is done in bitflux).
>> For 2) I'd suggest to use «Save»
>> WDYT?
>
> just a quick ACK - thanks for the feedback.
> i'll see if i can look into this tomorrow, but no promises.
> what kind of warning do you want?
> something like this?:
> "you are trying to navigate away from a page you are currently
> editing. your changes will be lost if you proceed. [return to
> editor] [abandon changes]"
Thanks for the reply
The autosave plugin has a message pretty similar to the one you
wrote: "The changes you made will be lost if you navigate away from
this page."
But the problem with a simple "OK" is: no checkin is invoked (yet) so
the user was warned about the loss of work but the result is still a
locked page.
I think it would be better to either not allow a user to navigate
away from the page at all but rather force the user to use the Save
or Cancel buttons (display just a warning with a ok button); OR If it
is allowed to navigate away, a cancel event has to be invoked to
unlock the page.
The luxury version would be a window featuring 3 Options: 1) cancel
(nothing happens, user stays in editor ) 2) discard changes (unlock
document and go to the requested page) 3) save changes (save changes
and go to the requested page).
I think the autosave plugin shows how it could be done.
Thanks, Jörn
> regards,
>
> jörn
>
>
>
> --
> jörn nettingsmeier
>
> home://germany/45128 essen/lortzingstr. 11/
> http://spunk.dnsalias.org
> phone://+49/201/491621
>
> Kurt is up in Heaven now.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: tinyMCE
Posted by Joern Nettingsmeier <ne...@folkwang-hochschule.de>.
hi jürgen!
Jürgen Ragaller wrote:
> Hi
>
> From our last weeks editor teaching event we received two feedbacks
> regarding tinyMCE:
>
>
> 1) If a user navigates away, the page remains locked and changes made in
> tinymce are lost - this leads to frequent use of force checkin...
> 2) the german name of the Submit Button is «Einreichen» - identical to
> the workflow name; should rather be save («Sichern»)
>
> For 1) I suggest to add the tinymce plugin «autosave» to tiny_config.js
> (a popup is shown when the user navigates away - it has the option to
> save or cancel (just as it is done in bitflux).
> For 2) I'd suggest to use «Save»
>
>
> WDYT?
just a quick ACK - thanks for the feedback.
i'll see if i can look into this tomorrow, but no promises.
what kind of warning do you want?
something like this?:
"you are trying to navigate away from a page you are currently editing.
your changes will be lost if you proceed. [return to editor] [abandon
changes]"
regards,
jörn
--
jörn nettingsmeier
home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621
Kurt is up in Heaven now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: tinyMCE
Posted by Jürgen Ragaller <ra...@apache.org>.
Am Oct 6, 2007 um 13:59 schrieb Jürgen Ragaller:
> Hi
>
> From our last weeks editor teaching event we received two feedbacks
> regarding tinyMCE:
>
>
> 1) If a user navigates away, the page remains locked and changes
> made in tinymce are lost - this leads to frequent use of force
> checkin...
> 2) the german name of the Submit Button is «Einreichen» - identical
> to the workflow name; should rather be save («Sichern»)
>
> For 1) I suggest to add the tinymce plugin «autosave» to
> tiny_config.js (a popup is shown when the user navigates away - it
> has the option to save or cancel (just as it is done in bitflux).
I realised, that the two buttons (Save / Cancel) must not trigger the
onbeforeunload handler from the autosave plugin (the onbeforeupdate
action can be overwritten using a
onclick="javascript:window.onbeforeupdate = true;" statement).
The autosave Plugin displays a screen showing an ok and a cancel
button - When the user clicks ok, she/he can navigate away from the
page without cancel being invoked - so the plugin is a quick start
but not sufficient. Maybe a new plugin is the best way to go?
> For 2) I'd suggest to use «Save»
>
>
> WDYT?
>
> Jürgen Ragaller
> ragaller@apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: tinyMCE
Posted by Jürgen Ragaller <ra...@null-oder-eins.ch>.
Am Oct 6, 2007 um 13:59 schrieb Jürgen Ragaller:
> Hi
>
> From our last weeks editor teaching event we received two feedbacks
> regarding tinyMCE:
>
>
> 1) If a user navigates away, the page remains locked and changes
> made in tinymce are lost - this leads to frequent use of force
> checkin...
> 2) the german name of the Submit Button is «Einreichen» - identical
> to the workflow name; should rather be save («Sichern»)
>
> For 1) I suggest to add the tinymce plugin «autosave» to
> tiny_config.js (a popup is shown when the user navigates away - it
> has the option to save or cancel (just as it is done in bitflux).
I realised, that the two buttons (Save / Cancel) must not trigger the
onbeforeunload handler from the autosave plugin (the onbeforeupdate
action can be overwritten using a
onclick="javascript:window.onbeforeupdate = true;" statement).
The autosave Plugin displays a screen showing an ok and a cancel
button - When the user clicks ok, she/he can navigate away from the
page without cancel being invoked - so the plugin is a quick start
but not sufficient.
> For 2) I'd suggest to use «Save»
>
>
> WDYT?
>
> Jürgen Ragaller
> ragaller@apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org