Symphony.

Hey I'm just curious how to go about doing such a thing

Like if I save a change anyone viewing the content will see it update.

I have seen this functionality with firebase and angular just Curious if that sort of thing can be done with symphony.

Cheers

I have in my section an extra 'preview' checkbox. In my template I check if an user is logged in or not. Simplified the code is like:

    <xsl:choose>
      <xsl:when test="//params/cookie-username">
      <!-- The user is logged in so show everything -->
          <xsl:apply-templates select="//content/entry" mode="main-article"/>
       </xsl:when>
      <xsl:when test="not(//params/cookie-username)">
          <xsl:apply-templates select="//content/entry[preview ='No']" mode="main-article"/>
      </xsl:when>
    </xsl:choose>

@Jeff, do you mean anyone who's currently on the frontend of the respective entry sees the page reload / data refresh if an entry is updated via the backend?

It seems I wasn't fully awake when I give my answer. I thought at that moment you don't want changes directly visible.

But instead you are looking for a kind of live reload / sync as gunglien mention? I think you need a javascript that poll the server every few seconds

I can think of a few more ways other than polls, but it depends on the infrastructure you have set up. Especially if you want something like a push functionality.

If you mean by way of injecting the update on the front-end site without a page refresh then that should be possible but all just JavaScript either way.

One of the best options I've seen at the moment is React - a front-end framework (not full-stack) which produces a virtual DOM and only diffs the changes. As it's all in memory it's lightening fast. It's event-based and uses JSX (a JavaScript syntax extension which looks a lot like XML - a benfit to Symphonians) to provide an easy way to keep the interface updated when data changes. It's a very clever library indeed.

They provide some great examples and tutorials on the github page. I've not yet tried it with Symphony specifically but it could be a pretty nice combination - especially with the JSX syntax.

Thanks for all the input,

Ya sorry if that wasnt clearer I meant people on the front end will see live changes. like a push event or a live chat kinda thing

I dont have anything set up just thinking about future projects and what this would entail. And what the best way to go about it would be.

ALSO Im not sure if it was possible without refreshing the datasource, Or if it would be better to give it a go with the symphony API extension.

I will check out react.thanks.

I don't get how React can work better than anything else in this case, it's not Jeff that'd be viewing the page that's having the data refreshed right?

I think @plenaforma has it above but it seems a bit mad unless the browser viewing had entered into some kind of live chat.

So it'd be the page keep checking if there's a newer entry on the server rather than you pushing the changes to them.

-edit

Probably news feed sites do it all the time, hadn't thought it through. Perhaps it'd work with some kind of carousel where you could slot the new data in the next time round.

Aren't we already doing part of this work by caching data until the cache is reset by saving an entry in the backend. Wouldn't just polling the server work without really doing much else?

If the cache is fresh then reload, however you want jQuery/json if you don't want to refresh the whole page.

When I thought it would be possible I was thinking something similar to a WebSocket thing. Which is an HTML5 compatible push application, you could connect it with a PHP/NODE/JAVA server, and it's a push-style thing (once a client is registered) thus in theory you could initiate a push to all users registered to be on a page. The push would be read by your frontend javascript, which would than take care of the 'rendering' obviously you want your users to know that the data is/has changed so that might be a bit tricky, but it could be quite seamless with no polling.

The only constraint that I've been made aware of using this technique is that apparently websockets have a limitation on the number of connections that could be opened by clients, but the technology might have advanced since I've used it, (and the implementation I've used had been stripped to barebones so functionality was much reduced)

That's similar to livechat except it's supposedly a human sending the data, not sure if the ones I've been on would pass the Turing test though.

Sounds really interesting, would you run the DS on a separate page and then copy the data/html to the main page?

There seems to be several push services out there like this one,

https://pusher.com/tutorials/html5realtimepush_notifications

I suppose with this type of setup, you could listen for the push and ajax in the new content.

Also theres also http://socket.io/

the node.js server, im not sure how that would work yet. Is this the type of server you are talking about @gunglien?

There's quite a bit of scope to this topic as there are potentially many different levels you can take it to. If you're talking about websockets and realtime bi-directional communication such as chat then you'd need server-side connections. This isn't something that Symphony is geared up to handle without some extensive modifications in it's current incarnation. Typically you could look to use something like Node.js which is event-based by nature or ReactPHP if you wanted to go the PHP route - with React even outperforming Node.js in some tests. Fundamentally though, the architecture is very different to Symphony as we're talking about very different times of conception and goals. Symphony wasn't built with the intention of creating realtime web-apps.

On top of that Websockets can be used to provide realtime data communication. After that you can pretty much name your poison. The likes of Meteor and React JS straddle the line between client and server by potentially running on both (although React JS isn't so much as a framework as a library which aims at tackling the View in MVC). There are tonne of other JavaScript frameworks and libraries which can be used to provide a 'data binding' from Model through to the View from full-stack to lightweight so it's really just a case of preference with that argument never having a right or wrong - just best for a particular use case.

If you're going to use a JavaScript framework then the trouble is that they will then require their own templating - Angular will use it's own Directives and syntax, React JS will use JSX or plain JavaScript (although it isn't actually a template language), Ember JS will use Handlebars, even Backbone views will need to be rendered with whatever template language you prefer. Essentially though they would work in place of XSLT rather than in addition to it. So with that in mind the only way you can really work it is to setup an API (API Page or REST API can help) in Symphony and then use your chosen framework/library/components on the front-end to listen for changes in the feed output (XML/JSON) and then update the client. This wouldn't be realtime and you couldn't build a chat application out of it but it would provide a way to update the client upon saving of data in Symphony (server-side) without having to refresh the page. It also wouldn't flood the server with polling as it would rely on pub/sub and data-binding. Essentially though it's just making AJAX calls to the webserver.

If you're looking to build a realtime chat application of web app then I wouldn't look to use Symphony. There are horses for courses. Symphony is a CMS built on a very different architecture. Web applications will typically be API-driven and wont need a visual CMS on the back-end — a UI would typically be built for purpose and you're always far better to start something like that on the right architecture.

Thats some great info thanks!