View previous topic :: View next topic |
Author |
Message |
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Mon Apr 04, 2005 10:47 pm Post subject: Smarty 3.0: initial discussion |
|
|
The core developers have been passing ideas around about Smarty 3.0 in private e-mails for awhile now. Lets get the ball rolling, what do you want to see? What should Smarty 3.0 accomplish?
I think one important design goal for Smarty 3.0 is to overcome its (currently) monolithic approach in class structure, breaking down the functionality into pieces so that the "probable use" cases load in the minimal amount of PHP code possible (think decorator pattern.) This basic structure change could easily lend itself to other things like pluggable compilers, streams integration, etc. Will this require PHP 5.0? Who knows. Its time to start the discussions ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
swapo Smarty Regular
Joined: 04 Apr 2005 Posts: 46 Location: Lübeck, Germany
|
Posted: Mon Apr 04, 2005 11:37 pm Post subject: |
|
|
Okay,
I won't go too much in details now. As mohrt already knows, my opionion about
breaking the monolith apart is quiet similar.
About php5 usage: It's not a question of *if* but *when* php5 will be the standard
in php servers. 5.1 is on its way and I believe that's the point when php4 will begin
to die. So I'd develop for the future, especially because php5 has some great advantages
that may become useful. Exception handling for example is a real big plus I think.
I don't know a thing, where php4 is really better than 5, except from some reports
of speed problems (but on the other hand speed advantages).
Let's build it for the future ![Very Happy](images/smiles/icon_biggrin.gif) |
|
Back to top |
|
xces Smarty Regular
Joined: 09 Apr 2004 Posts: 77
|
Posted: Tue Apr 19, 2005 2:12 pm Post subject: |
|
|
Please consider that large web-based server management applications (*kuch* Plesk 7.5 reloaded *kuch*) (still) doesn't support PHP5 atm. |
|
Back to top |
|
::downtown:: Smarty Rookie
![](images/avatars/190749835544168620e6752.jpg)
Joined: 20 May 2005 Posts: 33 Location: Berlin
|
Posted: Fri May 20, 2005 9:24 am Post subject: |
|
|
Why not using PHP5. I think PHP5 has some feature, to provide more readable and reusing code. I mean Interfaces and Abstract Classes.
And in PHP5 you only pass references from Variables and no clones.
This is a speed advantage for PHP5 ( less memory usage, reusable Objects ).
And correct:
Let's build it for the future _________________ Erik Seifert
http://www.b-connect.de |
|
Back to top |
|
antileon Smarty n00b
Joined: 12 Jun 2004 Posts: 2
|
Posted: Wed May 25, 2005 6:55 am Post subject: Smarty can influence! |
|
|
I also agree that Smarty should use the new features of PHP5. One good reason is that - let's face it: PHP5 is good. What is the only reason why we aren't using it as much today? - because there is a lack of support from hosting companies.
So if Smarty, which is used by a lot of PHP applications, start using PHP5 we force the hosting companies to evolve and install PHP5, and this is good for the entire PHP community.
Who is writing code for PHP3 today? |
|
Back to top |
|
algo Smarty n00b
Joined: 02 Jun 2005 Posts: 3
|
Posted: Thu Jun 02, 2005 11:21 pm Post subject: Little coding for a great feature available.. |
|
|
With PHP5.1 we have ArrayAccess and Countable: that is [] and count() overloading.
Please, don't convert objects to arrays explicitly in compiled templates, because that renders 'array masquerading' useless.
It is possible to keep compatibility simply by checking necessary interfaces.
For example, now we have (in compiled template)
count(\$_from = (array)$from)
After the suggested fix:
count($_from = is_a($from, 'Countable') && is_a($from, 'ArrayAccess') ? $from : (array)$from)
This fix seems to be
1) enough to make use of ArrayAccess/Countable
2) compatible with php4
That probably could be done in 2.x branch even.. |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri Jun 03, 2005 12:01 am Post subject: |
|
|
Actually, in recent versions this was changed. The compiled code is now driven by the following snippet in the compiler:
$output .= "\$_from = $from; if (!is_array(\$_from) && !is_object(\$_from)) { settype(\$_from, 'array'); }";
Objects are no longer being cast to arrays as they were in the past. With this code, the developer is expected to provide appropriate objects to the templates if they are going to be iterated.
Last edited by boots on Fri Jun 03, 2005 12:19 am; edited 1 time in total |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri Jun 03, 2005 12:16 am Post subject: |
|
|
Here's an idea I'm working on: runtime object composition through delegation
We would start with a very minimal Smarty class -- basically just enough functionality to implement a load method which imports additional facilities at runtime (modules). Overriding __call on the base Smarty class would allow us to make the (concrete) module methods look and act like standard methods on the Smarty object (by forwarding). Modules would be derived from a special class which overrides __get and __set to use properties held in a third object (a property-bag). The Smarty object would maintain a container of property-bags and modules would be initialized by passing them reference(s) to appropriate property-bags. This way, each loaded module could easily share properties with other loaded modules (and Smarty would co-ordinate this for the loaded module). Moreso, these properties can be easily shared with non-module code (such as plugins). Smarty's own __get and __set can also be overridden to forward to the property bags (this may require some cunning to figure out which bag to access). Smarty could define a series of standard property-bags to provide some structure. Refinements of this could include implementing interfaces to interact with property-bags and specializations of the interfaces to be defined for added structure. Note that the __get and __set on Smarty and the modules would probably have to be final to ensure consistent behaviour. Probably the same for __call.
Its really not too difficult to mock up some objects to accomplish this (I have some throw-away code doing this already). The question is, is it a useful design in this case? It would essentially replace all of the current "internals" code (which would be grouped into classes) and even the compiler could be implemented as a module. It could also help overcome some of the $this/$smarty shortcomings in the current code-base.
Just floating the idea for now. PHP5 has a strange sort of OOP but it is interesting.
One important question: should Smarty3 be based on PHP 5.0.x or 5.1.x? I tend to favour the latter. |
|
Back to top |
|
algo Smarty n00b
Joined: 02 Jun 2005 Posts: 3
|
Posted: Fri Jun 03, 2005 12:21 pm Post subject: Feature request |
|
|
It could be nice to have hooks for variable procession.
For example, I'm interested in safety of my templates, so I'd love to have
all variables escaped by default(when output), 'noescape' modifier serves as a way to leave variable as it is.
It is very important, because leaves no way to 'forget' escaping... And saves your time, because escaped variables are met much much more often then unescaped ones.
Currently, template is prefiltered and modifiers are adjusted ( |escape added where needed).
I suggest a hook that will take a variable with its modifiers, process them and pass on.
All blocks {$variable|modifiers..} will pass through that hook in compile-time and have their modifiers adjusted.
That allows implicit rules like 'auto-escaping', 'auto-truncation' to be implemented w/o hacking. |
|
Back to top |
|
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Fri Jun 03, 2005 1:54 pm Post subject: |
|
|
There are already default modifiers available in Smarty, although this solution isn't perfect... it doesn't know the difference between variables with output vs. other variables like tests inside an {if} statement. Typically you would only want a default modifier applied to variables with output. |
|
Back to top |
|
algo Smarty n00b
Joined: 02 Jun 2005 Posts: 3
|
Posted: Fri Jun 03, 2005 4:49 pm Post subject: |
|
|
yes, that is the main point here. One needs modifiers exactly in the moment of output usually...
suggested hooks are much more powerful then "default modifiers" anyway. |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Fri Jun 03, 2005 11:14 pm Post subject: |
|
|
I think that providing some programatic control over the output routines is a good idea, too.
I'm also for an (optional) alternate form of assignment via callbacks (this is what I usually think of when someone mentions hooking data). That one is much easier to implement outside of the Smarty class, though, so maybe it is not really that important.
Another question: How much backwards compatability is important? Is it enough to be able to compile 2.x templates? How about plugins and other extensions to Smarty? |
|
Back to top |
|
kills Smarty Elite
Joined: 28 May 2004 Posts: 493
|
Posted: Sat Jun 04, 2005 1:41 pm Post subject: |
|
|
I think its also important to have a configuration class which allows reading and writing of config files. Also referencing in keys to other keys were a nice feature.
Bye, Markus |
|
Back to top |
|
iamsure Smarty Rookie
Joined: 02 Feb 2005 Posts: 22
|
Posted: Thu Jun 09, 2005 11:53 am Post subject: |
|
|
[edited]
Last edited by iamsure on Thu Jul 27, 2006 12:40 am; edited 1 time in total |
|
Back to top |
|
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Thu Jun 09, 2005 1:41 pm Post subject: |
|
|
Two possibilities to that:
1) maintain Smarty 2.x for the PHP4 users until PHP4 dies off.
2) make Smarty 3.x compatible with both PHP4 and PHP5. PHP5 has some radical language features that can be leveraged... it may be possible to support PHP4 transparently, but likely have some performance and/or feature drawbacks. Until some code gets written there are obviously some unknowns for this one. |
|
Back to top |
|
|