#packfire framework

[packfire-blog]

HTTP RESTful typed-parameter Routing

In any application, we cannot trust the users' input to the application. Many security attacks going on has been a constant reminder for web developers, especially in PHP, to filter any input and harden their application to minimize the risk of a successful attack. Packfire Framework offers you typed-parameter routing to your controller actions. This gives you great advantage as you are able to control the input parameters and routing at the same place in the `routing.yml` file. Even before execution reaches your controller action, you can determine if the data-type of parameters is valid or not. In your routing configuration file **routing.yml**, routing parameters can be the following: - **any**: any input provided - **optional**: ignores validation if this is set and input is null - **int, integer, long**: input provided must be an integer - **real, float, double**: input provided must be a double - **email**: input must be a valid email address format - **alpha**: input must contain alphabets only - **numeric**: input must be numerical (double or integer) - **alnum**: input must be alphanumerical (alphabets and numbers) - **regex/{match}**: input must match regular expression {match} - **param/{key}**: input must match fellow input parameter {key} - **value/{value}**, equals/{value}, equal/{value}: input must match {value} - **min/{value}**: input must be at least {value} - **max/{value}**: input must be at most {value} - **strmin/{value}**: input length must be at least {value} - **strmax/{value}**: input length must be at most {value} For example: # pack/config/routing.yml user.view: rewrite: /users/{id}-{name} method: 'get' actual: 'Users:view' params: id: num name: alnum If the parameters do not match the parameter typing specified, the route entry will not match. So given a 'GET /users/alpha-ru!n' request will not match the example route above and will cause a HTTP 404 Not Found. > By the way, the ordering of the parameters in the `params` entry does not need to match the order of your controller action. Packfire Framework automatically detects your method parameters list for the data to be passed into your controller action correctly. Voilà! Validation and filtering made simple for you and you can just concentrate on the business / application logic alone. Worry less with Packfire Framework for PHP.

[packfire-blog]

Recall: jQuery-like chaining in PHP's Object Oriented Programming

> I wrote this article 3 years back on http://thephpcode.blogspot.com/ and decided that I will bring up some of the old yet useful blog posts from that blog of mine. -- Sam It's interesting to see how object methods in PHP can be chained just like jQuery's chaining: $("div").children(".firstbtn").hide().fadeIn(); In PHP, it is also possible to chain similarly. In fact, LINQ in Packfire Framework relies on chaining greatly to build the queries flexibily. $source = range(0, 200); // get all odd number and order it by descending $result = Linq::from($source)->where(function($x){ return $x & 1; })->orderByDesc(function($x){ return $x; })->toList(); To do chaining in PHP, simply add a return statement that returns the current object like this: return $this; It is only advisable to perform object chaining for action methods, i.e. methods that logically do not need to return any values.

[packfire-blog]

"Why develop another framework?"

The question of "why do you create another framework?" pops up to me time to time. The typical message that comes after that: > There are already so many well-designed and constructed community-powered standardized updated modular MVC OO blah blah blah frameworks out there on the shelves. Why bother creating another one that's probably not going to work? Well, my primary aim of developing frameworks was to learn. It was in fact through developing frameworks (Samstyle PHP Framework and phpRaise) past five years that I learnt much about software development. > "Why think out of the box when you can completely remove the box away?" -- Anonymous Yes I may be reinventing the wheel but what's the harm of it? Let me tell you what I've learnt over the years that probably may never be taught in classes: - Modal View Controller (MVC) - Templating - ORM - Database Abstraction - phpdocs / in-code documentation - SVN - Git - LINQ - YAML - Continuous Integration - Unit Testing - Gang of Four Design Patterns - and many more which I may have missed out. I strongly believe that through open source projects, a two-way learning opportunity exists between fellow software developers and me. This opportunity didn't come by twenty years back. It was open source that made me understand the difficulties and importance of the entire Software Development Lifecycle (SDLC). So what's so different about Packfire Framework for PHP you asked? Different frameworks target different problems to form solutions, and different users have very different needs. For Packfire, I define it to be: - Low footprint - developer-intuitive - code generation - strict Object Oriented - well encapsulation and cohesion - RESTful - API-oriented In fact, with Packfire Framework, I was able to write code more efficiently and be in control of the code I write. Currently I have several websites and server projects that leverages on the power of Packfire Framework and that I am able to develop quickly and comfortably.

[packfire-blog]

MVC: Where to put my codes?

 Over the past decade of computer science advancements, many successful architectures and design patterns surfaced and has helped many to design great software applications to solve different problem domains. In Packfire, we follow the well known and tested Model-View-Controller (MVC) architecture. MVC enforces Separation of Concerns (SoC) which helps to break down large software application into smaller working Model, View or Controller nodes. New solutions comes with new problems: and that I wouldn't say is a bad thing afterall. People started to debate on where to put my codes in the MVC. Some people go for fat models and slim controllers, while others say logic is handled views and controller serves them. **Fat Models and Slim Controllers** Fat Models means that most of the application code is written in the model classes while the controllers merely call and use the appropriate models based on the request. This method will cause your models to become bloated and ending up with excessive methods and code that you probably won't use later. You may argue that your code will be neater because you have the CRUD and higher level of CRUD methods all within the models. I beg to defer because how can code be neater if almost all your application logic are in the models? **The Packfire MVC Approach** While there are many ways to implement MVC catering to different problems, I insist on one for developers to use with application development in Packfire Framework. Let's recap on the flow of Packfire Framework:  Notice that Model almost play no part in the framework flow in an empty application? That's simply because there is one key idea to the framework: **The controller holds the application logic.** Models do what they named. They are simple classes in the application that you use to model after logical or physical objects that are of concern to the application and business logic. Using these models in your controller, you can manipulate the models to achieve what you want in your controller. _"What about CRUD in the models?"_ I only create what I need to in my controller. Basically I break down my application logic as much as I can into methods / actions of the controllers. This is **divide et impera** ("divide and conquer" in Latin). Using simple-modular controller actions, I can build application logic from these actions. So if I need to insert an object into the database, I will create a controller action for it, and let other controller actions to use it. Reusability - the basics of Object Oriented Programming. [Packfire Framework's starter guide](https://github.com/packfire/books/blob/master/starter-guide.md#guide-mvc) includes the extensive explanation of where codes should go in the MVC architecture.

[packfire-blog]

Detecting client browsers, platforms and operating systems in Packfire

It is of importance to all software developers that we deliver the best experience to the end-users. In the case of the internet, there are so many browser and operating system combinations. Often browser detection JavaScript snippets would appear on the internet, offering developers detection and customization. In Packfire, browser and operating system detection is included in the `pHttpClient` class. The HTTP client is accessible through the `pHttpClientRequest` class, provided by Packfire to the Application when loading. To access the browser and operating system information of your client in your controller: $browser = $this->request()->client()->browserName(); $platform = $this->request()->client()->operatingSystem(); And to detect the type, you can use constants from `pHttpClientBrowser` and `pHttpClientOS`. switch($browser){ case pHttpClientBrowser::CHROME: // chrome break; case pHttpClientBrowser::FIREFOX: // firefox break; } switch($platform){ case pHttpClientOS::ANDROID: // Android phone break; case pHttpClientBrowser::WINDOWS: // Windows break; } You can then set your view according to the platform and browser.