Re: [Tikiwiki-devel] Ajax save draft and auto save features

[Jonny B. <jo...@ti...>]

On 23 Dec 2009, at 12:22, Xavier de Pedro wrote:

> Great Idea, Nelson! :-)
> I was scared years ago when I tried it (as undocumented feature), and 
> since then, I always avoided that feature for production. With the 
> changes you propose, that would be perfect for improving autosave 
> feature in a more intuitive way (like in other apps., etc)
> Thanks for taking care of this improvement.
> My 2 cents.
> Cheers
> Xavi

Do you mean save draft or auto-save?

I never got to grips with save draft - or at least never found the drafts it said it had saved... but i did do some work on auto-save - so more inline below.

> En/na Nelson Ko ha escrit:
>> Hi,
>> 
>> I've been trying out the ajax auto-save feature and the save draft
>> features in trunk, and...
>> 
>> 1) 1st of all they don't work unless I add <input type="hidden"
>> name="page" value="{$page}" /> to the form, because it needs to read
>> that to work. I was going to commit that... Any objection? It
>> duplicate the page=xxxxx in the query string, but I suppose hat's ok.
>> It does not need to be escaped, right? (for a hidden form input var)

That's odd - for auto-save it worked for me without that (They are totally separate features, afaik, but i'm only talking about auto-save). From what i remember it uses a hash of pagename, user etc

>> 2) Secondly I don't understand the purpose of the "Save draft"
>> feature. What is saved is a "personal" draft which is not viewable by
>> anyone else except the person saving it, and the next time you edit
>> the page it shows the draft contents and "Draft last edited xxxxxxx".
>> This is really confusing if someone else has edited the page since...,
>> even if it says "Warning: new versions of this page have been made
>> after this draft". Is anyone using this feature? If yes, how to
>> improve it...., if no, can it be removed?

+1 for KIL

>> 3) As for the auto-save feature, it works but it auto-saves to a
>> temporary file and is not a real auto-save. Well, I suppose this might
>> work for edit lost protection, but again it is confusing because when
>> I edit the page again, it says: If you want the saved version instead
>> of this autosaved one Click Here. And if I view the page, it shows the
>> non-autosaved one. The problem is that this is just very different
>> from what other apps' auto-save does. But I can understand we may not
>> want to make the wiki history full of auto-saves....
>> 
>> Any suggestion?

This is just how it was when i came to it - i agree we wouldn't want the page history filled up with a new version every 60 seconds, so am more of less happy with how it is. I have found occasionally (still) that it will leave an auto-save version lying around when you've cancelled or saved an edit, but it's more reliable than it was.

>> I am actually suggesting that the above 2 features be combined into
>> one, called "auto-save" that behaves more like other apps and also
>> saves it to the wiki page. This will provide lost edit protection and
>> have some additional features as follows:
>> 
>> This new auto-save will save to the wiki history. There are two modes
>> that can be set by the admin.
>> 
>> Mode 1: all edits are saved to wiki history (simple)
>> 
>> Mode 2: only final edit is saved to wiki history. In the second mode,
>> there will be something in the history that indicates that this is an
>> auto-save. So when it auto-saves again, the wiki history will be
>> checked to see if it is in fact the same person auto-saving again. If
>> yes, then it will replace that history entry instead of adding one.
>> 
>> Any comments?

I agree we should merge them, but i'm not so sure about using the database & page history for this - ideally i suppose it's a good idea but the danger of it adversely affecting other features (translation tracking for instance, edit conflicts etc) makes me think it would be a large undertaking.

Good luck! :)

jonny


>> 
>> Nelson.
>> 
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev 
>> _______________________________________________
>> Tikiwiki-devel mailing list
>> Tik...@li...
>> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel
>> 
>> 
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Tikiwiki-devel mailing list
> Tik...@li...
> https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel