Smarty Forum Index Smarty
The discussions here are for Smarty, a template engine for the PHP programming language.

Smarty 3.0: initial discussion
Goto page Previous  1, 2, 3, 4 ... 10, 11, 12  Next
 
Post new topic   Reply to topic    Smarty Forum Index -> Smarty Development
View previous topic :: View next topic  
Author Message
mohrt
Administrator


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

PostPosted: Fri Jul 15, 2005 2:30 pm    Post subject: Reply with quote

{include file="`$smarty.config.news_tpl_folder_name`$news_tpl_name"}

or

{include file=$smarty.config.news_tpl_folder_name|cat:$news_tpl_name}

or

{include file=#news_tpl_folder_name#|cat:$news_tpl_name}
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


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

PostPosted: Fri Jul 15, 2005 5:09 pm    Post subject: Reply with quote

Personally, I think there are too many variable notations. We have: $foo, #foo#, $foo.bar, $foo[$bar], $foo[bar] (in sections) and of course, $foo->bar -- plus many combinations of these. I think we need to simplify and just support $foo.bar (and possibly $foo[$bar] as well). I also think we only need one type of loop structure.
Back to top
View user's profile Send private message
mohrt
Administrator


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

PostPosted: Fri Jul 15, 2005 6:10 pm    Post subject: Reply with quote

I agree from a template-user point of view. However, there are technical reasons why the template syntax is so diverse, mostly because the variable type may not be known at compile time, so the compilation step must know this information by the syntax. This can be a good 3.0 discussion topic.
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


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

PostPosted: Fri Jul 15, 2005 6:50 pm    Post subject: Reply with quote

mohrt wrote:
I agree from a template-user point of view. However, there are technical reasons why the template syntax is so diverse, mostly because the variable type may not be known at compile time, so the compilation step must know this information by the syntax. This can be a good 3.0 discussion topic.


Yes, but I think that is mainly a response to the object vs array issue which, in PHP 5, can be implemented around. mkahn presented such a mechanism in
this thread
. I think there is reason to justify forgoing some speed in favour of a simplified template syntax. Of course, it may be worthwhile to discuss the merits and pitfalls of overloading constructs as would be the case here. Mainly I see it as a good thing here because the differences are not particularly semantic at the template level but rather exhibit themselves as such at the application level; hiding those details from template users seems like a big win both because they wouldn't have to become experts concerning the application's structural implementation and further because it implies less coupling between the application and the template. On the other hand, depending on how much application "work" is done in the templates (which is a dodgy proposition anyhow), this may complicate debugging and testing issues when things do go wrong.

As for config vars, I see no particular reason that they have a different syntax than template vars except for the fact that config vars are "static". This too is probably just another implementation detail that the engine can manage. Interestingly, config vars can not be assigned except by an import which is generally more in-line with template patterns usage of passed-in variables. I would suggest that if there is a general way for template users to import data from within the template, they should import it into the template variable scope rather than a separate scope that requires a different syntax. If need be, the import process can create a static serialization of the data to mimic the static behaviour of config vars and a complete solution might even be abstracted with a plugin system so that we might have something like a callback into an application level data provider.

Another point I think merits discussion is the concatenation and sub-expression problem. It seems that if we did a proper lex/parse of variables we might be able to introduce a parens notation for sub-expressions: $foo.($bar.baz).bar and so on. I was wondering if we can use a hybrid parser for that -- regex all smarty tags out and then proper parse each tag content so that we can handle parens nesting and the like.
Back to top
View user's profile Send private message
boots
Administrator


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

PostPosted: Fri Jul 29, 2005 4:08 am    Post subject: Reply with quote

Currently, assign() is used to pass information to the template (along with $smarty magic and {config_load}). As a result, templates are neither gauranteed of what they will recieve nor is any introspection -- or typically, even documentation -- available. Even in the case that documentation is available, it is invariably manually produced rather than being mechanically generated from doc comments and/or specification configuration files/data.

Consider a custom property bag class that acts as a contract for values passed to a template. The base class would provide some __get() and __set() magic to defer to getter and setter methods and/or defined properties -- for example, if no getter/setter is available but the property is defined as global. Instances of derived contract objects would be assignable to Smarty and act as the template variable scope (and perhaps even function scope). With some additional behind-the-scenes mechanics this can potentially give an object that defines a contract, enforces/validates both sides of the contract, enables 2-way introspection and additionally provides for user defined functionality such as custom filtering and escaping.

Of course, there are many ways to design and build such a feature out. I am first wondering if others think that this merits consideration.
Back to top
View user's profile Send private message
Swatinem
Smarty Rookie


Joined: 26 Jan 2005
Posts: 12

PostPosted: Fri Aug 05, 2005 9:20 pm    Post subject: Reply with quote

without having read the whole thread i would definetely prefer PHP5 (5.1 would be good too).
Sure, many hosters won't support PHP5 in 1-2 years but just think about the time that Smarty 3 would take to develop. I mean it sounds like everything needs to be coded from scratch. And in 1-2 years when its finished, the hosters will support PHP5.
Develop for the future and not for the past.

One thing i have integrated in my personal copy of smarty is the ability to delete the cache depending on the objects used in them. The CMS i'm currently developing should be as flexibel and lightweight as possible. Almost everything is cached and when a content is changed only the cache files utilizing that object are deleted the others dont need to get refreshed. I also integrated a better use of dynamic caches. Every cache file is now a php-file as well just like the template and it can contain dynamic code.
I think such features would be great for smarty3 as well.
Back to top
View user's profile Send private message
TommyD
Smarty Rookie


Joined: 20 Feb 2004
Posts: 18

PostPosted: Wed Aug 10, 2005 2:11 pm    Post subject: Reply with quote

Hello guys!

I'm very happy that work behind the scenes goes on (after I haven't seen many news on the frontpage in the last couple of months Smile, anyways,
two things:

At first, please implement Smarty 3.x completly with PHP5. You have no deadlines or whatever for this, just because Smarty 2.x is great as-is on PHP4 and PHP5 installations. Make a good product, make it stable, and well, make it fast =) - you have the time for it!

Secondly, a feature request: I'd like to see better i18n integration with Smarty. Currently I'm doing i18n via config files (including different config files for different languages), which works out fairly well, but when it comes to formatting stuff most of the supplied modifiers are "stupid" in such a case that I need to give them hints (parameters) everytime I want to format e.g. a datetime value or currency amount properly for a certain target audience.

I know that most of i18n functionality already exists with PEARs I18Nv2 package, so I'd love to see this thing tightly integrated into Smarty (without doing my own 10.000 modifications to get it running). I18N in Smarty could become as easy as setting a certain locale (like "de_DE" in my case) in Smarty's base class and all modifiers (like date_format) would automagically use for example the correct official dateformat string (if no other is supplied).

Another thing which would be nice is to have multiple places where config files can be located, currently only one directory is allowed. Thus I need to place general config files into my i18n directory where the language config files reside, which, on the other hand, breaks with my cvs devel setup where translators only get write access to the i18n directory...

The {html_options} function is also lacking on I18N support, since its values need to be filled in by a PHP script. This is not a matter for content which comes from DB (which is most likely translated or provided as-is), but for select boxes with fixed/ static contents (like a search dropdown box which contains several search options).
I could - of course - put normal "<option ..>" tags in my code for that purpose, but for a reasonable amount of options this clutters the template file a lot. Also, I'd need to apply custom logic for (pre-)selected elements.

Thats all, keep up the good work!
Tommy.
_________________
Administrator / Developer on http://www.musicmademe.com
- http://thomaskeller.biz
Back to top
View user's profile Send private message
Swatinem
Smarty Rookie


Joined: 26 Jan 2005
Posts: 12

PostPosted: Wed Aug 10, 2005 8:39 pm    Post subject: Reply with quote

I18N would definitely be a good feature.
I use a modified version of John Coggeshalls IntSmarty. I like the way it works and it is also integrated with php so you can provide translated variable contents to smarty.
And the fact that it works as prefilter also makes it easy to localize Time Output.
A built-in I18N support in smarty which works easy enough would be extremely cool so the developers dont need to bother with that themselves.
Back to top
View user's profile Send private message
khan2265
Smarty Rookie


Joined: 07 May 2004
Posts: 21

PostPosted: Mon Aug 15, 2005 8:36 pm    Post subject: Reply with quote

please just make it compat with php 5.1
and release it when 5.1 production comes out.

5.0 has way too many problems, especially with damn sOAP
Back to top
View user's profile Send private message
swapo
Smarty Regular


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

PostPosted: Tue Aug 16, 2005 9:49 pm    Post subject: Reply with quote

Though I didn't spend much time here on the forum or the newsgroup I thought a lot about template engines in general and specially about smarty the last time.

There's a often used cite that I really like - it's something like: "Every template engine evolves until it is PHP".
That's so true. And even if Smarty is not on his way to become PHP, I'd say it has too much functionality which make it fat and often causes ugly templates which contain already too much logic.

As I (and others) said before, I'd like Smarty to get away from it's monolithic design. Okay, that's a nice point and I still agree with that. But I'm currently wondering if that's really enough.
Within this discussion I see people asking to implement a lot of basic features. I don't want to say, that this features (like i18n) are useless. But I don't think that this is basic functionality of a template engine.

If anybody asked me today, I'd say that Smarty should get as slim as possible - containing only features that are really necessary for the engine. To keep Smarty an all purpose solution, there should be a real powerful API that allows you to flexible design plugins that provide exactly the features you want from your template engine of choice.
In addition I have a vision of "CESAR" (Contributions Extending Smarty At Requirement) a central archieve of smarty plugins. You could differentiate official plugins, high quality contributions (tested by a QA-Comitee) and normal contributions (not tested yet or found not to meet the required quality).



Another point I'd like to start that has nothing to do with the stuff above is backward compatibilty. Is this necessary? Isn't their much stuff in the template syntax that perhaps could better be completely redesigned (apart from the functionality overhead)?
I'm not quiet sure about this, but there are some points that you should think about.

One thing is XML-Compatibility: Although Smarty can be used to create valid XML it can't be used within XML-Files. If Smarty had a XML-Tag-Style syntax you could write valid XML-Files which also represent Smarty Templates. Using custom namespaces would solve a lot of general problems.

E.g.
Code:
<?xml version="1.0"?>
<html>
<head>
   <title>Smarty example</title>
   <smarty:include file="headinclude.tpl" />
</head>
<body>
   <smarty:loop from="$iterator" as="item">
   <p>
      <smarty:display var="item" />
   </p>
   </smarty:loop>
</body>
</html>


Of course there's not much left from the old syntax style but i see a lot of advantages. Addiotionally i don't see too much problems in breaking the style because I don't believe in a 100% compatibility (neither nearly).
I also don't see that it's necessary to switch a running project directly from 2.x to 3.x.
And if it should really be necessary, the new designed API should give the ability to write a Smarty2-to-Smarty3 live converter. That'd be more flexible and i bet the possible grade of compatibility would be much higher.


Okay, that's enough stuff for now.

David
Back to top
View user's profile Send private message
Swatinem
Smarty Rookie


Joined: 26 Jan 2005
Posts: 12

PostPosted: Tue Aug 16, 2005 11:52 pm    Post subject: Reply with quote

I thought such xml style could be achieved with left/right delimiter but on a closer look its not.
xml style syntax would indeed be interesting but it seems to be harder to implement than these simple delimiters. And hardcoding a xml style syntax would be a bit of bloat too.

Designing Smarty3 from ground up to be as slim and FAST as possible is definetely the way to go IMHO.
Back to top
View user's profile Send private message
boots
Administrator


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

PostPosted: Wed Aug 17, 2005 12:09 am    Post subject: Reply with quote

Hi Swapo.

I was wondering if you have more definitive goals? IMO, it is just as easy to say Smarty should do less as it is to say it should do more. On-the-other-hand, more concrete ideas of how to go about making it one or the other are needed. I tend to agree that Smarty needs to lose some of the monolithic design -- the question, really, is how to do that while maintaining runtime performance? In other words, what level of granularity is appropriate (where do we need re-use and re-factor points) and what will be the best way to both rapidly and easily create composites that do the runtime work?

For a long time I've seen Smarty as more than just a template engine -- for me it is an "output processor". I realize that doesn't say much more but at least it admits that there is more to what it is aiming for than just variable interpolation and it gets us away from that somewhat inane comment that Rasmus once said and which has become fashionable to repeat. Hell, we don't even have to think of Smarty as a template engine or "output processor" or framework or any friendly name we can think of. It is just a bunch of PHP classes, like any other. Like other classes, what it achieves can also be done with pure PHP (it is PHP!) but in collecting appropriate behaviours and strategies together in a convenient mecahnism, development is simplified. Sure, as part of that it implements another syntax but what's wrong with that? Does anyone complain that CSS is not an XML language? Or that Javascript != PHP? Or that PHP != Java? (oh wait...)

As for an XML dialect of Smarty, I'm sure that someone will do one because there is interest in such a thing. I just don't think I see the point. Who cares if it can't be used within XML-Files? It isn't meant for that -- it is meant to produce XML files. When I see things like, <smarty:display var="item" />, I want to shake my head. XML is intended as a format neutral way of describing data. It is completly horrid at representing intentional behaviours. It is one thing to XMLize data (creating a data language), it is quite another to XMLize process (which IMO creates a mess).

When it comes to BC, I mostly agree with you on that one Smile It is important, but it is not like the 2.x branch is going away anytime soon. There is an opportunity to redo Smarty in the 3.x branch, using lessons learned from past mistakes and leveraging newly available language features and techniques. I think we should.

I also agree that a standard peer-reviewed repository of extensions would be a nice addition. It would be nice if Smarty was bundled with nothing and that there existed after that repositories or bundles of collected functionality which was installable in a standard way. MMM.
Back to top
View user's profile Send private message
swapo
Smarty Regular


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

PostPosted: Wed Aug 17, 2005 1:30 am    Post subject: Reply with quote

XML is an open standard and not specific for only one purpose. This gives you a lot of new possibilites for example in designing and editing templates using any XML parser you like. And there's a hole lot of different parsers - not at least native within php. And defining a specific DTD allows to check validity - not just within Smarty.
Of course XML is mainly designed to structurize data - but I really believe that this doesn't have all - and there are already similar examples in the java world.

You asked if I'm complaining about the different existing languages. No. I'm definitily not. But, to be honest, I think this is like comparing apples and pears. Though I like Smarty, it's far away from beeing this kind of standard.
But in a way that's another reason for XML.

However, i'm still more in the position of collecting and presenting ideas. I don't have any definitive goals (and I don't feel like beeing in the position to define goals).
I'm currently presenting my ideas to give you guys something to think about (Wink) and to get some feedback which could improve my ideas (which I still like very much).
I also have some problems with preparing too detailed suggestions at the moment when I have no idea what could be a way accepted by a majority. If I'll find out that, it's time to get more specific.


One last thing: I did not want to say that smarty shouldn't be able to do all the things It's able to do. But it should not be the standard - I've seen a lot of Smarty templates now and I often think: "damn, that's business logic. this template sucks".
If someone likes to have the ability to do everything within a template without he should directly use PHP-includes (may be using a wrapper class) what is faster, more solid and even much more flexible.



Woah, I'm sorry. I think my english is getting worse. It's 03:30 AM here and I'm really tired.

Good night says David Wink
Back to top
View user's profile Send private message
saerdna
Smarty Rookie


Joined: 12 Dec 2004
Posts: 20
Location: Linköping, Sweden

PostPosted: Mon Sep 19, 2005 2:18 pm    Post subject: Reply with quote

one idea that came up, nothing special really but anyway.

if features are going to be modules it would be nice if you make a interface for modules.

public interface SmartyModule
{
/* abstract methods here */

}

so there will be some kind of standard in the modules

public class myModule implements SmartyModule { ... }


Last edited by saerdna on Mon Sep 19, 2005 5:58 pm; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website
boots
Administrator


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

PostPosted: Mon Sep 19, 2005 4:32 pm    Post subject: Reply with quote

saerdna wrote:
as many already stated smarty, im only looking forward for optimization.


Optimization of what? Development process, flexibility, speed? At what trade-offs? Personally, I would like more flexibility with a streamlined process that relied more on PHP5 features rather than a to-the-metal implementation. I would also rather that the compiled files either had an intermediate meta-data stage or otherwise compiled to a more flexible container rather than straight PHP4-like code.

saerdna wrote:
if features are going to be modules it would be nice if you make a interface for modules.

public interface SmartyModule
{
/* abstract methods here */

}

so there will be some kind of standard in the modules

public class myModule implements SmartyModule { ... }


I completely agree. I'm in favour of scrapping all of the current plugin methods for a class based system. That way we get autoloading for free and we can still fallback to functions by creating a special autoloader that automatically wraps function calls in a specially named static class (which would effectively act as a fixed namespace in Smarty). This is the direction I have been exploring in my SmartyDoc addon and I am finding it to be rather flexible.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Smarty Forum Index -> Smarty Development All times are GMT
Goto page Previous  1, 2, 3, 4 ... 10, 11, 12  Next
Page 3 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