> Write a recipe for it and try it. If it were that easy, I’d not post to the list. I am a web designer at best and not a full-fledged programmer. My knowledge of the inner workings of PmWiki is very limited. It usually takes me a lot of trial and error to get my own custom markup right (which usually just takes some input to generate some primitive html or wikicode).
That said, I do not think that creating and maintaining this functionality as a recipe is a good idea. I myself would not have the time (or knowledge / skill for that matter) to properly maintain and fix the recipe. Also this recipe could possibly introduce lots of vulnerabilities to PmWiki as it has to change parts of the inner workings of PmWiki (and you really don’t want to have a creative amateur coder messing with that stuff). As already stated in earlier posts to the list, I do not think that best solutions is to always put everything in recipes. That will eventually lead to unexpected cross-recipe behavior (which will lead to broken installations or even worse security vulnerabilities, which will lead to the dark side ;p). But for the sake of showing that I am willing to give it a try… Could someone please point out the proper functions / processes / workflow relevant when attempting to write this recipe for PmWiki? Is PmWiki written in procedural or oo php? I guess, that the simultaneously edits is either a function (or a method) that on save compares the timestamp current content of the page to the one that the page had when the user started editing and merges those if they don’t match. my proposal would set a var somewhere (would the best way be a page lock file like adobe uses for indesign files?) to indicate the page being locked upon editing if the editor has javascript support. every reader viewing that page would then trigger a comparison of the lock file’s timestamp to the current timestamp and if they deviate by more than let’s say ten minutes, delete the lock file. this will happen on every php request and if the viewer has js enabled every 2 minutes. the editor who triggered the lock will compare the id of the lock file to the one saved in a session var and if ===true be allowed to edit the page. a piece of jQuery js will then ajax in every 30 seconds to send a keepalive request and extend the locking period or send a delete request for the lockfile onunload. on save the editor will either request the lock file to be deleted or not (save and edit). as a fallback, the simultaneous edits function will stay in place to makes sure, that editors without js will still be allowed to edit. Take care, Josh On Sep/25, 2012, at 0244 , tamouse mailing lists wrote: > Write a recipe for it and try it. > > On Mon, Sep 24, 2012 at 12:05 PM, <[email protected]> wrote: >> I am currently using PmWiki for a collaboration project with a small but >> very active editor base on a restricted scope of pages. Simultaneous edits >> occur a lot and lead to time consuming rewriting of a page. It would be >> great to have an edit lock functionality. I have read >> http://www.pmwiki.org/wiki/PmWiki/PageLocking on the problems of page >> locking and the two options that were offered at the time and deemed to >> user-unfriendly to pursue. >> >> However I would like to present a third possibility which would allow >> reliable page locking and detection if an editor abandons the page using >> ajax. This will allow detection for unlocking almost in real time and would >> be a lot more user-friendly than the current simultaneous edits function. >> Now some might say, what if the editor gets disconnected from the internet >> by accident, but wants to conclude his/her edit of a page at a later time? >> For that case (the client failing to ajax in and no onunload event fired) a >> timer could be used that sets an ultimatum (maybe 10 minutes?) for the user >> to reconnect and conclude the edit. >> >> Yes, that would need cookies and it would need javascript. ajax has already >> been standardized in 2007 by the w3c. That said, I think PmWiki should be >> allowed to use cookies (which it already does for session handling) and >> javascript by default. Those who do live in the past, will have to fallback >> to the current simultaneous edits function. >> >> I’d like to hear opinions on that and of course a feedback if this is >> something that is doable and more important, if this is something that can >> be considered for future core functionality. >> >> Take care, >> Josh >> >> >> -- >> 李喬什 >> josh li >> >> 艺术指导 创意摄影 会展经理 >> ART DRCTR CREATIVE PHTGRPHR EXHIBIT MNGR >> >> mobile +49-1511-5794189 >> email [email protected] >> online http://joshleepictures.com >> linkedin http://linkedin.com/in/joshleepictures >> >> 22 aurikelweg >> 50259 pulheim >> germany >> >> >> _______________________________________________ >> pmwiki-users mailing list >> [email protected] >> http://www.pmichaud.com/mailman/listinfo/pmwiki-users _______________________________________________ pmwiki-users mailing list [email protected] http://www.pmichaud.com/mailman/listinfo/pmwiki-users
