Development Information

October 3, 2010

Database Class 2.2.8 → 2.2.9

Filed under: Updates — judda @ 1:11 pm

Made the class valid with PHP Strict.

There used to be a binding issue when binding integers would throw a Strict error, this issue has been resolved.

September 5, 2010

MiniMVC v1.0.0 → v1.0.1 and Form Builder v1.0.0 → v1.0.1

Filed under: Mini MVC Information,Updates — judda @ 10:22 pm

Through use further use of MiniMVC and the Form Builder, I have noticed there were a few bugs in them.

MiniMVC the error handling wasn’t working correctly, so it has been fixed.

Form Builder was missing functions for setting CSS classes for the labels, so these (addLabelCSSClass, getLabelCSSClass) have been added in. These take the same parameters as the functions which are similar for the fields (addCSSClass, getCSSClass).

These updates are encouraged as they help to support the core functionality of the application.

August 22, 2010

Mini MVC – How to Use – The Base Controller

Filed under: Mini MVC Information,Tutorials — judda @ 1:33 pm

Sorry for the horribly long delay but here is a quick run down on how to extend the BaseController to write your personal controllers.

As mentioned before, the controller acts as the liaison between the model and the view. These are the classes which get looked for and called whenever your site is visited. For example, if your site is http://www.site.com and the URL is http://www.site.com/about, then Mini MVC will automatically look for the controller named ‘AboutController’ in the ‘./app/controllers/’ directory. The class name for each controller should have the name ‘Controller’ at the end, in order to prevent any namespace collisions between the controllers and the models. It also allows you to quickly and easily determine the difference between the two.

For each controller, you can have as many methods as you would like. These methods are also accessible through the web depending on the URL. For example, http://www.site.com/about/contact would call the ‘contact’ function within the ‘about’ controller. If no function name is provided in the URL, then the default function which is called will be used. This is defined in the configuration file (./app/config/config.php) as the __DEFAULTFUNCTION__. The default function which is called in ‘index’.

Please Note: if you don’t want a function to be web-accessible, prefix it with __ and it will be automatically ignored.

When making your own controller, you should always extend the base class (BaseController) because it provides a bit of additional functionality which is not available if you only make it extend the base class. For example, when you are using a model in your controller, you can then use

$this -> __loadModel ( 'ModelName' );

to load the model into memory and then access it directory through the instance of the controller (i.e. $this -> ModelName).

A sample controller will look like this:

<?php
class SampleController extends BaseController // Accessible by the web through http://www.site.com/sample
{
    public function __construct ()
    {
        parent::__construct (); // Always call the parent's constructor to initialize all information
    }
 
    public function index () // Will be called if no function name is provided (i.e. http://www.site.com/sample)
    {
         // In here you will do any of your data manipulation or generation
         // and tell it what views and models to use
         Base::__loadViews ( array (
                 // Define the 3 parts of the view (header, body and footer) - these definitions are not necessary but they are useful
                 Base::VIEW_HEADER => array ( 'header.php' /* The view name(s) to use for the header */ ),
                 Base::VIEW_BODY => array ( 'body.php' /* The view name(s) to use for the body */ ),
                 Base::VIEW_FOOTER => array ( 'footer.php' /* The view name(s) to use for the footer */ )
             ),
                 // Any variables to send in
                 array (
                     // Please Note: All variables MUST have a name associated with them.
                     'key' => 'value', // Variables to be accessible to all views (accessible through $key in the view)
                     Base::VIEW_HEADER => array ( 'Title' => 'Welcome' ) // Variables only accessible to the header view (can be done for the body and footers as well)
             )
         );
    }
 
    // The $username variable will be filled in with the value associated with information after the function name
    public function other ( $username ) // Will be called if no function name is provided (i.e. http://www.site.com/sample/other/judda)
    {
         // i.e. http://www.site.com/sample/other/judda => $username = 'judda'
         // In here you will do any of your data manipulation or generation
         // and tell it what views and models to use
         Base::__loadViews ( array (
                 // Define the 3 parts of the view (header, body and footer) - these definitions are not necessary but they are useful
                 Base::VIEW_HEADER => array ( 'header.php' /* The view name(s) to use for the header */ ),
                 Base::VIEW_BODY => array ( 'body.php' /* The view name(s) to use for the body */ ),
                 Base::VIEW_FOOTER => array ( 'footer.php' /* The view name(s) to use for the footer */ )
             ),
                 // Any variables to send in
                 array (
                     // Please Note: All variables MUST have a name associated with them.
                     'key' => 'value', // Variables to be accessible to all views (accessible through $key in the view)
                     Base::VIEW_HEADER => array ( 'Title' => 'Welcome',
                         'name' => $username ) // Variables only accessible to the header view (can be done for the body and footers as well)
             )
         );
    }
}

That is all I can think about for this topic, please feel free to ask any questions about it so I can expand on this tutorial. :)

Form Builder (Mini MVC)

Filed under: Mini MVC Information,Updates — judda @ 1:12 am

I have completed a preliminary version of a form builder. It will allow you to programmatically build forms which can be send in from the controllers to your views so that you never have to worry about different views handling the information in different ways (or changing names or anything).

I will be posting links to the documentation soon so that all of the built-in features will be displayed. Just because you are doing things programmatically doesn’t mean you can’t stylize nor have valid HTML. You can add as many attributes to the input types as you want (including specialized ones for adding CSS classes and styles).

Please Note: In this version of the form builder, arrays of fields are not permitted (i.e. they will overwrite each other). I am actively working to remove this limitation as soon as possible.

Along with the form builder, I have uploaded a small update to the Mini MVC base engine (just a little clean up thing).

July 13, 2010

Layout Manager Plugin (Mini MVC) 1.0.0 → 1.0.1

Filed under: Mini MVC Information,Updates — judda @ 12:54 am

Tiny update. Now the body can be pushed through the layout folder as well.

If you know that a file will never exist in the layouts folder, you can include LayoutManager::BYPASS => true in the array passed into each of the arrays for the __loadViews function and it will skip the extra searches.

July 5, 2010

Tiny Re-arrangement – Mini MVC

Filed under: Mini MVC Information,Updates — judda @ 10:20 pm

While implementing a new plugin, I realized that the original folder situation for the app/config/ folder would get awful messy fairly quickly. I have done a quick update just to rearrange the folder hierarchy to clean it up a little more.

Sorry for the inconvenience.

July 1, 2010

Mini MVC – How to use – The Configuration File

Filed under: Mini MVC Information,Tutorials — judda @ 11:07 pm

Here I am going to give a quick run down about the the Mini MVC project that I have been working on recently and how to use it.

First, let’s start off with the configuration. As I said in my previous post, it will work right out of the box with no modifications needed. However, sometimes things aren’t always how you want them. In these cases it’s good to know what can easily be changed and what cannot.

In the file: ./app/config/config.php

This is the configuration file which comes with the system by default.

Within this section of the configuration file, there is only one thing that you may need to modify. That is the __SHOWINDEX__ defined value. __SHOWINDEX__ will define whether or not the ‘index.php’ will show up in links which are created using the __INDEXPATH__ defined value. If set to TRUE, then it will be added to the link, otherwise it will not be. This is especially useful if mod_rewrite is not enabled on your server. This will just force the application to send everything through the main page instead of masking the use of the ‘index.php’ page.

/* Break up the current path to contain all information */
$split = preg_split ( '/\//', $_SERVER [ 'SCRIPT_NAME' ], -1, PREG_SPLIT_NO_EMPTY );
 
/* Allow the user of the script to decide if the index should be included in urls */
define ( '__SHOWINDEX__', false );
 
/* Define the base path for the script */
define ( '__BASEPATH__', '/' . $split [ 0 ] . '/' );
 
/* Define the index path for the script depending on previous settings */
define ( '__INDEXPATH__', __BASEPATH__ . ( __SHOWINDEX__ ? 'index.php' : NULL ) );

This following section should not be modified just for ease of use:

/* Define where the system libraries are stored */
define ( '__SYSTEM__', __FULLPATH__ . 'system/' );
define ( '__SYSTEMLIBS__', __SYSTEM__ . 'libraries/' );
define ( '__SYSTEMHELPERS__', __SYSTEM__ . 'helpers/' );
 
/* Define the application path */
define ( '__APPPATH__', __FULLPATH__ . 'app/' );
 
/* Define where the user libraries are stored */
define ( '__USERLIBS__', __APPPATH__ . 'libraries/' );
define ( '__USERHELPERS__', __APPPATH__ . 'helpers/' );
 
/* Define the configuration */
define ( '__CONFIG__', __APPPATH__ . 'config/' );

This spot basically defines everything about where stuff within the application is actually stored. For example, we can see the creation of the links to the system helpers and system libraries paths. If any of these values are changed, the corresponding changes should be made in the ./system/ folders.

Next we move onto the definition of the location of the model, view and controllers directories as well as the configuration directory in case there are any other things which require it.

/* Define the configuration */
define ( '__CONFIG__', __APPPATH__ . 'config/' );
 
/* Define the model / view / controller directories */
define ( '__MODELS__', __APPPATH__ . 'models/' );
define ( '__VIEWS__', __APPPATH__ . 'views/' );
define ( '__CONTROLLERS__', __APPPATH__ . 'controllers/' );

The next key part is the following:

/* Define whether to enable error message logging or not, and where to store the log */
define ( '__LOGERRORS__', true );
define ( '__ERRORLOG__', 'error_log' );
define ( '__DISPLAYERRORS__', true );

This defines the actions which happen when an error occurs. These errors are not the errors which are send by PHP, but ones generated by the Mini MVC script when trying to complete any of your tasks.

The first two definitions: __LOGERRORS__ and __ERRORLOG__ work hand in hand. If __LOGERRORS__ is set to true, then all of the errors which occur will automatically be appended to the file defined in __ERRORLOG__.

The __DISPLAYERRORS__ definition is currently set to true however, this should only be used in development because it displays all of the error messages on the screen after all of the other scripts have been run (after your controller has been called). This will make it so you reveal a bit to much information to the user as well as invalidates any HTML which has been emitted (it emits more HTML after the </html> tag which is not allowed.

The next section:

/* Define the default class and method */
define ( '__DEFAULTCLASS__', 'main' );
define ( '__DEFAULTFUNCTION__', 'index' );

Just defines what the application should be doing if it hasn’t been provided any information about what controller nor the function to use.

In summary:

Constant Result
__SHOWINDEX__ If true, the urls generated through using __INDEXPATH__ will contain ‘index.php’ in them. For example, http://www.yoursite.com/model/controller becomes http://www.yoursite.com/index.php/model/controller
__ERRORLANGUAGE__ Allows you to change the language which the error messages are logged in (currently only English exists)
__LOGERRORS__ If true, whenever Mini MVC detects generates an error, it will append it to the specified data file (__ERRORLOG__)
__DISPLAYERRORS__ If true, all of the error messages generated from Mini MVC will be emitted at the bottom of the page.

Hope this helps to make the configuration file a little more clear. Next step, making controllers.

Mini MVC

Filed under: Mini MVC Information — judda @ 10:29 pm

As previously mentioned, I have finished making a Model View Controller design pattern enforcer for PHP.

Firstly, I must start you off with a video.

Yes, the guy can’t sing … but he does a great overview of MVC.

So what is MVC and how will it help you? Based on the way it is structured, it pushes you in the right direction to creating highly maintainable code. Your code is separated into three main components: models, views and controllers.

  • Models – The part of the application where all of the actual data processing should occur
  • Views – The part of the website which is eventually emitted to the viewer
  • Controllers – Acts as a liasion between the models and the views. This layer will pass any information required to the models back to it in a manner which is required by the model as well as tell the application what should be emitted for the front end (the views to display)

Diagrammatically:
Model View Controller

Image From: http://www.bhartisoftland.com/technologies-skill-sets/gifs/mvc-php.png

Why use this version of MVC over some of the more renown ones?
Easy … because it is extremely light and doesn’t require tons of additional files to run correctly and it works right out of the box. It is also fully documented and all of the documentation has been compiled and placed online at your finger tips just waiting for you to look through it.

How about fancy plugins and stuff?
There is already one out (a layout manager) and more are in progress.

So what do you get when you download the zipped Mini MVC file?

  • The implementation of MVC
  • Built-in use of my database class (see previous posts about it for more information)
  • Sample controllers and views

Why not take the plunge and try it today?

I’ll be posting examples of how to use it shortly.

For more information about MVC, check out the Wikipedia article on it.

Please feel free to contact me if you have any question / comments / concerns / bugs that you find.

Mini MVC

Filed under: Site Update — judda @ 1:57 pm

I have added my most recent project on here. It is called ‘Mini MVC’. Basically this is a very small script which enforces Model View Controller on it’s users.

What is Model View Controller? It is a design pattern which is used in order to keep all 3 major parts of your code separate. In doing this, it will help you to create higher quality code.

I am in the midst of uploading all of the documentation for the classes which are required as well as writing up some brief tutorials on how to use it.

Hope this comes in handy :)

April 23, 2010

Database Class – Like

Filed under: Database Class Information,Tutorials — judda @ 1:13 pm

It has come to my attention that a few people have been stumbling upon how to use the ‘LIKE’ command with wildcards using this database class. ┬áBecause of this, I will provide a brief sample of how to use it.

Normally when someone writes a query which uses ‘LIKE’, it is written as follows:

$query = "SELECT `email` FROM `users` WHERE `username` LIKE '%Tom%'";
 
$res = $db -> query ( $query );

However, because of how this database class currently works, this will cause issues (it looks for the percent sign (%) and then tries to find a parameter type to bind to it).  So instead of doing it this way, you must do the following:

$query = "SELECT `email` FROM `users` WHERE `username` LIKE %s";
 
$res = $db -> query ( $query, '%Tom%' );

This will bind the wildcards along with the actual value into the query and end up doing exactly what you need it to do.

Sorry for the inconvenience.

« Newer PostsOlder Posts »

Powered by WordPress