0

I have an php framework which supports me building websites and allows me to edit the content directly in the frontend via inline editing. I have kind of an api, which receives the updates via an ajax call.

So far i was the only one using it, but in the future there could me more people editing the pages the same time, so the page has to be locked for other users the moment someone starts editing (maybe displaying which people are viewing the page at the moment as well).

I have some experience in php, javascript and a rough understanding of http requests, node.js and so on, but I am not an expert.

Now I would think, that i simply had to setup up a websocket server, tell the websocket server, when a user is viewing and editing a single page and update the page for the other clients and lock the editing buttons via javascript. So the Page would be only marked as locked on the websocket server.

Maybe I could check the status of the page when updating the content of a page by sending another request to the websocket server, if the page is locked. Or should i update the database directly through the websocketserver and mark the page as locked in the database?

Can you tell me if I'am on the right track or if it's a completely wrong approach?

PS: Even if it may be an overkill I still would want to try it only to practice, as I haven't used this technology so far :)

5
  • 1
    I think that websockets would be overkill for such a task. I would simply use a polling technique. Have your database engine save whether or not the page is locked and check for the lock before allowing users to edit. Commented Jun 17, 2015 at 13:57
  • 1
    Locking a page is not a matter of the transport mechanism. Lock the page in the db. For updating client UI's on a lock change, emitting an event over a websocket is a possibility. However it might be easier to simply try to get a lock when a user want's to start editing (which will result in a failure if the page is already locked). Commented Jun 17, 2015 at 14:00
  • But you wouldnt change the db through the websocket event, but through another seperate call right? this is really much easier - sometimes i think way to complicated :D Commented Jun 17, 2015 at 14:06
  • If I would still want to do it, it would be better to simply lock the page by an ajax request and send the event to the users right? Commented Jun 17, 2015 at 14:09
  • This really depends on your setup. But as you're already doing it with php and ajax, I would stick to that. Commented Jun 17, 2015 at 15:39

1 Answer 1

2

The approach that I would take is as follows:

Problem: (restating to show my understanding)

Notify clients when content is being edited to prevent conflicts.

Hard requirements:

Implemented using WebSockets -- for educational purposes.

Assumptions:

  • Sending the edited content will continue to be done via AJAX calls.
  • Clients do not need to know about content on pages that they're not currently viewing.
  • Clients should learn about the lock status of content once the page is loaded, before (or at least as soon as) the ability to edit content is available to the user.
  • It may become a requirement for all clients to be notified that contents on a page has been updated so that they can request an updated version through AJAX calls.
  • Multiple pieces of content may potentially be edited on a page, and locks should only apply on a per-content chunk basis, not a per-page basis. (I.e., a page that lists 10 customer addresses, if editing 1 address, let the other 9 be available for others to edit.)

Approach:

Personally, I'd use a PHP-based WebSockets server, but that's because I'm biased towards the one I wrote. Because of that, I'm going to approach this answer from a PHP-WebSockets perspective, and I apologize for any server specific implementation details that might not translate. That being said, it is far more important for you to use the tools that you're most comfortable with than to use a tool that I recommend, and I am trying to write in as general terms as possible.

Client JS:

  • On connecting, send the URL of the page that is loaded.
  • On initiating and completing (committing or aborting) edits, send a message indicating which bit of content on that page to lock/unlock.
  • Client may request the lock status of any bit of content at any time.

WebSockets Server:

  • On new connection, store the URL that they're on. (The same user can have multiple pages open in multiple browser tabs, but the client's page to socket relationship should always be 1-to-1.) If the page has content that is locked, send that connection a message saying which is locked.

  • On a new lock, store the URL, client, and which piece of content is being locked. Send a message to all clients who are registered to that URL (including the originator, who will use that reply as confirmation) on what content is now locked. If desired, store the lock status in the DB.

  • On removing a lock, remove the record for the URL, client, and which piece of content was locked, sending a message to all clients registered to the URL, and clearing the flag from the DB. Leave room in this method to poll the database/framework on whether the content was changed or not, to potentially tell the clients registered to that URL to invalidate their view and fetch fresh content.

  • On a query about any locks, respond with all locks that currently exist for that page.

  • On client disconnect, remove any locks. If locks are removed, notify all clients registered to the URL. If the user re-connects, it will be on a separate socket so they'll have to establish a new, different lock anyways. Clean up the connection details as well (no need to try to send messages down a pipe that's closed, right?).

Sign up to request clarification or add additional context in comments.

1 Comment

Hey Ghedipunk, Thank you very mich fpr your detailed answer. This is what nearly exactly what i planned to do now, after i thought about the problem for a while (overall at least :)) +1 - will take me some time, but i'll do it like this and will update this post later. Maybe someone else who's not so into websockets as well may need it

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.