[2.0] Smarty3
Re: [2.0] Smarty3
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.
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.
My blog: Refining Linux
Re: [2.0] Smarty3
Which plugins do you have in mind?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.
I do know some of our plugins, which are fully smartified and can be customized as much as wanted.
Please specify.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.
Again. Which Plugin is the one in real need?
All plugins being smartified do provide some sort of "block" template output. They normally can't exist without the template enviroment.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.
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
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: [2.0] Smarty3
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.
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.
My blog: Refining Linux
Re: [2.0] Smarty3
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?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.
![Confused :?](./images/smilies/icon_confused.gif)
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
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: [2.0] Smarty3
I'm talking about templates in general and plugins in particular. ![Wink ;-)](./images/smilies/icon_wink.gif)
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?
![Wink ;-)](./images/smilies/icon_wink.gif)
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?
My blog: Refining Linux
Re: [2.0] Smarty3
Yes, I already got thatManko10 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.
![Wink ;-)](./images/smilies/icon_wink.gif)
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: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.
No, as far as I know, there isn't.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?
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
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: [2.0] Smarty3
Yep, that's both a blessing and curse.this is a long term goal, since breaking compatibility is not a very own speciallity of Serendipity
![Smile :-)](./images/smilies/icon_smile.gif)
That would be a great idea.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...!
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.
My blog: Refining Linux
Re: [2.0] Smarty3
Yes sure!
Every Plugin has this section:
If you say , or ,
for example this would do the switch for you, easily!![Wink :wink:](./images/smilies/icon_wink.gif)
Every Plugin has this section:
Code: Select all
$propbag->add('requirements', array(
'serendipity' => '0.7',
'smarty' => '2.6.7',
'php' => '5.0.0'
));
Code: Select all
serendipity' => '1.7'
Code: Select all
smarty' => '3.2'
for example this would do the switch for you, easily!
![Wink :wink:](./images/smilies/icon_wink.gif)
Regards,
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: [2.0] Smarty3
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.
Having all the plugins inside the Git repository would be handy. But as you mentioned, Garvin might take care of this.
My blog: Refining Linux
Re: [2.0] Smarty3
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
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
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: [2.0] Smarty3
Have you already linked or given an example of such a block?
Re: [2.0] Smarty3
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...![Wink ;-)](./images/smilies/icon_wink.gif)
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...
![Wink ;-)](./images/smilies/icon_wink.gif)
Regards,
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Re: [2.0] Smarty3
.. .. ..
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 :wink:](./images/smilies/icon_wink.gif)
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 :wink:](./images/smilies/icon_wink.gif)
Regards,
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
-
- Core Developer
- Posts: 30022
- Joined: Tue Sep 16, 2003 9:45 pm
- Location: Cologne, Germany
- Contact:
Re: [2.0] Smarty3
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?![Smile :)](./images/smilies/icon_smile.gif)
Thanks for your efforts,
Garvin
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?
![Smile :)](./images/smilies/icon_smile.gif)
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/
# 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/
Re: [2.0] Smarty3
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: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.
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: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.
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...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?
![Wink :wink:](./images/smilies/icon_wink.gif)
Regards,
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian
Ian
Serendipity Styx Edition and additional_plugins @ https://ophian.github.io/ @ https://github.com/ophian