Lucid MVC – Development Update 1

Development Update 1 For Lucid MVC

This is a small update on Lucid MVC. Although I haven’t started work on the FormHelper or Database classes yet, I have made several improvements, and fleshed out the demo site (which will be included with the release).

A contact form page

A contact form page

Most of the work has been on improving form validation, which has been further simplified and made more flexible;

It didn’t really make sense to have the validators created from within the controller, and due to the way validation worked previously, it had to be done after a call to Model::load();. Validators can now be added anywhere within the Model and at any time, which also allows for ad-hoc validation if you want to add/remove validation at any time during the Model’s life-cycle.

With that in mind, validators can be removed simply by passing in the same parameters that match the validator that was added via Model::addvalidator();.

So, if we wanted to remove email validation, we could, for example, remove it before validating our form within the controller;

This is just a simple example. You might wish to remove validation based on user-submitted data. For example, if the user wanted to skip a part of the form, or if the user only had to fill in at least one of two form inputs, you could check if one input was filled in, then remove the “required” validator from the other.

Helpers

Another area I’ve been working on are the Helper classes, so far we have;

  • AlertsHelper – for rendering Bootstrap alert messages
  • SessionHelper – various methods for handling sessions
  • UrlHelper – various methods for generating links (absolute, relative, etc..)

As well as the FormHelper class, I’ll also be creating a DebugHelper for logging output to file/screen.

Configurations

The final area I’ve been working on has been the configuration settings within the project, and how best to represent them. Two of the more common approaches are arrays and .ini files, however both would require additional coding to require them automatically where needed, or additional code to call them.

In the end I decided to use a static class representation;

This made the most sense, given that Lucid MVC requires in classes automatically. Configuration settings can be included anywhere within your project, just by accessing the static class property. For example;

You can of course create your own configuration classes if you wish. The private class constructor is just there to prevent the class from being instantiated.

Other ideas

I’m also considering adding in some of the following;

  • Events/Listeners – Add events to Models/Views/Controllers at certain execution points
  • Dynamic Models – the ability to create new model attributes dynamically outside of the class
  • Modifiers that can change/convert data before/after it’s loaded into the model using callables.

Lucid MVC – A light PHP framework for small online projects

Building an MVC framework from the ground-up

Having worked with several PHP MVC frameworks now (Laraval, Nova Framework, Yii2, Joomla), I thought it would be a rewarding challenge to develop my own framework, based on what I liked about these frameworks, and what benefits me as someone who works with PHP frameworks.

The main goals of this project are;

  • Light MVC framework that’s fast to learn
  • Easy to work with, with minimal boiler-plate code
  • Fast form-building
  • Easy form validation
  • Automated URL routing
An early screenshot of the Lucid MVC Framework

An early screenshot of the Lucid MVC Framework

With that in mind, I’ve been working on Lucid MVC; a light PHP Model-View-Controller framework designed for small projects, but with enough features and functionality to avoid repetition and too much boiler-plate code. For example, there is no manual URL routing to speak of, so URLs are automatically translated to direct to the correct controller, passing any additional parameters to the controller if the controller method accepts them.

For example, the URL:

library/books/author/richard-dawkins

Would instantiate the libraryController, run the books method, and pass in the parameters “author” and “richard-dawkins”. The route will only be successful if the controller method can be called successfully, otherwise, the user will be redirected to the ErrorController, telling them the URL they have reached is invalid (our standard 404 “page not found” page). If the controller allows for optional parameters, then they can be omitted from the URL, and the default parameters will be used. This allows for flexible controller paths, leaving it up to the developer to handle any further validation if they require it.

Like Yii2, a layout template can be applied to the entire view, rendering the view content inside it. Different layouts can be applied in the controller before a view is rendered, or the default layout can be used.

Views themselves are fairly straight-forward. Model attributes, variables or other values are passed to the view via the controller, and can be accessed like normal variables.

Contact Form Controller

This is the controller for the contact form page at the beginning of this post. So far, models can load POST data (assigning it to the model attributes), store data, and perform data validation through a growing-list of validation filters.

Controllers can render views, and redirect to different routes. Controllers also have some basic functionality for dealing with web requests such as checking for POST data.

 

Automated PHP file-inclusion

Because this is designed to be an MVC framework for small projects, the framework uses a custom autoload function to automatically include any PHP files when you call a new Class. So, rather than using Namespaces, every PHP file will be included automatically at the moment it is needed. For large-scale projects this might cause problems with naming conflicts, but for a library that’s designed to be quick to use and build with, it’s perfectly serviceable.

What’s next

The next two features that need to be implemented are the Database class, and the first of the Helper classes to aid in quick form-building. The Database class will be a wrapper class for PHP’s PDO extension, providing easy-to-use methods for standard database CRUD operations, and will handle variable binding automatically for the highest security and less coding.

The FormHelper class will aid in building HTML forms programmatically, automatically handling the form action, various input types and options, and binding the model attributes to the form.

Once the FormHelper and Database class are complete, I think the project will be complete enough to release on GitHub for anyone who wishes to use it.