PHPackages                             phy/phyneapple - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Framework](/categories/framework)
4. /
5. phy/phyneapple

ActiveFramework[Framework](/categories/framework)

phy/phyneapple
==============

A lightish weight PHP5.4 framework. You have no reason to use it, I just got bored so here it is. Plus it helps for quickly rolling out smaller to medium sized sites.

0.4.1-alpha(11y ago)27The Open Software License v3.0PHPPHP >=5.4.0

Since Aug 26Pushed 11y ago1 watchersCompare

[ Source](https://github.com/mullanaphy/phyneapple)[ Packagist](https://packagist.org/packages/phy/phyneapple)[ Docs](https://github.com/mullanaphy/phyneapple)[ RSS](/packages/phy-phyneapple/feed)WikiDiscussions master Synced 2d ago

READMEChangelogDependencies (2)Versions (8)Used By (0)

Phyneapple - an experimental framework for PHP 5.4+
===================================================

[](#phyneapple---an-experimental-framework-for-php-54)

Phyneapple is a smaller framework I built for side projects to use as an alternative to [Symfony2](https://www.symfony2.org/). It doesn't compete with Symfony2 or any other framework for the most part since it doesn't even have simple routing patterns...

Install
-------

[](#install)

To install, run this up. And then add all your code into src.

```
composer create-project phy/phyneapple
```

Routing
-------

[](#routing)

To keep it basic, routing works by mapping /:controller/:method to a \\PHY\\Controller{:controller}::{:method}\_{:request\_method}(). For example doing a POST /user/login would load \\PHY\\Controller\\User and then attempt to call the method login\_post(), if that doesn't exist it falls back to login\_get(), then index\_post(), and then finally index\_get(). That's how routing works on face value.

Controllers
-----------

[](#controllers)

Controllers and routes are rolled into one, on top of that, routers have access to the page's building blocks via \\PHY\\View\\Layout, the page's request \\PHY\\Request, and returns a \\PHY\\Response.

Views
-----

[](#views)

Views are influenced by Magento's blocks. However Magento uses XML and it's very clunky. Which is with a good reason since it's highly customizable and once your familiar with it, it's pretty sweet. Still, for smaller projects no XML and a simpler structure was needed. So views are broken into blocks and are put together using JSON config files.

Everything starts in design/default/www/config/default.json which has a main "layout" class and all other blocks are children of "layout" or its descending children and so forth. Configs can then overwrite any block from design/default/www/config/default.json and there is some black magic to load these config files if they exist, using the same routing method, our previous /user/login will look for design/default/www/config/user/login.json and then design/default/www/config/user/login.json unless you overwrite the config inside of your action method.

Now, as for blocks themselves, they're just .phtml files which has variables passed to them as basic variables. Also has access to $this, which correlates to \\PHY\\View\\AView and whatever type of View is extending that.

Quick example of how the .phtml file works.

```
/*
 * in \PHY\Controller\Index::index_get()
 */
$this->getLayout()->getBlock('message', [
    'someVariable' => 'banana!'
]);

/*
 * in design/default/www/block/
 */
I passed variable "someVariable":

Here's a url builder: