I have been working on a REST API using the excellent tools provided by Yii2. My problem was that I have to differentiate between empty values and null values. In other words, <elem></elem> is different from null as it represents an empty string. Also, although some use <elem/> to represent a null value it should still be interpreted as an empty string. In other cases, the absence of the element is taken to represent a null value, but this may create problem with some parsers.
This article is helpful only if you have the following situation:
A web app which uses facebook login to login its users and if a user is logged out from his/her facebook account through another browser tab, then your app dont know that he is logged out out or not from his facebook account and he/she will remain as logged in your web application.Its ok if you have no problem with this situation.But if you want to forcefully logout the user from your application if he is logged out from his facebook account means you can try this example.This example uses periodic ajax calls to facebook's graph api to check whether the user is logged in or not.
In many cases developers of one project use their own local environments for coding. There may be a common test platform and, of course, production. All these environments usually have different DB credentials and directory structures (first of all, path to YII framework directory). Another feature is debugging. It's convenient to turn it on for local environments, eventually - on the test server and never (generally speaking) - on the production.
You may have scenarios, where you want to store a specific array configuration to the database. A classic example could be saving Yii widget configuration to the database and then retrieving it at runtime, with dynamic parameters set. This wiki discusses one of the approaches to do this. Let's consider you have something like the NavBar configuration below to store in the db:
There came the need to perform two operations, always, on 'application boot' time. Example? My real world example involved some geo-location logic (that's the first operation) and syncing of some session details so KcFinder can be in sync with the user in context - each user with his own session container (the second).
One of the common tasks the web application might be required to perform, especially the app using some kind of a CMS, is to save the history of data changes. Your client for sure will want the answer to this simple question - If I mess this up or delete by accident can we bring it back? Well, DB backup is one thing and quick recovery is another - let's talk about latter one.