Skip to content

PPI SmartyEngine Plugin #27

Closed
dragoonis opened this Issue Apr 3, 2012 · 9 comments

2 participants

@dragoonis
PPI Framework member

@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)
);
@noisebleed
PPI Framework member

Hi. Just forked ppi/framework and started to look around.

Is it expected to support several template engines at the same time like in Symfony2? If not, methods like EngineInterface::supports() could be dropped.

The module concept is already stabilized? Is there any documentation yet?

offtopic: Do you really want to stick to tabs as stated in Coding Standards? Neither Symfony2, PEAR or ZendFramework allow them. I would suggest 4 spaces instead.

@dragoonis
PPI Framework member

Right now, I don't plan for multiple templating engines at the same time. If you can figure out a nice clean way to do this, then I welcome that idea. It will be useful for the template syntax Module:Controller:viewfile.format.engine

supports - I believe it's best to stick with EngineInterface anyway since it gives good consistency between engines.

The module concept is stablised and really just needs some more love on the "service locator" layer once ZF2 finalise their proposal.

PPI2 will be following the PSR1/PSR2 coding standards that is currently in progress, this will mean 4 spaces instead of 1 tab. Don't worry too much about the coding standards as it will be all cleaned up once PSR1 is finished.

@noisebleed
PPI Framework member

It is possible to support multiple templating engines. It's just a matter of including Symfony DelegatingEngine to pick up the right engine for a given template format. I may send a PR to include that, if that's the direction you want to go (more flexibility but more code too).

Also, PHP, Twig and Smarty are hardcoded in App.php. Is this testing/temporary code or is it just like you want it to be?

Are modules equivalent to Symfony2 bundles? Is there a draft defining the module layout and properties?

Symfony has a nice check_cs script to replace tabs with 4 spaces indentation (and other CS tricks). Give it a try.

@dragoonis
PPI Framework member

@noisebleed

I'd really enjoy doing DelegateEngine even though it is more code, it has great benefits.

However I'd like a way to disable the DelegateEngine functionality and revert back to a single templating engine. This would be a way to achieve enhanced performance.

If my app was only using PHP views, I would personally not want it to load up TwigEngine or SmartyEngine too for me. So how about, by default it's PHP and you have to enable DelegateEngine functionality with a setting on App.php.

<?php
$app->multipleTemplateEngines = true; // Try to think of a shorter name.

Yes, pretty much. Right now there's no formal documentation since all of my effort is tied up in developing PPI2 components. If you look at the User module for now you can get a good feeling for its functionality.

Are modules equivalent to Symfony2 bundles?
Is there a draft defining the module layout and properties?``

Very cool ! The PSR1 standard is coming to a close, I'll definitely be looking to use this. We are also hopefully working on a PSR1_Beautifier to clean up existing code too.

Symfony has a nice check_cs script to replace tabs with 4 spaces indentation (and other CS tricks). Give it a try.

@noisebleed
PPI Framework member

OK then, I'll take a look of what can be done to the templating component. Do you prefer partial PR's or just finished ones?

Something simple as $app->templateEngines = array('php', 'smarty'); should do.

@dragoonis
PPI Framework member

You can make a branch/PR and keep committing to that branch with ammendments until it's finished.

Do you prefer partial PR's or just finished ones?

I like your simple idea. This value can also take a string to make it easy for people.

$app->templatingEngines = 'php'or$app->templatingEngine = array('php', 'twig');`

Looks nice :-)

@dragoonis
PPI Framework member

What about issue #26, is it necessary to have duplicate tickets?

@noisebleed
PPI Framework member

No need, you can merge them.

@dragoonis
PPI Framework member

I have merged your PR @noisebleed and smarty is working with the 2 extensions too!

Closing this issue :)

@dragoonis dragoonis closed this Jul 14, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.