Smarty Forum Index Smarty
The discussions here are for Smarty, a template engine for the PHP programming language.
Smarty 3.0 Alpha 1: Proof of Concept
Goto page 1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic    Smarty Forum Index -> Smarty 3
View previous topic :: View next topic  
Author Message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7264
Location: Lincoln Nebraska, USA

PostPosted: Fri Sep 19, 2008 10:42 pm    Post subject: Smarty 3.0 Alpha 1: Proof of Concept Reply with quote

I have submitted some code as a proof of concept for the Smarty 3.0 engine.
You can find it here:

http://smarty-php.googlecode.com/svn/branches/Smarty3Alpha/

It would be best to read through the README first, as it covers most of the thoughts and ideas that went into this code.

http://smarty-php.googlecode.com/svn/branches/Smarty3Alpha/distribution/README

You can check out the code with the following:

Code:
svn checkout http://smarty-php.googlecode.com/svn/branches/Smarty3Alpha/


Please leave your thoughts and feedback on this thread.


Last edited by mohrt on Wed Jun 10, 2009 2:33 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
U.Tews
Administrator


Joined: 22 Nov 2006
Posts: 4625
Location: Hamburg / Germany

PostPosted: Sat Sep 20, 2008 12:20 pm    Post subject: Reply with quote

Hi Monte. Thanks for your proof of concept.

I think it is a good aproach. I have made some work of testing where I made the core compiler class as slim as possible by creating a separate compiler class for each tag, which is just autoloaded when needed by the template.

Other topic is the parsing of the templates. Have you thought about using a lexer? I just started to look into it a little bit. I will update you whenever I have some results.
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7264
Location: Lincoln Nebraska, USA

PostPosted: Sat Sep 20, 2008 3:15 pm    Post subject: Reply with quote

Lexers have come up before. I haven't had luck with them, but I haven't looked at them in awhile either. It would need to be a lexer that runs entirely in PHP. One with potential is here:

http://pear.php.net/package/PHP_LexerGenerator
Back to top
View user's profile Send private message Visit poster's website
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7264
Location: Lincoln Nebraska, USA

PostPosted: Sat Sep 20, 2008 3:29 pm    Post subject: Reply with quote

I have moved the internal plugins to /libs/sysplugins/. Update your SVN if you checked it out already.
Back to top
View user's profile Send private message Visit poster's website
U.Tews
Administrator


Joined: 22 Nov 2006
Posts: 4625
Location: Hamburg / Germany

PostPosted: Sat Sep 20, 2008 4:40 pm    Post subject: Reply with quote

I am just trying out some stuff with the PHP_LexerGenerator
Back to top
View user's profile Send private message
flatfield
Smarty Rookie


Joined: 30 Apr 2007
Posts: 18
Location: Genova (Italy)

PostPosted: Thu Sep 25, 2008 10:01 am    Post subject: Reply with quote

Smarty 3 in development? Excellent news! Very Happy
Back to top
View user's profile Send private message Visit poster's website
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7264
Location: Lincoln Nebraska, USA

PostPosted: Mon Sep 29, 2008 8:22 pm    Post subject: Reply with quote

Here are some thoughts on syntax, posted to the dev list:

http://groups.google.com/group/smarty-developers/browse_thread/thread/c29ae569842882cd

I have not thought through things like modifier syntax yet.
Back to top
View user's profile Send private message Visit poster's website
Celeb
Administrator


Joined: 17 Apr 2007
Posts: 1025
Location: Vienna

PostPosted: Wed Oct 01, 2008 8:22 am    Post subject: Reply with quote

I definitely like this idea:
Code:
{$foo[$bar][$foo['bar']]}

I guess it would get rid of alot of temporary {assign} workarounds we encounter here almost on a daily basis.

I also like getting rid of {section} and introducing {for}. It just seems more .. PHPy Smile

You said in your post, the Smarty compiler would basically be a prefilter. Do you think we'll be able to compile custom [block] functions, modifiers, etc using "just" a prefilter? In a sense the current Smarty compiler is nothing more than a sophisticated prefilter aswell. Smile

What concerns me about the idea of templates being full-fledged PHP scripts is security. Today we are able to decide, which PHP functions can be used and if the template designer is allowed to use PHP at all. With a template being a PHP script only having the delimiters replaced, it might be difficult to restrict the template designers possibilities.

And last but not least, how do you plan on accessing the tpl_vars array built by assign() in the templates. For example, how do you plan on converting
Code:
{$foo}

into
Code:
<?= Smarty::instance()->tpl_vars['foo']?>

I don't want to say, this is hard to accomplish (a quite basic regex could easily do this, it would kinda put us back to Smarty 2, though), I'm just curious about your thoughts on it.

I just checked out the latest Smarty 3a SVN. Did you get rid of the idea of multiple Smarty instances? Was there a reason for that? I kinda liked the idea, however, I can think of one or two problems it might introduce.
_________________
Darn computers always do what I tell them to instead of what I want them to do.
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7264
Location: Lincoln Nebraska, USA

PostPosted: Wed Oct 01, 2008 1:38 pm    Post subject: Reply with quote

Quote:

You said in your post, the Smarty compiler would basically be a prefilter. Do you think we'll be able to compile custom [block] functions, modifiers, etc using "just" a prefilter? In a sense the current Smarty compiler is nothing more than a sophisticated prefilter aswell.


I'm pretty sure there is going to be a tokenizer that comes with Smarty, so it won't be a prefilter that does this. As a matter of fact, there will be some things we'll want to keep, such as modifier syntax {$foo|bar|blah}. Custom block functions are not going away.

Quote:
What concerns me about the idea of templates being full-fledged PHP scripts is security.


If you choose to go the route of pure PHP templates, then you probably are not after template security. I doubt security restrictions will be placed on php-only templates. (although its possible, think prefilter again)

Quote:
And last but not least, how do you plan on accessing the tpl_vars array built by assign() in the templates. For example, how do you plan on converting
{$foo}

into
<?= Smarty::instance()->tpl_vars['foo']?>


In short, we don't Smile I'm pretty sure that Smarty 3 will be taking a new route and extract()ing the tpl variables just before the templates are displayed. So {$foo} would just get compiled to <?=$foo?> (well actually <?php echo $foo; ?> we don't use short tags in compiled code.)
Back to top
View user's profile Send private message Visit poster's website
Celeb
Administrator


Joined: 17 Apr 2007
Posts: 1025
Location: Vienna

PostPosted: Wed Oct 01, 2008 2:12 pm    Post subject: Reply with quote

Quote:
I'm pretty sure there is going to be a tokenizer that comes with Smarty, so it won't be a prefilter that does this. As a matter of fact, there will be some things we'll want to keep, such as modifier syntax {$foo|bar|blah}. Custom block functions are not going away.

I'm glad to hear that. I like the current modifier syntax.

Quote:
If you choose to go the route of pure PHP templates, then you probably are not after template security. I doubt security restrictions will be placed on php-only templates. (although its possible, think prefilter again)

I thought so about the pure PHP templates. Though, if Smarty 3 templates are going to be preprocessed PHP files of some sort there must be some way to prevent
Code:
{$foo}
<? evil_function(); ?>

I don't think you're stupid and wouldn't think of something like this yourself, I just wanted to point it out and hear your thoughts about restricting such a thing.
You could just strip the <? ?> tags, though that would be a very Smarty 2y solution and I don't know if you want to go this way.

Quote:
In short, we don't Smile I'm pretty sure that Smarty 3 will be taking a new route and extract()ing the tpl variables just before the templates are displayed. So {$foo} would just get compiled to <?=$foo?>

Okay, thanks for answering the question I intended to ask but didn't Smile
How do you intend to extract them? Well,
Code:
foreach($tpl_vars as $key => $value) $$key = $value;

would certainly extract them, but what do you do with already existing variables (if there are any)? There might be a $smarty array providing the data the Smarty 2 $smarty does. What if somebody assigns a variable called "smarty" or "this" or something similar?

Do you plan to build some sort of {include}? Will it have the same variable-changes-in-child-don't-affect-parent-variables policy?
Well .. maybe asking those questions is a little early since they seem to regard implementation rather than design.

I guess I should get my IRC client going again so I can ask all this stuff in "person" Smile
_________________
Darn computers always do what I tell them to instead of what I want them to do.
Back to top
View user's profile Send private message
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7264
Location: Lincoln Nebraska, USA

PostPosted: Wed Oct 01, 2008 2:19 pm    Post subject: Reply with quote

With security enabled, there would be no PHP allowed in the templates, as per usual.

I haven't looked into the details yet, but I think the variables will be a straight up extract, then special variables will get their attention.

I would imagine {include} will still exist, but haven't gotten to those details yet.
Back to top
View user's profile Send private message Visit poster's website
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7264
Location: Lincoln Nebraska, USA

PostPosted: Wed Oct 01, 2008 2:24 pm    Post subject: Reply with quote

Quote:
I just checked out the latest Smarty 3a SVN. Did you get rid of the idea of multiple Smarty instances? Was there a reason for that? I kinda liked the idea, however, I can think of one or two problems it might introduce.


I got rid of multiple instances because it caused problems with autoload (no way to pass id to reference which instance.) For now, it is a singleton instance. There should be no reason to run multiple instances of Smarty anyways. We'll see what crops up.
Back to top
View user's profile Send private message Visit poster's website
vain
Smarty Rookie


Joined: 20 May 2006
Posts: 23
Location: Berlin / Germany

PostPosted: Sat Oct 04, 2008 5:28 pm    Post subject: Reply with quote

Wooh! Smarty 3 on the horizon! Very good news!

Some thoughts to discuss:

1) Trac for Smarty
Unless you are already hosted on GoogleCode or some other environment, i would suggest to setup a project environment
like Trac (wiki, bugtracking, roadmap, svnbrowser, use login from board on trac).

2) Centralized Source / Project Structure
I would also suggest to build a clear! centralized structure around the core repository. Maybe a Plugin Repository under QA and possibly some open user contributable repositories. Please do not store code in the forum or the wiki - it's ok for creativeness, but results in some kind of mess!

3) Thoughts on Syntax
a) what about a lexer for array sub-expressions:
$foo.bar.($bar.baz) or {$foo[$bar][$bar['baz']]} ?
b) +1 for kicking {section}
c) {literal} should be dropped also, there's no need for manual escaping
d) +1 for no short-tags <?=$foo?>, instead <?php echo $foo; ?>
e) better support for objects in the templates:
{$obj->method()->field} or
{include file="stuff.tpl" title=$obj->method()->field}

4) What i learned from SmartyDOCB (Rendering Processor Plugin) ...

a) It's important to know, where things come from!
Even more when having powerfull syntax-features like "moveto" from subtemplates. We needed not only the compiled output, but "$this->_current_file" for the current template file, to know which file is/was processed! This was only possible by overriding the Smarty Compiler Code. So i'm requesting not only the compiled output, but file infos also.

b) It's important to know, where things should moveto!
New Syntax Feature proposal: {moveto}
This is coming from SmartyDocB and adresses the question on how to include javascript and css in the head of the mainframe template while it is being built from subtemplates?
Basically this syntax shuffles off styles and scripts to external files or to certain tag-positions!
{moveto target=head} content for the head {/moveto}
{moveto target=customtag} content for the customtag-position {/moveto}
{moveto target=file file='my.js'} <javascript> {/moveto}

c) Template Engine on the limit, when it comes to "Document Generation"
Some problems have driven us nuts: how to prevent that files are included twice? how to move things to custom tag positions?

One possible solution we came up with, was, to think of leafs (key/slots) named after tags in a composite tree structure of the document generated. This adresses the central part of a view handling system!

This idea is also connected to {include} and the variable-scopes of includes, which could be stored as meta-data in leaves (in other words: composite views) of such a tree.

That approach (or something similar) really takes the thing to another level. When we speak about pure PHP-Templates this question comes even more into focus, because the typical task of pushing things into the template is gone! One would say: I have now php-templates
with objects inside, but i still have to assemble a document from 50 subtemplates. So what's left as a smarty task?

For me, one important design goal is to think of Smarty 3 as a "Flexible Document Processor". The original task of Smarty: replacing smarty-placeholders by php-code is just a prefilter! This is the nature of a template engine. And the reason to do this is: security, because templates with own template-language provide a secured, sandboxed environment!

In Smarty 3 it's taken to the next level of parsing flexibility by dropping regular expression in favour of an Lexer.
This is a huge step! I'm happy to see this!

I bring this kind of thinking up again, because i hope we could draw some positive stuff from the SmartyDoc(B) Rendering Processor into Smarty v3.
Back to top
View user's profile Send private message Visit poster's website
mohrt
Administrator


Joined: 16 Apr 2003
Posts: 7264
Location: Lincoln Nebraska, USA

PostPosted: Sat Oct 04, 2008 9:11 pm    Post subject: Reply with quote

Quote:
1) Trac for Smarty


Smarty is in google code, and Smarty 3 will also stay there. We only have an alpha SVN for it thus far, so nothing too official yet. The lexer is coming along nicely. I plan on booting the current wiki in favor of either a local wiki or something else local.

Quote:
2) Centralized Source / Project Structure


Agreed.

Quote:
3) Thoughts on Syntax


A lot of these syntax issues are already addressed by the lexer. We can do sub-expressions and in-template math no problem. nested objects are no problem either. With a lexer, recursion problems are a thing of the past.

The need for {literal} is pretty much going away. Delimiters followed by whitespace will no longer be parsed as a template tag.
Back to top
View user's profile Send private message Visit poster's website
Notromda
Smarty Rookie


Joined: 30 Aug 2004
Posts: 13

PostPosted: Thu Oct 16, 2008 12:35 am    Post subject: Reply with quote

+1 for php templates, and for short tags.

I just discovered a trick I like for my own smarty subclass that may be good for smarty... in PHP5, use the builtin ArrayAccess class:
Code:

class Smarty Implements ArrayAccess { ...


with the required functions implemented, it makes it easier to assign data:

$smarty["foo"] = "bar";

combine that with <?=$foo?> and we have the best of all worlds IMHO Smile
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Smarty Forum Index -> Smarty 3 All times are GMT
Goto page 1, 2, 3, 4, 5, 6, 7  Next
Page 1 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP