Smarty Forum Index Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon.

Smarty 3.0: initial discussion
Goto page 1, 2, 3 ... 10, 11, 12  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> Smarty Development
View previous topic :: View next topic  
Author Message
mohrt
Administrator


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

PostPosted: Mon Apr 04, 2005 10:47 pm    Post subject: Smarty 3.0: initial discussion Reply with quote

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
Back to top
View user's profile Send private message Visit poster's website
swapo
Smarty Regular


Joined: 04 Apr 2005
Posts: 46
Location: Lübeck, Germany

PostPosted: Mon Apr 04, 2005 11:37 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
xces
Smarty Regular


Joined: 09 Apr 2004
Posts: 77

PostPosted: Tue Apr 19, 2005 2:12 pm    Post subject: Reply with quote

Please consider that large web-based server management applications (*kuch* Plesk 7.5 reloaded *kuch*) (still) doesn't support PHP5 atm.
Back to top
View user's profile Send private message
::downtown::
Smarty Rookie


Joined: 20 May 2005
Posts: 33
Location: Berlin

PostPosted: Fri May 20, 2005 9:24 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
antileon
Smarty n00b


Joined: 12 Jun 2004
Posts: 2

PostPosted: Wed May 25, 2005 6:55 am    Post subject: Smarty can influence! Reply with quote

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
View user's profile Send private message
algo
Smarty n00b


Joined: 02 Jun 2005
Posts: 3

PostPosted: Thu Jun 02, 2005 11:21 pm    Post subject: Little coding for a great feature available.. Reply with quote

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
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Fri Jun 03, 2005 12:01 am    Post subject: Reply with quote

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
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Fri Jun 03, 2005 12:16 am    Post subject: Reply with quote

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
View user's profile Send private message
algo
Smarty n00b


Joined: 02 Jun 2005
Posts: 3

PostPosted: Fri Jun 03, 2005 12:21 pm    Post subject: Feature request Reply with quote

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
View user's profile Send private message
mohrt
Administrator


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

PostPosted: Fri Jun 03, 2005 1:54 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
algo
Smarty n00b


Joined: 02 Jun 2005
Posts: 3

PostPosted: Fri Jun 03, 2005 4:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
boots
Administrator


Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada

PostPosted: Fri Jun 03, 2005 11:14 pm    Post subject: Reply with quote

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
View user's profile Send private message
kills
Smarty Elite


Joined: 28 May 2004
Posts: 493

PostPosted: Sat Jun 04, 2005 1:41 pm    Post subject: Reply with quote

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
View user's profile Send private message
iamsure
Smarty Rookie


Joined: 02 Feb 2005
Posts: 22

PostPosted: Thu Jun 09, 2005 11:53 am    Post subject: Reply with quote

[edited]

Last edited by iamsure on Thu Jul 27, 2006 12:40 am; edited 1 time in total
Back to top
View user's profile Send private message
mohrt
Administrator


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

PostPosted: Thu Jun 09, 2005 1:41 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Smarty Forum Index -> Smarty Development All times are GMT
Goto page 1, 2, 3 ... 10, 11, 12  Next
Page 1 of 12

 
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