template format
There have been a couple people asking about using different template formats. So far ZenMagick uses plain PHP files as templates. There has been a smarty plugin (currently unmaintained) for a long time, but that never took off.
I guess the main issue is that it is all good and well offering support for different templating engines (and it wouldn’t be too hard). However, there is the question of maintaining separate a default theme for each template system.
Anyway, seeing that there is currently some discussion about templating, I think it would be just fair to get some feedback on using a template engine as default.
Candidates could be:
Hi Martin:
Happy Holidays and the best for a new year! I see you are moving rapidly in the development framework for zenmagick. My two cents sense worth on this templating issue is that I have attempted to use smarty in the past for various site packages and it was a royal pain. It had a step learning curve and it was learning yet another complete new language – not something I would like to experience again. Surely there is something out there that is more intuitive that smarty that can help out. As to the PHPTAL – I did a quick look and saw more [i.e. ${php:strlen('"')} “] gibberish. Not good for a non-dev to operate on. Surely there is something more like <?php [stick content HTML stuff here] . Anyway, just my two cents worth.
David
Comment by David — December 14, 2009 @ 10:42 pm
Well, it’s one of those questions bound to come up. It’s good to see some feedback to decide what to do!
I do not mind templating, but then, I am a developer and do not have trouble working around limitations.
For ZenMagick I would personally prefer straight PHP. There is so much that can be done in templates without really breaking the MVC pattern that it doesn’t seem worth it. Since I do not run a store myself it is up to you guys (the users) to decide this.
Anyway, there could always be plugins if anyone really wants to use an engine.
Oh, and the same to you – have a good time. Much snow around your place? We really should buy a BBQ this year
Comment by DerManoMann — December 14, 2009 @ 11:37 pm
I think there is no need to go for the “completely no php”. David is right, most template systems out there tend to make it more difficult than it should be anyhow. The old good html + css mix is good enough I believe.
Comment by Raine — December 15, 2009 @ 7:56 am
have any of you folks looked at haml for ruby? or mustache? I would recommend a look. They aren’t very similiar, but i like things in each. most of the time i just want to be able make saying a bit shorter. It’s hard to pick a good sequence of characters to use as delimiters. I kinda like {{foo}}.
http://defunkt.github.com/mustache/
http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html
I’m not necessarily promoting either one, but i have personally enjoyed working with them.
Comment by johnny — December 20, 2009 @ 7:15 am
oops, looks like it filtered out the php code i put in
it was : phpopentag echo $foo phpclosetag
and to elaborate, i do not want to rely on the short tag feature in php that may or may not be on.
Comment by johnny — December 20, 2009 @ 7:16 am
Yes, something like that would be nice – some time ago I asked about opinions on removing the (optional) echo parameter from a lot of toolbox methods.
Having shorthand that would handle the echo would really help in that case!
Comment by DerManoMann — December 20, 2009 @ 11:01 pm
i do not want to see the <?=$foo?> syntax as we cannot rely that it is turned on.
Comment by johnny — December 21, 2009 @ 10:01 am
@David: The example you’ve given isn’t considered good code in PHPTAL. TAL has its own super-simple expressions, and the complex php:-prefixed ones are only for cases where programmer was lazy and didn’t provide enough information to the template
If you pass objects with appropriate methods (things like option/isSelected) or create custom expressions (e.g. date formatting) then designer doesn’t have to see any bit of PHP ever.
It’s just that PHPTAL doesn’t _force_ that. If you’re lazy and have designer not afraid of some PHP bits, then you can save some time at expense of purity.
Comment by kl — December 21, 2009 @ 3:22 pm
Thanks for clarifying this. I think having appropriate objects/methods is what I try to archive with the toolbox classes. Also, making it easy to add your own and customize existing ones means that by using OO subclassing you can change pretty much everything.
@johnny: When I was talking about shorthand notation I didn’t necessarily mean the php shorthand form, but something like ${product.name} or similar.
I think all those PHP open/close tags are really a pain and make the templates much harder to read.
Comment by DerManoMann — December 21, 2009 @ 11:20 pm