HomeMySQL Page 2 - Data Management Made Easy Using Nennius: Advanced Data Handling
Advanced Application Configuration - MySQL
Welcome to part three of this tutorial introducing application development for the Nennius engine. In this article, we will enhance the News Manager application from part two.
Begin by opening the 'application.defaults.php' file that we created in part two. Currently this file contains only those configuration variables required by Nennius. Our first step in exploring the advanced configuration options available to Nennius developers will be to modify this file. The text below shows the additional variables we will be adding to our configuration. We will take a closer look at each variable later, but for now just add the following text to your 'application.defaults.php' file:
As you can see above, most of the variables we have added to our configuration file are self-explanatory, but let's take a short look at each just to avoid any possible confusion.
Our first variable, 'nennius_branding_logo', specifies the relative path to the Web application's branding image. Branding images should generally be no more than 200 pixels wide and 40 pixels tall. For our example application, we have developed a simple branding image that displays the name of our Web application in graphical format. (Note: if no branding image is provided, the default Nennius logo will be used.)
Next we told Nennius to store file attachments on the file system instead of in our database; we could have just as easily chosen to store files in the database (using 'DB_BLOB'). Depending on the application, it will often make more sense to use one method of storage over the other. If neither method is specified, Nennius will default to storing files on the file system within a '/webapps/application_name/files/' folder.
The 'nennius_default_page' is fairly straightforward. If our application contains more than one component, we are able to specify the default component for users who are logging in. Upon a successful login, Nennius will re-direct the user to the component page specified here.
Our last two variables deal with logging information. Nennius offers a variety of logging options. We have chosen the two most common for our application: 'nennius_debug_mode' and 'nennius_logging_mode'. By enabling debug mode and specifying a log file ('nennius_debug_file') we are telling Nennius that any time a SQL query fails it should write that query (and the error message returned) to a log file. This is a very handy feature for Web applications, especially during the initial development stages. Logging mode is similar; it records failed login attempts. It is recommended that logging mode be enabled for any Nennius application managing sensitive data.
Note: When creating the 'application.defaults.php' file, make certain that there is no trailing space before or after the PHP brackets. This is a fairly common oversight to make, but it will prevent the authentication class from setting a user's login cookie.