 |
Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon. |
|
| View previous topic :: View next topic |
| Author |
Message |
brandon
Smarty n00b
Joined: 08 Nov 2004
Posts: 4
|
 Posted: Mon Nov 08, 2004 4:03 am Post subject: why only 1 level of object nesting? |
 |
|
I'm trying to use Smarty with nested objects. But when I try to do method chaining, I get:
Smarty error: [in File.tpl line 7]: syntax error: unrecognized tag: $person->getAddress()->getState()->getAbbreviation() (Smarty_Compiler.class.php, line 417) WARNING 2004-11-07 21:45:54 : ) lib/smarty/Smarty.class.php:1088
I see on line 144 in Smarty_compile.class.php that this is intentionally limited to one level. Is there any reason for that? It really messes up my object model if this won't work.
Brandon |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Mon Nov 08, 2004 8:12 am Post subject: |
|
|
Hi. I figure that it is probably like that as this sort of dereferencing isn't supported in PHP4, AFAIK.
Last edited by boots on Mon Nov 08, 2004 8:54 am; edited 1 time in total |
|
| Back to top |
|
messju
Administrator
Joined: 16 Apr 2003
Posts: 3336
Location: Oldenburg, Germany
|
| Posted: Mon Nov 08, 2004 8:35 am Post subject: |
|
|
| correct. the reason why this is limited is, that you would get invalid syntax in php4 otherwise. |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Mon Nov 08, 2004 9:23 am Post subject: |
|
|
I just thought I'd add a little bit of opinion here. I want to make clear that I am talking about nested method derefrencing--nested objects are another matter.
It seems natural to ask why not emulate PHP5's defrencing behaviour in Smarty by automagically compiling intermediate temporary assignments for the dereferences under PHP4. Of course, emulating that in user space is a bad idea in my mind but even if it is doable (which is an open question so far) it begs the question: why is it needed in template anyhow?
I think the idea of passing in objects into the template to support property references seems justifiable enough but to support method calls is another thing. Asides from being a go-around of the plugin system (unneccessarily tightening the coupling between your application structure and the template) it can be asked why other techniques are not explored. There are several, and here are a few to consider, separately or together:
- expose values as properties instead of methods;
- flatten the data model received by the template as much as possible to simplify the designer's task;
- use arrays instead of objects (and possibly transform objects into arrays before being passed)
Granted, it is sometimes very helpful to have assigned objects that have methods that return values/arrays so as to delay expensive aquisition/processing of data that is optional for some templates. Still, this is achievable in Smarty. |
|
| Back to top |
|
brandon
Smarty n00b
Joined: 08 Nov 2004
Posts: 4
|
| Posted: Mon Nov 08, 2004 2:05 pm Post subject: |
|
|
| boots wrote: | | correct. the reason why this is limited is, that you would get invalid syntax in php4 otherwise. |
Oh yeah, that would be a good reason. I guess I've been using PHP 5 for so long that I've forgotten that.
| Quote: |
I just thought I'd add a little bit of opinion here. I want to make clear that I am talking about nested method derefrencing--nested objects are another matter.
It seems natural to ask why not emulate PHP5's defrencing behaviour in Smarty by automagically compiling intermediate temporary assignments for the dereferences under PHP4. Of course, emulating that in user space is a bad idea in my mind but even if it is doable (which is an open question so far) it begs the question: why is it needed in template anyhow? |
I think that is a great idea.
In the mean time, I'm trying to modify smarty to work with this since I'm using PHP 5 (I already have a somewhat hacked up version of Smarty just to get it to work with PHP 5 strict). It looks to me like I just need to change the regexp that checks if the object call is valid or not, but I can't seem to get it to work. Would someone be able to help me with this? The regexp's are on lines 155-164 of Smarty_Compiler.class.php. Does anyone know if I would need to make furthur changes?
Thanks,
Brandon |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Mon Nov 08, 2004 3:49 pm Post subject: |
|
|
No, it is a bad idea to emulate it is user-space  It would be much better if that was supported by PHP directly in the engine -- but that's not going to happen in the PHP4 branch.
Also, instead of hacking Smarty to get it to work under E_STRICT, why not just turn error reporting down to something more reasonable for a PHP4 library (ie. something less than E_STRICT) and turn it back up after loading Smarty? I wish the PHP Group was a bit more realistic with E_STRICT and only had it reporting deprecated notices during a lint instead of during normal execution. Has anyone else thought the same?
Finally, hacking the regex's is probably the last thing you want to do. Unless you are making patches that end-up in Smarty itself, tracking changes in that portion of the code is tricky at best. I'm sure you know what you are doing, but proceed with caution. As an example, there were recently several changes to the regex's which I didn't follow very closely the upshot being that I can't make any suggestsions to you on how to proceed there. That despite the fact that I try to stay current with the source; perhaps you get my meaning about customizing the regexes.
Cheers! |
|
| Back to top |
|
brandon
Smarty n00b
Joined: 08 Nov 2004
Posts: 4
|
| Posted: Tue Nov 09, 2004 1:03 am Post subject: status of PHP5 support |
|
|
So, what is the plan then for a php 5 version of smarty? I am writing an application based on some pretty bleeding edge tools (Mojavi 3, propel, & phing), all using PHP 5. I've patched smarty to work with PHP 5 strict because it is the default setting for most installations (I know it can be changed at runtime, but I like to avoid that if possible). Is there a PHP 5 branch in the works yet for smarty?
Thanks,
Brandon |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Tue Nov 09, 2004 2:04 am Post subject: Re: status of PHP5 support |
|
|
| brandon wrote: | | So, what is the plan then for a php 5 version of smarty? I am writing an application based on some pretty bleeding edge tools (Mojavi 3, propel, & phing), all using PHP 5. I've patched smarty to work with PHP 5 strict because it is the default setting for most installations (I know it can be changed at runtime, but I like to avoid that if possible). Is there a PHP 5 branch in the works yet for smarty? |
It wouldn't be called bleeding edge if there wasn't any bleeding involved, huh?
AFAIK, there are currently no definate plans for a PHP5 version of Smarty. Additionally, there is presently no branch specific to PHP5. By many accounts the PHP5 branch would be the starting point for a re-architecture (Smarty 3.x.x) which would almost certainly break BC so that new features can be added and old cruft removed. To that end, there have been some suggestions and summarizing of possible avenues that can be explored in the smarty-dev mailing list, to a lesser extent here at the forums and also amongst the frequent contributors. From what I have followed there is no concensus on what the redesign should include and how it should work. I think there is a wait-and-see attitude while PHP5 continues to mature so as to determine which features will be relevant in any new endeaver. Importantly, PHP5 adoption is still in the ramping up phase and is still dwarfed by PHP4 usage.
That said, there is likely merit in an interim PHP5 branch since the current code-base doesn't support some features which are reasonably expected in PHP5 installations such as the derefrencing and strict rules you mention as well as iterator support for foreach loops. One problem is that templates that use those features won't be BC with PHP4/Smarty so templates written against Smarty 2.6.x/PHP5 won't necessarily work on Smarty 2.6.x/PHP4 installations which I think is a big-deal. Developing with PHP5 features at home only to upload your templates to your host provider and find that they won't work is not a good thing. There is also a realistic concern if maintaining (and supporting!) two separate branches is feasible at this time considering the developer/contributor resources that are available.
Back to the derefrencing issue: there is no gaurantee that it would be included in even a re-architectured version. The value of adding such a feature to the template language is still debatable.
Monte or Messju can give better insights than I, so I will ask a question as we wait for them to weigh-in: are there enough developers out there willing to maintain and support a PHP5-compatability branch?
Another question: what is Pear doing about the E_STRICT compatability issue? |
|
| Back to top |
|
brandon
Smarty n00b
Joined: 08 Nov 2004
Posts: 4
|
| Posted: Tue Nov 09, 2004 3:39 am Post subject: Re: status of PHP5 support |
|
|
| boots wrote: | | It wouldn't be called bleeding edge if there wasn't any bleeding involved, huh? |
Yeah, but someone has to do it. If I bleed now, I'm helping somene else down the road. What would happen if there weren't any early adopters? 
| boots wrote: | | Back to the derefrencing issue: there is no gaurantee that it would be included in even a re-architectured version. The value of adding such a feature to the template language is still debatable. |
I think that a lack of this feature goes against the principles that smarty promotes: separation of logic and presentation, encapsulation of data, MVC pattern, etc. The "enterprise level" (if there is such a thing) technologies that I have used (EJB, Hibernate, Struts, JSTL, etc) all strongly encourage the use of objects to encapsulate data. What is the point of even using a solid data model if you have to translate it into an associative array before it can be sent to the view? IMHO, and I believe something I've heard some of the developers of PHP say, associative arrays are just a hack to overcome a poor object model in PHP 4. Plus, what is the difference in my template if I use {$array.some.data} or {$array->getSome()->getData()}? Or, if you want to follow the jsp expression language syntax, you could just use {$array.some.data} and if $array is an object, then assume it follows the java beans standard and has get/set methods. I think this is more consistent with similar technologies in other languages. What do you think?
| boots wrote: | | Monte or Messju can give better insights than I, so I will ask a question as we wait for them to weigh-in: are there enough developers out there willing to maintain and support a PHP5-compatability branch? |
I haven't been involved with smarty development in the past, and I'm not completely familiar with all the internals, but I would be more than willing to help. I don't think it would take a lot to create a 2.6.x/php5 branch. The changes for the version I'm running are only 105 lines, almost all of which are just changing the var keyword to public/protected/private. |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Tue Nov 09, 2004 6:06 am Post subject: Re: status of PHP5 support |
|
|
Hi Brandon.
| brandon wrote: | | If I bleed now, I'm helping somene else down the road. What would happen if there weren't any early adopters? |
You go brother! I've ridden that road myself in the past and if you are willing to chart the terrain, I'm certainly willing to learn from your trials.
| brandon wrote: | | I think that a lack of this feature goes against the principles that smarty promotes: separation of logic and presentation, encapsulation of data, MVC pattern, etc. The "enterprise level" (if there is such a thing) technologies that I have used (EJB, Hibernate, Struts, JSTL, etc) all strongly encourage the use of objects to encapsulate data. |
We agree that data encapsulation is good; I hardly need to point out that we have been doing just that for years without the help of method-derefrencing. Object centric languages will of course promote object based approaches--nothing wrong with that either. If those features are a fine fit for your application, by all means, use them. I still don't see why they are necessary in template land, though. After all, templates are supposed to render a given (structured) data set, you are not meant to write programs against the structures that are passed into a template. The idea is to keep the passed data formats as simple as possible, probably more simple than required by the application.
| brandon wrote: | | What is the point of even using a solid data model if you have to translate it into an associative array before it can be sent to the view? IMHO, and I believe something I've heard some of the developers of PHP say, associative arrays are just a hack to overcome a poor object model in PHP 4. |
I suppose you mean object model (instead of data model--you don't need objects to implement a tree structure after all). The point, I'd propose, is that the object model is for your application and the developers that have to write it. Templates want simple structures as interfaces, not complicated object models. Serialization to other formats is no big deal in today's scripting world. We do it all the time: flat-file to relational db, XML to object-structures, etc.
IIR, the story actually goes that PHP4 objects were implemented as a dirty hack of arrays (originally in a weekend, I believe). Arrays have always been top-drawer in PHP.
| brandon wrote: | | Plus, what is the difference in my template if I use {$array.some.data} or {$array->getSome()->getData()}? Or, if you want to follow the jsp expression language syntax, you could just use {$array.some.data} and if $array is an object, then assume it follows the java beans standard and has get/set methods. I think this is more consistent with similar technologies in other languages. What do you think? |
I think a lot about that Like I said prior, I'm fairly comfortable with an object that is accessed by its property values, it is the method derefrencing that throws me. Perhaps it is my lack of experience with PHP5 but using get/set for every access to a property that is likely short lived anyhow seems like major overkill and can lead to tremendous confusion (for the template folks, anyways). Remember, a key idea in templates is that they are not supposed to alter the data model -- in other words, they are supposed to be read-only clients. So then, what can be more straightforward (and lightweight) than packaging your data in easy to digest structures like shallow hashed-arrays? Not to mention it is far easier/faster to serialize/deserialize data when in that form -- no object overhead. After all, encapsulating data does not mean turning it into code, it means exposing it in a controlled manner via code and the Smarty->assign() facility does just that.
As a caveat I want to mention that I'm quite happy to see method derefrencing in PHP5. I think it makes some programmer tasks a little more elegant, particularly for properties -- but as far as templates go, I'm not quite sold (but I wouldn't be completely surprised if a majority had other opinions on the matter).
Greetings. |
|
| Back to top |
|
boots
Administrator
Joined: 16 Apr 2003
Posts: 5611
Location: Toronto, Canada
|
| Posted: Tue Nov 09, 2004 10:54 pm Post subject: |
|
|
Hmm. Instead of a complete branch, how about a set (*.class.php) of extended class wrappers that implement all the PHP5 features? The extended class implementation can mute error_reporting before loading the base classes and then turn it back up afterwards, as required.
If I had the time, I'd do the conversion and post it to the wiki... |
|
| Back to top |
|
|
|
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
|
|
