Template Engine for Joomla!
975 views
Skip to first unread message
Nils Rückmann
Apr 16, 2013, 8:52:40 PM4/16/13
to joomla-...@googlegroups.com
Hi, first i want to say that i'm not a huge fan of template engines for php and i don't think that we should use an engine for our templates/views (at least not now).
But if we would have a template engine in our core we would have a base for such a future.
Besides the markup, we could use a template engine for a unified syntax for placeholders, which are used in almost every email or in plenty content plugins.
There are a lot of other situation where you don't want to allow php, and especially for third party extensions it would be convenient if we would have a clear path.
PS: I know my discussions are falling out of alignment sometimes. So please, let's stay on topic ;)
My proposed structure of this discussion:
1) Collecting and discussing pro & contra of a template-engine in Joomla
2) Decision if we want a template engine (based on the discussion)
3) Picking an engine or decide to create an own
4) Finding volunteers ( you can count me in ;) )
Regards,
Nils Rückmann
But if we would have a template engine in our core we would have a base for such a future.
Besides the markup, we could use a template engine for a unified syntax for placeholders, which are used in almost every email or in plenty content plugins.
There are a lot of other situation where you don't want to allow php, and especially for third party extensions it would be convenient if we would have a clear path.
PS: I know my discussions are falling out of alignment sometimes. So please, let's stay on topic ;)
My proposed structure of this discussion:
1) Collecting and discussing pro & contra of a template-engine in Joomla
2) Decision if we want a template engine (based on the discussion)
3) Picking an engine or decide to create an own
4) Finding volunteers ( you can count me in ;) )
Regards,
Nils Rückmann
Andrew Eddie
Apr 17, 2013, 1:06:01 AM4/17/13
to joomla-...@googlegroups.com
On Wednesday, 17 April 2013 10:52:40 UTC+10, Nils Rückmann wrote:
Hi, first i want to say that i'm not a huge fan of template engines for php and i don't think that we should use an engine for our templates/views (at least not now).
But if we would have a template engine in our core we would have a base for such a future.
Besides the markup, we could use a template engine for a unified syntax for placeholders, which are used in almost every email or in plenty content plugins.
There are a lot of other situation where you don't want to allow php, and especially for third party extensions it would be convenient if we would have a clear path.
PS: I know my discussions are falling out of alignment sometimes. So please, let's stay on topic ;)
My proposed structure of this discussion:
1) Collecting and discussing pro & contra of a template-engine in Joomla
We do have a templating engine in the CMS already. It's called JView. When it was built it was loosely based on the idea behind phpSavant. That is, that PHP provides a perfectly good templating solution which is easy and efficient. Whether everyone agrees with that is another question. The main disadvantages is that the JView allows for data to be manipulated which is bad, bad, bad (no, you shouldn't be making calls to the database in your layout even if PHP lets you do it).
2) Decision if we want a template engine (based on the discussion)
What you are really asking is do we want a better way to handle "layouts".
3) Picking an engine or decide to create an own
I'd just use Mustache.
4) Finding volunteers ( you can count me in ;) )
You'll probably find the engines are being distributed via Composer so the CMS will have to work out how to deal with that. That's not a bad thing because it's a precursor to reintegrating the Framework. I've already got code for a MustacheView class - it's fairly trivial. Most of the work is just agreeing on an engine, if that's what you want to do.
As an aside, I use my MustacheView for creating email templates, so you might want to think a little bit outside the box in terms of scope.
Regards,
Andrew Eddie
piotr_cz
Apr 17, 2013, 4:34:26 AM4/17/13
to Joomla! CMS Development
The problem I'm facing every now and then is having shared base for
server-side and client-side templates (I think once webservices are
in, this will get more attention).
Example:
On entry application renders layout server-side on page load.
Since then interaction is handled client-side (api calls -> layout
rendering).
So would be really handy to have layout templates in format that is
easy to pickup both server-side and client-side and possibly as static
files for performance.
In brief evaluation I picked Mustache and Handlebarjs as these are
easy to pick and there are available php processors.
ps: Interesting thing is the heredoc syntax, it looks quite like
mustache:
$layout = <<<HTML
<div>{$item->title}</div>
HTML;
server-side and client-side templates (I think once webservices are
in, this will get more attention).
Example:
On entry application renders layout server-side on page load.
Since then interaction is handled client-side (api calls -> layout
rendering).
So would be really handy to have layout templates in format that is
easy to pickup both server-side and client-side and possibly as static
files for performance.
In brief evaluation I picked Mustache and Handlebarjs as these are
easy to pick and there are available php processors.
ps: Interesting thing is the heredoc syntax, it looks quite like
mustache:
$layout = <<<HTML
<div>{$item->title}</div>
HTML;
Donald Gilbert
Apr 17, 2013, 2:32:24 PM4/17/13
to joomla-...@googlegroups.com
I really like the Dust templating engine (http://cretz.github.io/dust-php/). It has hints of Mustache and Twig.
One of my favorite things about it is the various types of $context it is able to interpret. You can pass it an array, a simple stdClass object, JSON object, or a class with methods. On top of that, it was first written as a JS templating language, and then ported to PHP, so it was built with client side rendering in mind. It would be easy to make the same layout markup work with both a web-services approach as well as with server-side rendering. I know the other templating engines do similar things, but Dust is the new kid on the block written by the Linkedin Team.
So, to answer your questions:
1) Pro: A template engine in core would serve as an example for extension / app devs to work from, which a lot of people (including myself) need. Con: PHP has pretty good html templating baked in (it IS what is was originally built for, after all)
2) I would say yes. I would like it to be able to use Dust or Mustache out of the box. I would also like it to be SUPER simple to add in more support for more engines, when new & improved versions come out.
3) See #2
4) I'm in.
Donald Gilbert
Apr 17, 2013, 3:06:50 PM4/17/13
to joomla-...@googlegroups.com
Man, Dust is 5.4 only. I looked at it though, and it seems that it's only 5.4 for the short array syntax. I don't see usage of any other 5.4 specific features, so it's probably possible to fix those issues.
Nils Rückmann
Apr 18, 2013, 10:34:03 AM4/18/13
to joomla-...@googlegroups.com
Seems like Michael also wants a template engine for the tracker (https://github.com/joomla/jissues/issues/86).
@Andrew
Mustache is quite nice, especially because of different languages. But i did never get so deep to Mustache.
For example: Are nested loops possible (foreach in foreach) ?
I wouldn't call JView a "template engine" ;) As we donÄt want big changes, i would propose to just add the engine to our libraries. So every developer
can decide if he wants to use the engine or not. After taht we can integrate the engine step by step, like giving JView the ability to use the engine if desired.
Composer shouldn't be a problem, as it allows us to set a custom path for the library. But you're right.It would be a good step to introduce Composer to the CMS.
@Andrew
Mustache is quite nice, especially because of different languages. But i did never get so deep to Mustache.
For example: Are nested loops possible (foreach in foreach) ?
I wouldn't call JView a "template engine" ;) As we donÄt want big changes, i would propose to just add the engine to our libraries. So every developer
can decide if he wants to use the engine or not. After taht we can integrate the engine step by step, like giving JView the ability to use the engine if desired.
Composer shouldn't be a problem, as it allows us to set a custom path for the library. But you're right.It would be a good step to introduce Composer to the CMS.
Michael Babker
Apr 18, 2013, 11:04:55 AM4/18/13
to joomla-...@googlegroups.com
Well, for the tracker, we won't have JDocument available to us to handle rendering, so we need something at a minimum to handle that.
As for JViewHtml (or AbstractHtmlView in the Framework), it's good for finding and pulling in the layouts, but I wouldn't try to tie it into an engine system (notice how our JViewLegacy classes don't use <jdoc> tags but that's left at the template level). Let that be application specific implementation. So, if the CMS wanted to use one, implement it but don't make things difficult like we've been known to do in the past (oh, we want to use this, but we want to make it so that users can rip it out easily and use something else, it really complicates our development sometimes).
--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-cm...@googlegroups.com.
To post to this group, send an email to joomla-...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
Andrew Eddie
Apr 18, 2013, 5:23:31 PM4/18/13
to joomla-...@googlegroups.com
On 19 April 2013 00:34, Nils Rückmann <syb...@gmail.com> wrote:
@Andrew
Mustache is quite nice, especially because of different languages. But i did never get so deep to Mustache.
For example: Are nested loops possible (foreach in foreach) ?
Yes, as long as you structure your data in nested arrays. A Mustache template will actually consume a JRegistry object very well.
I wouldn't call JView a "template engine" ;) As we donÄt want big changes, i would propose to just add the engine to our libraries. So every developer
can decide if he wants to use the engine or not. After taht we can integrate the engine step by step, like giving JView the ability to use the engine if desired.
I wouldn't use JView at all because it still carries so much PHP4 and Joomla 1.5 bloat. The best solution is to see if you can get the template engines to talk together and work out a basic interface (that could one day form a PSR) and then you can use composition to pick your desired engine.
Composer shouldn't be a problem, as it allows us to set a custom path for the library. But you're right.It would be a good step to introduce Composer to the CMS.
Yes. And this is a nice baby step to take in that direction to iron out the issues.
Regards,
Andrew Eddie
Reply all
Reply to author
Forward
0 new messages