Taylor is a freelance web and desktop application developer living in Suzhou in Eastern China. Started from Borland development tools series (C++Builder, Delphi), published a book on InterBase, certified as Borland Expert in 2003, he shifted to web development with typical LAMP configuration. Later he started working with jQuery, Symfony, Bootstrap, Dart, etc.
Back in the times of Symfony 1.x, the framework had a powerful backend module to help the developers and site administrators create a good enough app and provide necessary CRUD features to manage the database (and save us from using PHPMyAdmin).
Since Symfony 2, this has been taken out from the core and the developers either have to rely on their own to start from scratch or rely on some other third party Symfony 2 bundle when such a feature is needed – and in many circumstances, it is.
In this article, we will take a look at Phreeze, a simple and easy to use PHP framework that can help us generate a MySQL CRUD backend app. I will use my book collection test site as the underlying database. Please refer to my Data Fixtures in Symfony2 article for more details on the database structure.
Installation and bootstrapping
Phreeze is distributed as standalone. You can clone a copy of its latest version from Github.
In my environment, I have created a new virtual host
testand cloned the repository to its
phreezefolder so that I can start the backend generation with Phreeze using:
To facilitate the generation of a backend, Phreeze introduces two step wizard-like screens to guide us.
In the first screen, we will provide the necessary database connection information (server, database/schema, user, password):
In my [Building a Personal Web App Head To Toe With Symfony 2](http://www.sitepoint.com/series/building-a-personal-web-app-head-to-toe-with-symfony-2/) series published on Sitepoint, I have covered some basics in bootstrapping, development and finalizing (on some advanced techniques) to use Symfony 2 to develop a web application. However, due to the length limitation of the series, we have not covered much on the “final” step: To deploy a Symfony 2 application to the production environment.
When we do development, most likely we are in a “root” role; but in a production environment, we may be deprived of this privilege. Also, the settings may be different. To make things worse, sometimes we are not able to change these settings as we do in our own machines.
Thus, it is of great importance to check the “compatibility” of our production server BEFORE any real development is done in our own server. This will avoid such horrible situations like: a library that Symfony depends on is missing, some global settings which the app relies on are unchangeable, etc.
Testing the “compatibility” of our production server should really be something we do at the very beginning. There are also some other aspects to be addressed during deployment – such as templates for various error messages, etc.
In the following sections, we’ll be assuming you don’t have full control over your production server. If you do, most of the compatibility issues probably don’t apply, as you should be able to resolve them yourself quite easily.
###An empty Symfony framework on the production server
Please follow the instructions in [my first article on Symfony 2](http://www.sitepoint.com/building-a-web-app-with-symfony-2-bootstrapping/) to set up an empty Symfony framework on the production server.
This is also useful to test if the server has cURL enabled, not only installed on the server but also as a PHP extension, making sure we can grab external resources. In my particular case, this is very important – composer.org is blocked in my country and I need to use a proxy to fetch and install the Symfony Framework.
This empty framework can later be checked into version control.
Valentina is a set of tools including: Valentina DB (a new SQL database server), Valentina Studio (a database management tool), Valentina Report (a GUI to create reports to be used in an application like PHP) and a related development toolkit (called ADK).
In this article, we will take a look at:
- How to use Valentina Studio to manage our MySQL database;
- How to use Valentina Report to create a presentable report.
We will not, however, discuss the the Valentina Database as it is impossible to grasp a new database server and cover its underlying mechanisms in such a short article.
Valentina Studio, the database management tool, has two versions. One is free and can be downloaded here. Another is the Pro version, with more features, priced at $200 per unit. Both versions support Windows, Mac and Linux platforms, making it a cross-platform tool.
In this article, I will use Valentina Studio Pro. Thanks to Valentina for providing me with a key for my installation and evaluation.
The startup speed of Valentina Studio is fast, faster than another tool that I am using. Its main interface has 3 panes:
Fig. 1 The welcoming window
- Servers: Provides CS based database management. It supports four types of “servers”: MySQL, PostgreSQL, Valentina and ODBC. It supports both local server and remote server connections. In my case, we can see there are two remote MySQL connections and one local connection. A red dot before the connection (or “Bookmark” in Valentina’s term) means the server is currently down. A green dot means it is up and running.
- Database: Supports files based database management. Currently it supports Valentina DB and SQLite.
- Projects: This is mainly used in report generation. A “report” generated by Valentina can reside locally and remotely. But it must have Valentina Report Server support (bundled with Valentina Server) to be called from an application. The report project manages the source, query and design of a report. We will cover this later.
After selecting a server, the databases in that server will be displayed in the following cascading column view:
This is my favorite view in Valentina Studio. In this view, different levels of entities (database, table, fields, links, indexes, etc) are displayed in columns in a cascading style. Selecting a database in column one, we can choose to display tables, links, views in column two; and for tables, view its fields, indexes, etc in column three. And the final level of details will be displayed in the right most pane. We can also create and modify an entity accordingly.
Another view, less used in my case, is the tree view:
When a table is selected, it displays the table data in a grid view; when a field is selected, only the column data is displayed. In the grid, we can right click on a record to export that record into CSV or SQL.
PHP-CPP Part 2: The OO side
In this part, we further elaborate its OO features. We will mimic a complex number (in the form of
3+4i) class to demonstrate some more useful and powerful sides of the PHP-CPP library.
This tutorial will get the reader up and running with PHP extension development in C++ via the PHP-CPP library. Taylor Ren covers some very basic introductory aspects, preparing the grounds for the followup articles about real world use cases.
In functional testing, we don’t look at the “correctness” of a single function, which should be verified by a Unit Test, but look at the bigger picture. The question answered by Functional Testing is: Is our app performing well in the sense that it displays the right content, corresponds to a user’s interaction, etc? This tutorial will focus on Functional Testing in our pre-built Symfony app.
Back when I first started to learn Symfony (1.x) with its Jobeet project, I thought the ability to load a bunch of test data into the database very useful.
In this article, we will revisit this feature, which has been completely re-modeled and thus has a lot to teach us.
In this article, we will have two 3rd party libraries to further enhance the power of Symfony.
The first is the
DoctrineFixturesBundle, used to load test data with Doctrine ORM, which is the default ORM in Symfony.
Please follow the instructions in Symfony official documentation to set up and configure the DoctrineFixturesBundle. If you are familiar with Composer, the process should be easy and straightforward, no hassles.
Next, we will install PHPUnit, the default test framework used by Symfony. Its official site offers the download of the latest
phpunit.pharfile. Simply save that file into the Symfony root directory and we are done. Symfony has come with a default and workable PHPUnit configuration file (
app/phpunit.xml.dist). In normal circumstances, we shall keep this file unchanged and PHPUnit will work fine. We’ll use PHPUnit in the followup to this article, so just make sure you have it.
After my previous article on Stored Procedures was published on SitePoint, I received quite a number of comments. One of them suggested further elaboration on CURSOR, an important feature in Stored Procedures. As cursors are a part of a Stored Procedure, we will elaborate a bit more on SP in this article as well. In […]
Mathematical questions and applications always trigger me. Recently I just finished a book by Stephen Hawking “God Created The Integers” and being able to “talk” to those great mathematicians in history thrills me. This is the main reason I decided to write about this topic. In this article, we will review the PHP capability to […]
This entry is part 2 of 2 in the series Integrating Polymer/Dart and SymfonyIn the previous article, we implemented a Dart widget in our Symfony app. Let's handle the rest now. This might get advanced, so grab a cup of coffee and pay close attention – I recommend you follow along only after completing Part […]