Looking to re-use an existing component library if its simple and fast enough then we can cherry-pick from it.

Usually PPI doesn't need all the fancy features from configuration that zf/symfony ship with. In the past this has lead PPI to create a similar but very trimmed down and faster version.

This is no longer a project goal for PPI to make its own components completely so re-using existing code is important.

The wiki for this part of the system is here: https://github.com/ppi/framework/wiki/PPI-v2-Configuration

** Please read the wiki document before commenting on this discussion

We need a logging class. Does it deserve to be its own component ?

My initial use case for this internally is to throw a deprecated notice for functionality that we want to phase out gradually.

More thoughts required here

@BenTheDesigner you built the exception component.. any thoughts here?

I've gone and done the hard work for you:

https://github.com/bobthecow/mustache.php

https://github.com/bobthecow/BobthecowMustacheBundle

If you don't beat me to it, I'll plug it in and send a pull request. But I'm super busy these days, so no promises :)

Current status

User config comes from app.config.php

Currently we load configuration from app/app.config.php:

<?php
$config = array(
    'environment'            => 'development',
    'templating.engines'     => array('php', 'smarty', 'twig'),
    'templating.globals'     => array(
        'ga_tracking' => 'UA-XXXXX-X'),
    'datasource.connections' => include (__DIR__ . '/datasource.config.php')
);

// Are we in debug mode ?
if ($config['environment'] !== 'development') {
    $config['debug']     = $config['environment'] === 'development';
    $config['cache_dir'] = __DIR__ . '/cache';
}
return $config; // Very important

Setting App properties is how we do this

we let the user set App properties using magic setters after the PPI\App instance is created:

$app = new PPI\App();
$app->moduleConfig = include 'app/modules.config.php';
$app->config = include 'app/app.config.php';

// Do you want twig engine enabled?
//$app->templatingEngine = 'twig';

// If you are using the DataSource component, enable this
$app->useDataSource = true;

Everything is stored in AppOptions (aka ParameterBag)

app and module configuration is store in App::$options['config'] and App::$options['moduleConfig'] respectively being $options an instance of PPI\ServiceManager\Options\AppOptions which is based on Symfony ParameterBag.

Some ParameterBag characteristics:

• Allows the usage of placeholders (example: %app.cache_dir%) which are later resolved.
• All keys are lowercased ('moduleConfig' becomes 'moduleconfig').
• It is not designed to store n-levels of config keys. One-level only.

App internal configuration is also stored in AppOptions

This means parameters that identify which class to use for a given component is stored alongside user configuration.

    'app.session.class'                  => 'Symfony\Component\HttpFoundation\Session\Session',
    'app.session.storage.class'      => 'Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage',

Where to go now?

• Should we store everything in the same AppOptions instance?
• Should we allow users to set a App property like we do now or centralize all user configuration?
• Can we work with a single-level (array deepness) implementation like ParameterBag. This class resolves placeholders automatically but only for root-level keys.

One of the key points about PPI is to alleviate vendor-lockin. This means your PPI module can be using ZF2 routing, SF2 routing or li3 routing (to name a few).

As demonstrated in this example, $module->getRoutes() will always return a symfony2 RouteCollection: https://github.com/ppi/skeletonapp/blob/master/modules/Application/Module.php#L18

This is great as an initially working implementation, but the idea is to let the developer on a per-module basis choose which routing he/she wants.

I'm keen to hear people's ideas/patterns on making an extensible matching system that will do, "oh this module is using symfony, lets ask symfony to match it", which is what it currently does. It must detect a Zend2 route collection and ask ZF2 to match it.. and so on.

I am doing a quick review about the state of PHP caching libraries in order to build/integrate a cache component in PPI 2.1.

@dragoonis has been moderating the PSR Cache Proposal for a while and should have a good background on this matter. The FIG has not yet reached a consensus about how the cache interface should look like.

Following our approach of picking the best tool for the job I don't want to implement a Cache component and rather use a solid PHP library that already provides this functionality.

After reading:

• https://github.com/dragoonis/fig-standards/blob/master/proposed/psr-cache.md
• https://github.com/symfony/symfony/pull/3211
• https://github.com/symfony/symfony/pull/5902
• https://groups.google.com/forum/#!topic/symfony-devs/EJr6XhawJTE
• ...

I've reached the conclusion the following are the most relevant PHP Cache libraries to build our component upon:

• Stash and StashBundle
• ZendCache
• DoctrineCache
• SonataCacheBundle

What are your preferences? What libraries are missing from this list? Should we wait until FIG agrees on the Cache proposal?

This will allow closures against routes.

You will still be able to talk to all standard components, use all functionality you'd expect from a controller, but no more routing since you specify it in your microapp call.

Think of how to still access the service locator here, perhaps $app is still available and you can do $app->getService('UserStorage').

@noisebleed is interested in making a PPI Module for registering the SmartyEngine

I have currently developed the code necessary for SmartyEngine. Futher development on this is required such as Extensions, Filters and Plugins for Smarty3 and I believe this is where @noisebleed comes in.

Modules can create 'services' which are globally shared using the ServiceLocator.

The default templating service is here: https://github.com/ppi/framework/blob/2.0/PPI/App.php#L198

The modules can create their own service in their /modules/<module>/Module.php class on the initServices method. An example of this is here: https://github.com/ppi/skeletonapp/blob/2.0/modules/User/Module.php#L38

Now any controller can perform $this->getService('mailerClass') if they wanted to.

The SmartyEngine Module in question should register a 'templating' service key in its initServices method, holding an instance of PPI\Templating\Smarty\SmartyEngine.php

An example of setting up SmartyEngine is here: https://github.com/ppi/framework/blob/2.0/PPI/App.php#L276 The code is also below for easy reference, the class names are 'use' statements at the top of PPI\App:

<?php
defined('SMARTY_DIR') || define('SMARTY_DIR', PPI_VENDOR_PATH . 'Smarty/');
$smartyDriver = new \PPI\Templating\Smarty\Smarty();
$engine = new SmartyEngine(
    $smartyDriver,
    new TemplateNameParser(),
    new FileSystemLoader($templateLocator)
);

Big topic, going to be calling them 'Extensions' instead of Plugins/Modules..etc

Trying to keep consistency with PHP project, since our names are similar.

PHP Extension PPI Extension <-- consistency

PPI's approach is to embrace, not replace so who's got the most effective but fast plugin system.

How is SF2's ? (sfEvent)

How is ZF2's ? (also, stability?)

Who else has a good one?

@seldaek are you good to elaborate on symfony here? @bittarman, @juozas being zf guys, are you yet aquiainted with v2?

Currently in PPI there is a PPI\View component.

1. It supports specifying a 'layout file'.
2. Then you have an 'action file' which is specified by your controller's action.
3. You can pass parameters into your template process from the controller.
4. You can pass options to the rendering process to tell it wether this is a 'parital' load, to just load the action file, or load the entire template as normal.
5. It has multiple "Template Adapters" which consist of PHP, Smarty, Twig.

I would much prefer to re-use an existing libraries implementation of the above, have something to connect my controller to.

I looked at ZF2's View implementation, it looked a bit crazy and over-complicated, but maybe theres parts we can cherry pick ? What about symfony?

We need to be able to manage our vendor libraries in different versions, so that Composer can tie things up nicely.

@elazar would you like to recap on what you discussed with me earlier? just detailing the high level steps required so we can get a discussion going, with say @seldaek ?

• Paul.

When you request new technologies that aren't included, currently you're asked to manually run "compose require" commands.

The suggested change, by @BenExile, is to inform the user that composer changes are going to be made and if they want PPI to run them for you, or you do it yourself.

cd $appRoot && composer require <package>

https://github.com/ppi/framework/blob/master/src/Module/AbstractModule.php#L322

and

https://github.com/ppi/framework/blob/master/src/App.php#L293

To test this Need to test this from SkeletonApp, by accepting a RequestInterface, ResponseInterface and then setting the body content of that PSR-7 object and then returning $response back from the controller action.

From http://framework.zend.com/manual/2.0/en/modules/zend.service-manager.quick-start.html#modules-as-service-providers

Module Returning an Array

The following demonstrates returning an array of configuration from a module class. It can be substantively the same as the array configuration from the previous example.

namespace SomeModule;

class Module
{
    public function getServiceConfig()
    {
        return array(
            'abstract_factories' => array(),
            'aliases' => array(),
            'factories' => array(),
            'invokables' => array(),
            'services' => array(),
            'shared' => array(),
        );
    }
}

Returning a Configuration instance

First, let’s create a class that holds configuration.

namespace SomeModule\Service;

use SomeModule\Authentication;
use SomeModule\Form;
use Zend\ServiceManager\Config;
use Zend\ServiceManager\ServiceManager;

class ServiceConfiguration extends Config
{
    /**
     * This is hard-coded for brevity.
     */
    public function configureServiceManager(ServiceManager $serviceManager)
    {
        $serviceManager->setFactory('User', 'SomeModule\Service\UserFactory');
        $serviceManager->setFactory('UserForm', function ($serviceManager) {
            $form = new Form\User();

            // Retrieve a dependency from the service manager and inject it!
            $form->setInputFilter($serviceManager->get('UserInputFilter'));
            return $form;
        });
        $serviceManager->setInvokableClass('UserInputFilter', 'SomeModule\InputFilter\User');
        $serviceManager->setService('Auth', new Authentication\AuthenticationService());
        $serviceManager->setAlias('SomeModule\Model\User', 'User');
        $serviceManager->setAlias('AdminUser', 'User');
        $serviceManager->setAlias('SuperUser', 'AdminUser');
        $serviceManager->setShared('UserForm', false);
    }
}

Now, we’ll consume it from our Module.

namespace SomeModule;

// We could implement Zend\ModuleManager\Feature\ServiceProviderInterface.
// However, the module manager will still find the method without doing so.
class Module
{
    public function getServiceConfig()
    {
        return new Service\ServiceConfiguration();
        // OR:
        // return 'SomeModule\Service\ServiceConfiguration';
    }
}

End of citation.

We need to support all of these alternatives.