Released RainTPL 3

[Rain]

Released RainTPL 3 and added on Packagist, which means is now installable with Composer

http://www.raintpl.com/News/2013/01/17/RainTPL-3-final-version-online-on-Packagist/

If you guys don't know Composer (yet), here is the link

http://getcomposer.org/doc/00-intro.md

in short composer is a package manager that is changing the way we install and maintain project, thanks to its version/dependency system that allows you to define in a json file (composer.json) which package your application need and what version they have to be. Totally awesome!

As always bug report, feedbacks and comments on the RainTPL are welcome!

Good looks!

[etor...@gmail.com]

What if I want to place Rain out of "library" folder?

Now you've hardcoded "library" inside $abs_path within autoload.php—it's not good.

Ok, I remove "library" so $abs_path = BASE_DIR . $path . ".php"

then I change helloworld.php to require "Rain/autoload.php" and… fatal error..

Warning: require_once(C:\www\domainsRain\Tpl.php) [function.require-once]: failed to open stream: No such file or directory in C:\www\domains\localhost\Rain\autoload.php on line 23

Fatal error: require_once() [function.require]: Failed opening required 'C:\www\domainsRain\Tpl.php' (include_path='.;C:/www/modules/php/PHP-5.3.23/;C:/www/modules/php/PHP-5.3.23/PEAR') in C:\www\domains\localhost\Rain\autoload.php on line 23

[etor...@gmail.com]

What about files and folders convention? It's not that intuitive.

"cache" and "templates" are ok, but core…

There are numerous Rain projects (template engine, framework, cms), so why /library/Rain/? I believe it should be "raintpl".

Let's go inside. autoload.php is ok, but there is file Tpl.php and Tpl folder—too general. I believe it should be "raintpl.php" and "helpers".

And the last one, "Plugin" folder inside "Tpl", why inside, why singular? I believe it should be "plugins" and stay on the same level as "helpers".

In the end:

cache

templates

raintpl

    helpers

    plugins

    autoload.php

    raintpl.php

[Federico Ulfo]

RainTPL 3 implement PSR-0 and is designed to work with Composer, that's why the "weird" folder organization. The best way to install RainTPL is with Composer, you can find the component on packagist.org.

The PHP-Fig is working on the PSR-X an alternative that hopefully will replace PSR-0 to remove all the unnecessary folder nesting.

In any way I'll keep in consideration to redesign the folder organization, as that was designed non-PSR-0 and re-organized as PSR-0, if I could start from scratch now it'd be surely different.

Thanks for your comment!

--
--
www.RainTPL.com
group at http://groups.google.com/group/raintpl
unsuscribe at raintpl+u...@googlegroups.com
 
---
You received this message because you are subscribed to the Google Groups "raintpl" group.
To unsubscribe from this group and stop receiving emails from it, send an email to raintpl+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[etor...@gmail.com]

I don't like having a lot of software to go.

You know, all that "svn.exe" for checkout, "git.exe" for clone, now Composer for whatever-smart-deployment, etc.

Plain urls to transmit via http/ftp/sftp and zip to pack/unpack should be enough.

So I would like to download RainTPL3, unpack it to any folder inside "www", put right path to require_once and enjoy template engine.

Twig works this way, Smarty does too, why Rain is walking on some weird stilts?

Please make proper changes.

[Federico Ulfo]

SVN, is old but still necessary to install some legacy package, git made our developer life better, and Composer is the mainstream in the PHP community, it makes easy to install and use any package and keep the dependency updated and the best part is actually packagist.org where you can find all the component you need, in fact if a component is not on packagist is probably updated.

Composer and PSR, are new standards that are becoming so popular, that soon they will become the standard de facto, both Twig and Smarty recommend it.

You should read http://phptherightway.com and subscribe at http://phpweekly.info and attend at the international conference of PHP (there are a lot in US and Europe). 

--

[etor...@gmail.com]

Hmm, I believe initialization should be simplified.

rain_hello_present.php

<?php

$tpl = "rain_hello";

$vars = array(

"title" => "RainTPL3",

        "name"  => "Luke Skywalker",

"week"  => array("Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday")

);

require "library/Rain/autoload.php";

use Rain\Tpl;

Tpl::registerPlugin(new Tpl\Plugin\PathReplace());

Tpl::configure(array("tpl_dir" => "templates/", "cache_dir" => "cache/", "debug" => "false"));

$rain = new Tpl;

$rain->assign($vars)->draw($tpl);       

?>

rain_hello_future.php

<?php

$tpl = "rain_hello";

$vars = array(

"title" => "RainTPL3",

        "name"  => "Luke Skywalker",

"week"  => array("Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday")

);

require "library/Rain/autoload.php";

Rain::configure(array("tpl_dir" => "templates/", "cache_dir" => "cache/", "debug" => "false"));

Rain::load($tpl, $vars);

?>

I noticed second implementation when met Haanga php template engine.

Anyway my point is how to shortcut with getting ouput: function(templatename,variables).

[etor...@gmail.com]

On Friday, May 10, 2013 6:15:02 PM UTC+4, Rain wrote:

Composer and PSR, are new standards that are becoming so popular, that soon they will become the standard de facto, both Twig and Smarty recommend it. You should read http://phptherightway.com and subscribe at http://phpweekly.info and attend at the international conference of PHP (there are a lot in US and Europe). 

Both Twig and Smarty could recommend being a vegetarian, but they still serve the purpose for the rest, or more simply, they work after being downloaded via classic http and unpacked via classic zip upon any folder hierarchy. Such flexibility makes them popular not only among geeky developers. You know, there are content managers, designers, etc as well, who seek for an easier way to maintain, for example, bilingual personal website with a dozen partly inherited pages. They don't like wordpress-similar CMS, but not ready for MVC frameworks, that's why they choose template engine as the golden mean. And so far RainTPL3 is far better (in terms of readability and speed) than Twig and Smarty, but not that well-brushed out of the box.

[Federico Ulfo]

RainTPL 3 uses the assign() method because it was implemented in RainTPL 2 and we wanted to keep as back compatible as possible, but I agree, that's a nice way to go for the next version.

--

[Federico Ulfo]

I see your point, perhaps you can download Rain and use its autoloader, but I still recommend to use the Composer autoloader. 

Talking about speed, there's always some way to improve the speed, for example using cache or a proxy server, also template engine are fast enough to make the difference unnoticeable, the speed problem lay somewhere else, such as the database, the streams and the bad written code, as for example for( $i=0; $i<count($array);$i++).

Anyway thanks for sharing your opinion!

[etor...@gmail.com]

On Friday, May 10, 2013 6:53:59 PM UTC+4, Rain wrote:

I see your point, perhaps you can download Rain and use its autoloader, but I still recommend to use the Composer autoloader. 

Composer is something user has to install on local/production (windows in my case) and remote/live (unix) machines, right? So It's a new layer of dependency, "one more thing to do before project goes alive". I'd like to keep small-sized projects as portable as possible to update, backup and transfer between various hostings. 

Now I have Rain3 running fine with native autoloader and within /library/Rain/ folder, but it makes me nervous that placing Rain outside that folder breaks the functionality (see detailed report above). Also I'm concerned to have initialization sequence shorter (Rain::load($tpl,$vars) for for new/strict Rain3 users and use Rain\Tpl, $rain=new Tpl, assign&draw for Rain2 compatilibity). 

 

Talking about speed, there's always some way to improve the speed, for example using cache or a proxy server

You're right. I used the wrong word here, not speed, but overall consumption. It does matter when you have limited shared hosting.

By the way, I did a small naive benchmark on local machine, let me share results with you.

Method

enginename_hello.php

<?php

$start = microtime(true);

$start_memory = memory_get_peak_usage();

$tpl = "enginename_hello.tpl";

$vars = array(

"title" => "enginename",

        "name"  => "Luke Skywalker",

"week"  => array("Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday")

);

...init sequence with default settings, passing variables, rendering...

echo (memory_get_peak_usage()-$start_memory)."<br>".(microtime(true)-$start);

?>

enginename_hello.tpl

<!DOCTYPE html>

<html lang="en">

...include command for enginename_hello_header...

<body>

<h2>Variable</h2>

Hi <b>...name...</b>, this is a beautiful day for a Jedi!

<br><br>

<h2>Array</h2>

<ul>

...loop command for $week...

<li>...value...</li>

{/loop}

</ul>

</body>

</html>

enginename_hello_header.tpl

<head>

<title>...title.</title>

        <link rel="stylesheet" href="style.css" type="text/css" />

</head>

Results

1. Compile and show (alphabetical order).

Haanga latest from github

2 348 512
0.0457410812378

Quicky 0.5, fork of Smarty 

1 317 624
0.0209231376648

Rain 3

416 768
0.016636133194

Smarty 3.1

3 940 048
0.0615899562836

Templum 0.4, poor syntax for designers

187 480
0.00483584403992

Twig 1.13.0

3 011 720
0.105006933212

2. Show compiled PHP from cache (simple browser refresh after step #1).

Haanga

212 832
0.00519609451294

Quicky

388 600
0.00479793548584

Rain

416 872
0.0134119987488

Smarty

1 331 088
0.0200409889221

Templum

187 480
0.00328803062439

Twig

1 012 472
0.0197639465332

I'm looking forward to check another modern PHP template engines, but it seems there are not many left.

So what is my conclusuion to date? Hooray for Rain3, no doubt, but we should polish it right away.

[Federico Ulfo]

Composer is a dependency manager, is a great tool if you need to install different packages, it helps a lot to make projects more maintainable, but yes add some overhead in the workflow from development to production, we were considering to use in our company, but we realized that could slow down drastically, because we work with Agile and we use a lot of in-house component.

You can extend RainTPL 3:
class T extends Tpl{

    static function load($template, $vars, $to_string=false){ 

        $tpl = new self;

        $tpl->assign($vars);

        return $tpl->draw($to_string);

    }

}

That's a nice benchmark. If you like benchmark check this out: phpcomparison.net

--

[etor...@gmail.com]

How do you think why Rain3 consumes same amount of memory on both stages?

Other template engines here tends to load with less footprint if page is already compiled.

[Thomas ZILLIOX]

Hi giys!

Just to say, I was afraid of the composer (http://getcomposer.org/) complexity at the beginning.
But you really need to try it!
I like simplicity too, and composer is lot simpler than doing all of it by hand.

You just have to maintain a composer.json file at the root of your project, and it will:

• Manage downloading
• Extracting
• Updating library
• Update autoload
• Validate PHP version
• Validate dependencies versions
• etc.

So yes, RainTPL must be usable without composer.

But if you want a ligther project, as you seems to, you should not handle dependency in your projects.

Cheers,

Thomas.

2013/5/10 Federico Ulfo <rainel...@gmail.com>

[Rainelemental]

What stages and which templates?

From my iPhone

On May 10, 2013, at 2:11 PM, etor...@gmail.com wrote:

How do you think why Rain3 consumes same amount of memory on both stages?

Other template engines here tends to load with less footprint if page is already compiled.

--

[Rainelemental]

I don't see how a project that use composer is less light than another that doesn't. Performance wise is basically the same, is more organized and it makes faster to develop a project if needs third party open source components.

Composer doesn't fit well for projects that need customized components.

In conclusion Rain has only to gain good from Composer! Otherwise, you can still use w/o composer!

From my iPhone

[etor...@gmail.com]

On Friday, May 10, 2013 10:59:51 PM UTC+4, Rain wrote:

What stages and which templates?

Arrrgghh. I did a benchmark, shared and commented results (see above).

First visit. Compile and execute. Takes a lot of resources.

Second visit. Execute previously compiled PHP from cache. Takes little resources.

But RainTPL3 seems to take same amount of resources (~400) on both stages.

I wonder why it takes same amount when executes previously compiled page?

[Thomas ZILLIOX]

I said 'light", because you have less files to commit.
So, you can start a project faster.

Sure I don't think it affects performance.

See you,

Thomas.

2013/5/10 Rainelemental <rainel...@gmail.com>

[Federico Ulfo]

@thomas, I disagree. You don't have to commit the vendor/ folder, you only have to commit composer.json in your repository. And you definitely start a project faster with Composer than without it. The only reason for not using Composer is when you need to use your custom libraries.

@Etorealno I'm sure Rain is saving the cache somewhere else, because the parsing of the template is slow enough to be visible in your benchmark. Check the filepath.

[Thomas ZILLIOX]

I'm not really good in english, but you said what I tried to :'(

So I agree, but it was about convince @Etorealno.

Thomas.

2013/5/11 Federico Ulfo <rainel...@gmail.com>

@thomas, I disagree. You don't have to commit the vendor/ folder, you only have to commit composer.json in your repository. And you definitely start a project faster with Composer than without it. The only reason for not using Composer is when you need to use your custom libraries.

@Etorealno I'm sure Rain is saving the cache somewhere else, because the parsing of the template is slow enough to be visible in your benchmark. Check the filepath.

--

[etor...@gmail.com]

On Saturday, May 11, 2013 7:42:40 PM UTC+4, Rain wrote:

The only reason for not using Composer is when you need to use your custom libraries.

And when you want to stay as portable and less dependent as possible. 

So the best way is to have options for users of all kinds.

e.g. Mustache (another template engine) has three installation options.

 

@Etorealno I'm sure Rain is saving the cache somewhere else, because the parsing of the template is slow enough to be visible in your benchmark. Check the filepath.

My benchmark measures execution memory peak and speed.

Question: why other template engines use less memory when load compiled cache, but RainTPL3 shows same peak?

I have compressed my files (rain.php+lib+tpl+cache) for you, please download and see for yourself.

[Federico Ulfo]

@Thomas
Yup! Now days any new PHP projects should use Composer. Perhaps I've started to converted all the Rain libraries to components:

https://github.com/rainphp/RainDB
https://github.com/rainphp/RainForm

The next version of RainFramework will use those and other components and RainCMS will obviously require the RainFramework as component.

@Etorealno software portability is important, in most hosting you can't run composer install, so Composer is not an option. In fact CMS always ship with an installer. This doesn't mean that you can't create those project with composer, e.g. Drupal 8.

You can install Mustache with composer, or just download it, what's the third option?

Here's the issue in the benchmark:

Tpl::configure(array("tpl_dir" => "templates/", "cache_dir" => "cache/", "debug" => "false"));

this should be

Tpl::configure(array("tpl_dir" => "templates/", "cache_dir" => "cache/", "debug" => false)); 

Here's the results:

w/o cached template: 433.92 KB    0.006 s

with cached template: 430.19 KB   0.002 s

The memory doesn't change that much, but speed does. Benchmark are fun!

 

--

[etor...@gmail.com]

On Saturday, May 11, 2013 8:31:59 PM UTC+4, Rain wrote:

@Etorealno software portability is important, in most hosting you can't run composer install.

That's the very point I say here again & again.

That's why I ask developers to review current RainTPL3 bundle

and make proper changes to let it work outside /library/ folder

with just right "require_once" path.

Now it fires error when is placed in any other folder.

Arrgghh, I'm tired to repeat it.

 

Here's the results:

w/o cached template: 433.92 KB    0.006 s

with cached template: 430.19 KB   0.002 s

The memory doesn't change that much, but speed does. 

I'm almost ready to cry. Honestly. 

Please, read it slowly, it's NOT ABOUT speed, it's ABOUT memory,

I'm doing my best to get a reasonable reply, not a formal-in-hurry reply.

Why

memory consumption

stays the same

whereas

other template engines

use

visibly less memory

with cached template?

For example:

- Haanga 2.3 MB / 188 Kb

- Mustache 767 Kb / 424 Kb

- RainTPL 477 Kb / 477 Kb

- Smarty 3.8 MB / 1.3 MB

- Twig 2.9 MB / 1 Mb

Is RainTPL v3 optimized only for speed , not memory consumption? 

[Federico Ulfo]

That's why I ask developers to review current RainTPL3 bundle
and make proper changes to let it work outside /library/ folder
with just right "require_once" path.

RainTPL 2 works with require_once, RainTPL 3 only with an autoloader.

Is RainTPL v3 optimized only for speed , not memory consumption?

No. To make it lighter we'll have to decouple the parser from the loader, by splitting Tpl.php in Tpl.php and ParseTpl.php. You're welcome to do this if you want.

--

[etor...@gmail.com]

On Saturday, May 11, 2013 11:05:21 PM UTC+4, Rain wrote:

That's why I ask developers to review current RainTPL3 bundle
and make proper changes to let it work outside /library/ folder
with just right "require_once" path.

RainTPL 2 works with require_once, RainTPL 3 only with an autoloader.

This statement could confuse people as both v2 and v3 use require_once.

Difference is v2 requires rain.tpl.class.php and v3 requires autoload.php.

Whatever, thing is autoload.php should be rewritten to be more flexible.because now it works only from /library/ folder.

Do you understand the point?

 

Is RainTPL v3 optimized only for speed , not memory consumption?

No. To make it lighter we'll have to decouple the parser from the loader, by splitting Tpl.php in Tpl.php and ParseTpl.php. You're welcome to do this if you want.

Sounds like a great way to evolve for better!

I'm not that skilled developer myself to mess with the code, but you are.

Will you split parser from loader on next release?

[Alexander Sergéev]

New benchmark: one large template, two variables. (download)

    RESULTS

    1. Compile and execute (alphabetical order).

    Haanga 1.0.4                 in 417026 . out 417461

    - start: 524 288 bytes

    - end: 3 407 872 bytes

    - peak: 6 029 312 bytes

    - time: 0.0509 seconds

    Mustache                     in 417026 . out 1102840

    - start: 524 288 bytes

    - end: 20 971 520 bytes

    - peak: 23 330 816 bytes

    - time: 4.4725 seconds

    RainTPL 3                    in 417024 . out 417190

    - start: 524 288 bytes

    - end: 1 310 720 bytes

    - peak: 4 980 736 bytes

    - time: 0.3551 seconds

    Smarty 3.1                   in 417024 . out 418049

    - start: 524 288 bytes

    - end: 4 718 592 bytes

    - peak: 6 291 456 bytes

    - time: 0.2604 seconds

    Twig 1.13.0                  in 417026 . out 406092

    - start: 524 288 bytes

    - end: 6 553 600 bytes

    - peak: 6 553 600 bytes

    - time: 0.0851 seconds

    2. Execute compiled template from cache.

    Haanga

    - start: 524 288 bytes

    - end: 1 310 720 bytes

    - peak: 2 359 296 bytes

    - time: 0.0089 seconds

    Mustache

    - start: 524 288 bytes

    - end: 8 388 608 bytes

    - peak: 9 437 184 bytes

    - time: 0.0572 seconds

    RainTPL

    - start: 524 288 bytes

    - end: 786 432 bytes

    - peak: 1 835 008 bytes

    - time: 0.0128 seconds

    Smarty

    - start: 524 288 bytes

    - end: 2 359 296 bytes

    - peak: 3 407 872 bytes

    - time: 0.0172 seconds

    Twig

    - start: 524 288 bytes

    - end: 2 097 152 bytes

    - peak: 3 145 728 bytes

    - time: 0.0188 seconds

[Federico Ulfo]

cool

[moneywasher]

Hi Guys,

for me RainTPL 2 in the latest version (v. 2.7.2) works fine. Okay, it's already one year old .... but RainTPL 3 is a cruel for me.

I don't want overhead stuff. Not want and need any Framework things.  I want just a little agile Template Engine. So i not like this autoloading stuff.

I uploaded Rain 3 and have quickly delete it again.  ;-)

Rain 2 with just one class file is the best choice for me.

Hope there will be soon a posiblity of choice for Rain 3 as just one class file for downloading too.

[Federico Ulfo]

Will you split parser from loader on next release?

I've separated the Parser from the Tpl class to improve performances, reduce memory and separate responsibilities, can you please review it and test it?

https://github.com/rainphp/raintpl3/pull/69 

Thanks

--

[Alexander Sergéev]

On Friday, May 17, 2013 5:42:12 AM UTC+4, Rain wrote:

Will you split parser from loader on next release?

I've separated the Parser from the Tpl class to improve performances, reduce memory and separate responsibilities, can you please review it and test it? https://github.com/rainphp/raintpl3/pull/69 

Gladly. You'll find detailed review right there under your commit. In short, performance's getting slightly better. 

[Federico Ulfo]

Well, the main concern is that the library keep working and the code is easier to maintain, performance are just a sweet "consequences" of the split. From your benchmark seams like speed is unchanged but memory dropped a little bit, a nice improvement as expected.

We need more feedback before merge this branch into master, but I appreciate your help a lot. Thanks!

--