[2.0] Smarty3

Mark threads with "[2.0]" for discussions about features in the longer-term future, "[1.6]" is for short-term. This is not the place for general discussions or plugin or template requests. Only features that are approved to happen by the core team should be listed here for better structuring.
User avatar
Manko10
Regular
Posts: 50
Joined: Sun Dec 26, 2010 5:58 pm

Re: [2.0] Smarty3

Post by Manko10 » Sun Nov 27, 2011 3:17 am

Is there any chance to make Smarty3 block syntax a code design guideline?
Currently all the plugins drop in some hardcoded XHTML stuff, which often is garbage and interferes with the overall HTML of the template, especially when you're not using XHTML syntax or need some more serious customization of a plugin's output.
Some plugins provide Smarty variables, but turning them on requires to re-implement all the plugin's output, which is also quite redundant and might cause problems when the plugin's updated.

Using Smarty's block syntax and deprecating hardcoded output would make things much more flexible and maintainable. Template authors get much more control over the HTML code which makes it easier for them to create consistent templates and it is also more update-safe since they can selectively override specific parts whereas all the other stuff stays as is.

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smarty3

Post by Timbalu » Sun Nov 27, 2011 11:30 am

Manko10 wrote:Currently all the plugins drop in some hardcoded XHTML stuff, which often is garbage and interferes with the overall HTML of the template, especially when you're not using XHTML syntax or need some more serious customization of a plugin's output.
Which plugins do you have in mind?
I do know some of our plugins, which are fully smartified and can be customized as much as wanted.
Manko10 wrote:Some plugins provide Smarty variables, but turning them on requires to re-implement all the plugin's output, which is also quite redundant and might cause problems when the plugin's updated.
Please specify.
Again. Which Plugin is the one in real need?
Manko10 wrote:Using Smarty's block syntax and deprecating hardcoded output would make things much more flexible and maintainable. Template authors get much more control over the HTML code which makes it easier for them to create consistent templates and it is also more update-safe since they can selectively override specific parts whereas all the other stuff stays as is.
All plugins being smartified do provide some sort of "block" template output. They normally can't exist without the template enviroment.
To use Smarty3 new Template Inheritance with block childs and parents, you need to redesign the the blog and main template design first to make plugins output hook into.

This might be a very long time goal, I presume!
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Manko10
Regular
Posts: 50
Joined: Sun Dec 26, 2010 5:58 pm

Re: [2.0] Smarty3

Post by Manko10 » Sun Nov 27, 2011 1:53 pm

There are many plugins. One example would be the twitter plugin which throws some links and one-pixel graphics into the code. I often have to make changes to the plugin because it's output is not really compatible with my template. Of course, those changes are all gone after the next update. Very annoying.
Also plugins such as freetag, metadesc, xmlrpc and many more use a lot of hardcoded HTML.
And even smartified plugins are not very ideal since you always have to override the whole template. If a plugin is updated and some new stuff is added to the template, it won't appear since the override template had to be updated as well. By overriding just a specific block instead of the whole template, you only need to override what you really need to change. That makes the whole thing much more update safe.

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smarty3

Post by Timbalu » Sun Nov 27, 2011 4:13 pm

Manko10 wrote:And even smartified plugins are not very ideal since you always have to override the whole template. If a plugin is updated and some new stuff is added to the template, it won't appear since the override template had to be updated as well. By overriding just a specific block instead of the whole template, you only need to override what you really need to change. That makes the whole thing much more update safe.
To be precise... you are not talking about the Serendipty template, you are talking about a specific plugin template file, which is commonly one or more nested blocks inside the template you are using. Now, as I understand your remarks, you want plugins to cut their advanced template files into smaller block pieces, right?

:?

If you have any experience about better coded template blocks, why don't you spend your knowledge with the plugin author to save this for all?
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Manko10
Regular
Posts: 50
Joined: Sun Dec 26, 2010 5:58 pm

Re: [2.0] Smarty3

Post by Manko10 » Sun Nov 27, 2011 6:35 pm

I'm talking about templates in general and plugins in particular. ;-)
I'd like to remove all inline HTML out of any plugins or s9y core functions so that there's no hardcoded HTML anywhere. Additionally I'd like to improve the flexibility of the templates by using Smarty blocks which are available in Smarty 3.
I guess, one reason why many plugin authors use inline HTML is that they don't want to create tons of different template files and indeed, templates with just one line of code can get very cumbersome. However, with Smarty blocks, you could use just one template file and split all your single lines into blocks.

And of course I'd also help to implement this as much as my timetable allows, but currently I'm not so informed about what's going on and where. I know, there's a Smarty3 branch on GitHub and I know that the plugins are on SourceForge.
This is all very fragmented and I'm not quite sure where to begin. The problem is I can't just grab any plugin and make it use Smarty blocks. Doing so would render it incompatible with current s9y versions which use Smarty2. So is there any specific testing branch for future plugin versions or so?

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smarty3

Post by Timbalu » Sun Nov 27, 2011 7:02 pm

Manko10 wrote:I'd like to remove all inline HTML out of any plugins or s9y core functions so that there's no hardcoded HTML anywhere. Additionally I'd like to improve the flexibility of the templates by using Smarty blocks which are available in Smarty 3.
Yes, I already got that ;-) But as you know and already mentioned yourself, this is a long term goal, since breaking compatibility is not a very own speciallity of Serendipity, .... to say it it this way!
Manko10 wrote:I guess, one reason why many plugin authors use inline HTML is that they don't want to create tons of different template files and indeed, templates with just one line of code can get very cumbersome. However, with Smarty blocks, you could use just one template file and split all your single lines into blocks.
Beside of performance questions.... maybe...! They may not always know the needs of using it differently, thats why I told you to get in contact. I totally agree; using these new features is something very good to have soon. To migrate smooth, we need some fancy ideas, on how to use new methods with old installations a while, until a certain point of no return, for sure.
Manko10 wrote:This is all very fragmented and I'm not quite sure where to begin. The problem is I can't just grab any plugin and make it use Smarty blocks. Doing so would render it incompatible with current s9y versions which use Smarty2. So is there any specific testing branch for future plugin versions or so?
No, as far as I know, there isn't.
Why not? Garvin said he will think about migrating additional plugins to github too, if people wish him to do. Maybe we could use this switch to have smarty3fied Plugin templates hosted on github, let Spartacus decide who is ordering and live with that switch beween SF and GIT a while, before we shut down the first...!
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Manko10
Regular
Posts: 50
Joined: Sun Dec 26, 2010 5:58 pm

Re: [2.0] Smarty3

Post by Manko10 » Sun Nov 27, 2011 7:36 pm

this is a long term goal, since breaking compatibility is not a very own speciallity of Serendipity
Yep, that's both a blessing and curse. :-)
Why not? Garvin said he will think about migrating additional plugins to github too, if people wish him to do. Maybe we could use this switch to have smarty3fied Plugin templates hosted on github, let Spartacus decide who is ordering and live with that switch beween SF and GIT a while, before we shut down the first...!
That would be a great idea.
Besides that: is there any mechanism to specify plugin compatiblity? It would be easier to do things like this when I could tell Spartacus that this plugin is only compatible with s9y starting at version X.

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smarty3

Post by Timbalu » Sun Nov 27, 2011 7:43 pm

Yes sure!

Every Plugin has this section:

Code: Select all

        $propbag->add('requirements', array(
                        'serendipity' => '0.7',
                        'smarty'      => '2.6.7',
                        'php'         => '5.0.0'
                    ));
If you say

Code: Select all

serendipity' => '1.7'
, or

Code: Select all

smarty'      => '3.2'
,
for example this would do the switch for you, easily! :wink:
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Manko10
Regular
Posts: 50
Joined: Sun Dec 26, 2010 5:58 pm

Re: [2.0] Smarty3

Post by Manko10 » Sun Nov 27, 2011 8:04 pm

Okay. The problem remaining is how we can maintain two parallel versions.
Having all the plugins inside the Git repository would be handy. But as you mentioned, Garvin might take care of this.

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smarty3

Post by Timbalu » Mon Nov 28, 2011 2:55 pm

Just to add this, ... and maybe Garvin hooks in...

Using these Smarty3 blocks overall would allow us to use smarty enhanced caching in future, which could be something very useful!

Rodney wrote
You want to specify the pieces of cachable content yourself. Go with a structure like
post-123
post-123|comments (if you have a page for all comments belonging to that post)
post-123|comments|feed (if you have a comment feed for a certain post)
now you can clearCache('post-123') and comments and comments|feed are killed as well.
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
onli
Regular
Posts: 2230
Joined: Tue Sep 09, 2008 10:04 pm
Contact:

Re: [2.0] Smarty3

Post by onli » Tue Nov 29, 2011 5:17 pm

Have you already linked or given an example of such a block?

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smarty3

Post by Timbalu » Tue Nov 29, 2011 7:15 pm

No, I haven't...
http://www.smarty.net/docs/en/advanced. ... itance.tpl
http://www.smarty.net/docs/en/language. ... .block.tpl
We could even start with {nocache} ... {/nocache} blocks, I think.

How this can be structered in Serendipity - does need someone real structered to find out... ;-)
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smarty3

Post by Timbalu » Wed Nov 30, 2011 10:54 am

.. .. ..
New syntax, new features and get rid of outdated customs and practices.

As we started to use smarty3 in the GIT master trunk, I am thinking we also should change all core delivered tpl files (yes also all templates, or drop them from core) to the new Smarty3 syntax like loops (see http://www.smarty.net/docs/en/language. ... oreach.tpl), dropping {$array|@mod} syntax @, ajust assign syntax in templates, or even change the old $CONST to $smarty.const calls. And there is even more....
http://smarty-php.googlecode.com/svn/tr ... ion/README (read from section WHAT IS NEW IN SMARTY TEMPLATE SYNTAX), followed by SMARTY_3.1_Notes.txt and possible future SMARTY_3.2_Notes.txt

Please tell me to start this project or to stop at certain points, Garvin.

If there is a general GO for this, I definitely need some help! :wink:
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

User avatar
garvinhicking
Core Developer
Posts: 30014
Joined: Tue Sep 16, 2003 9:45 pm
Location: Cologne, Germany
Contact:

Re: [2.0] Smarty3

Post by garvinhicking » Wed Nov 30, 2011 1:27 pm

Hi!

I think the new notation for foreach is not useful for us; the old one is easier to read for non-coders, and has the advantage to use variable variable names easily.

Dropping "@" syntax sounds good to me; I'm undecided on using $smarty.const instead of CONST. I like that it's ALL CAPS, and dislike that $smarty.const. does not easily read like a constant to the eye.

I have personally not looked into this "block" syntax, so feel free to elaborate on that or share general ideas on how to imnplement? :)

Thanks for your efforts,
Garvin
# Garvin Hicking (s9y Developer)
# Did I help you? Consider making me happy: http://wishes.garv.in/
# or use my PayPal account "paypal {at} supergarv (dot) de"
# My "other" hobby: http://flickr.garv.in/

User avatar
Timbalu
Regular
Posts: 4598
Joined: Sun May 02, 2004 3:04 pm

Re: [2.0] Smarty3

Post by Timbalu » Wed Nov 30, 2011 2:15 pm

garvinhicking wrote:I think the new notation for foreach is not useful for us; the old one is easier to read for non-coders, and has the advantage to use variable variable names easily.
Yes, but how long will it be supported into future? The question is, if it wouldn't be better to use the switch now to start "from scratch". It is the now officially supported smarty notation, apart from getting closer to PHP (which would be easier to drop in for DEVs knowing PHP, but not SMARTY) ... why shouldn't we follow as is? And as I said, there is more....!
garvinhicking wrote:Dropping "@" syntax sounds good to me; I'm undecided on using $smarty.const instead of CONST. I like that it's ALL CAPS, and dislike that $smarty.const. does not easily read like a constant to the eye.
Start working just to drop '@' does not make real sense to me. I like the shorter ALL CAP constant also, but it is an extra parsing and I am not sure it is in general a good idea to bend notations of third party software. If we could stay clean here, would allow us to broad the base of developers...
garvinhicking wrote:I have personally not looked into this "block" syntax, so feel free to elaborate on that or share general ideas on how to imnplement? :)
This is something not easy to think ... We need someone to know exactly the general function, assign, fetch and template structure in S9y versus the needs of an extanded use of smarty3 caching structure. Sounds to me like a master plan... :wink:
Regards,
Ian

Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian

Locked