The ideology behind Wave Framework was to give developer al the features of a modern web service and website framework while keeping PHP development itself still plain and simple. Developer should not have to learn about a large number of libraries and architecture design methods before they can implement their project on the framework. Developer should still be able to write their native and comfortable PHP code as much as they want without having to change their workflow too much. Wave Framework has only a few very simple requirements and recommendations for the developer in terms of architecture and code in order to support features from caching to compressions to dynamic loading of objects and more.
Wave Framework cannot be really compared against large scale frameworks that require a lot of configuration and planning and going through countless books in order to get up and running. This framework is intended primarily for projects that need to get up and running as fast as possible without compromises in quality or functionalities to do so. This is also why Wave is gaining recognition among some startup projects.
Web development has been slow to catch up with desktop programming over the years. Majority of web applications today get the whole MVC (Model-View-Controller pattern) wrong for the following reasons: views are tightly integrated and controllers often play a too multi-functional role in the entire system and are too tightly coupled with views. And a lot of web service API's (which allow you to connect different software systems with one another) within the last ten years or so have been developed as an additional plugin or an extension, rather than core part of the main functionality.
Wave Framework takes a different approach and keeps API in the center of everything. This is because every web service (even a website) that is being developed can also be developed as an API first and this helps to iron out most of the MVC-from-desktop-to-web kinks. This means that the software layer can be developed independently from the User Interface and then joined at any point during the development seamlessly. You can work on just your models and controllers and develop your entire software to work through API and then implement the UI by creating hooks in the views to that API.
This means that your entire software should work without any User Interface at all and after your models and controllers have been built, then your entire web service should be 100% functional. For example: if you build a Twitter client, then you should have logins, tweet submits, tweet reading and so on. Your visual and UI design team could work independently at the same time, coming up with the user interface while you're working on the functionality. At some point these two parts can be joined and a UI can be implemented across the API as you start implementing the Views.
What this API-centric development does is that it makes you entirely independent from your user interface. It's not just loose: it really is 100% independent. You can do everything through the API and this means that you can implement any kind of user interface and environment: be it web, desktop software or a mobile client.
This also makes testing - the bane of web developers due to multi-layered nature of the web - far easier: you can test the API separately from the UI very easily.
Desktop programming has largely worked this way for many years, but web has not yet caught up. Today - when the ability to quickly create mobile views of web services and/or mobile applications is business critical - this has become more important than ever and Wave Framework keeps that in mind.
Wave Framework includes a number of functionality that is useful only for development and is not useful when the project is deployed live. In order to make sure that your project is as secure as possible when deployed live, you should do the following:
Yes. While Wave Framework comes with fixed filesystem based Sitemap and Translations - as well as configuration - nothing stops you from building a system that allows you to generate these files. You could build a Content Management System where you can essentially build your website tree of URL's and then just generate a sitemap.ini file that Wave Framework understands.
Same applies to translations and configuration. You can essentially generate these files yourself and do with them whatever you want and Wave Framework will be able to function without problems.
Wave Framework has an API that can be used across HTTP very similarly to the principles of REST. But there are a couple of things that RESTful API would require that were considered not to be beneficial to the developer and seemed to be too restrictive. While you can build an API with Wave Framework that is very similar to how REST demands it, there are still some crucial differences:
Wave Framework does not implement this requirement for two reasons. First of all, if your API requires that a specific HTTP header is set for it to work, then you make it more difficult to implement the API in clients or software where it might be too difficult to make such a custom HTTP request. For example, a developer that builds a PHP system on a server that cannot use cURL but can use file_get_contents() over HTTP, would suddenly be unable to connect to your API. As a result, the API calls in Wave Framework are simply defined by a prefixed keyword of 'www-command' and the value of this can be for any model and any action, like 'users-get' or 'users-delete' while making the request over any HTTP method.
Wave Framework makes the input data independent from the request method entirely. It merges all the data down into a single array much like $_REQUEST variable in PHP. The idea of this is that you should never make an API request that defines two variables with the same keyword, this would be a bad design. Since Wave Framework makes the method of sending the variables completely open, you can make POST requests, GET requests and more without having to worry about the API returning different type of result.
Wave Framework does automatically implement the HTTP method header though for clients that still wish to use it, but this is not the recommended default behavior and you can read more about it in API documentation pages.
This means that if you want a JSON response, then it has to be defined in the headers. If you want an XML response, then you have to define it in headers again. Similarly to the previous point, Wave Framework API use is not strictly tied to the HTTP headers, you can send the response data type preference as part of the variables sent to API directly. And there are different API Handlers that can return different type of response by default.
Wave Framework API works through a single file that is assigned for the API and the URL's are intended for web pages themselves. Since Wave Framework can include API calls that cannot be easily mapped directly to objects or various features, it made little to no sense to restrict the developer and make them design a system that fits this URL approach.
In Wave Framework, you define your model and controller in the value of 'www-command' and that's it.
This can happen mainly because Internet Explorer 8 has triggered your website to work in compatibility mode of Internet Explorer 6/7 that does not support JSON object, thus throwing an error. Internet Explorer 8 often switches to compatibility mode internally (even without user intervention) when it has trouble finding what type of document is used - more specifically the doc-type of your HTML. Wave Framework View Controller has a HTML5 doc-type by default, which is not recognized by older Internet Explorer browsers, thus triggering compatibility mode.
It is possible to overcome this with Internet Explorer 8 by adding the following line to your header:
<meta http-equiv="X-UA-Compatible" content="IE=8" />
Wave Framework has simple methods that allow you to convert data to XML (and thus RSS) format from an array. An example array for an RSS feed would be like this:
$data=array( 'channel'=>array( 'title'=>'RSS Title', 'description'=>'This is an example RSS description', 'link'=>'http://www.example.com', 'lastBuildDate'=>date('D, d M Y H:i:s O',time()), 'pubDate'=>date('D, d M Y H:i:s O',time()), 'ttl'=>1800, 'item'=>array( 'title'=>'Example title', 'description'=>'Example description', 'link'=>'http://www.example.com', 'guid'=>'unique string per item', 'pubDate'=>date('D, d M Y H:i:s O',time()) ) ) );
Wave Framework uses PHP's own session handling to manipulate with user sessions and detect if sessions are used and what data is stored in $_SESSION. But sometimes it is important to use your own session handling, especially if sessions are stored on another server or through another system.
While there is no way to specify how Wave Framework handles sessions directly, it is possible in PHP to rewrite session handling functions that PHP natively uses (the same ones that Wave Framework implements). PHP function that defines all the functions used for session handling is the session_set_save_handler(). You can get more information about this function from PHP's own documentation. You should define the sessions you need in in the Autoload script in '/resources/scripts/script.php' file. Read more about Autoload scripts in its own documentation.
When browsers cannot decompress data that is sent from the server, then they may throw a warning page that says such. Some browsers, like Firefox, tend to fall back to non-compressed output, but Chrome browser (for example) requires the compression algorithms to work and throws a 330 error if it fails.
In order to see what is wrong, you should turn off output compression in your Configuration file. This allows you to see the exact output sent by the server.
Usually this compression error comes as a result of empty space existing after your PHP scripts, so make sure that the scripts you have edited do not have empty space after closing PHP tags. Alternative is to not use closing tags on PHP scripts at all.
There is a little-known bug in both Safari and Opera web browsers that ignore 'Vary' header from response HTTP request headers. 'Vary' header tells caching engines what header components to take into account when writing cache and validating cache in the storage. While Firefox, Chrome and Internet Explorer browsers all listen to this 'Vary' header as expected, Safari and Opera don't which means that sometimes these browsers may display cached content from time when there was no session cookie.
What is recommended is to not cache any pages (by setting www-cache-timestamp to 0 in Sitemap file or not defining it at all) that have user-specific information or simply wait until user reloads the page manually.
It is highly likely that the reason your POST variables get lost is due to a redirect. If you use the 'enforce-url-end-slash' configuration setting, then a request that is made to an URL is checked for a slash in the end of the request. And if the slash does not exist then the request is redirected to one that has a slash. While it is a common good practice to end your URL's with a slash, sometimes it can be easy to forget and if this setting is turned on then the POST variables are lost in the redirection. To avoid this problem you either have to turn the setting off, or make sure you always make your form submit happen to the proper URL that has a slash at the end of it.