Closed gingerlime closed 12 years ago
I think it's awesome that you did this. Few quick thoughts:
Why Rootache instead of Rootstache? :)
I completely agree that the lack of separation between presentation and logic in WordPress (default, other themes, and Roots) is its biggest flaw so I'm all for any attempt to fix that. And I'm also a big fan of Mustache since I firmly believe that the only sure fire way to keep logic out of templates is to use a logic-less templating language.
Although I'm wondering if it's too much of a radical departure. Using something like Twig (http://twig.sensiolabs.org/) for templates might be a better idea.
Regardless, Roots would work with Mustache but the main problem with this implementation is mostly the structure. This was already a problem in Roots but it's exacerbated by introducing a templates folder. Mustache.php, MustacheLoader.php, and Rootache.php don't belong in the root folder along with all the other php files. There should be a "lib" dir for these. In fact, all the existing PHP "templates" which are now basically context files, should be in their own separate directory. Maybe this could be called "views" or "contexts".
Roots is well organized and decently documented but we all know it doesn't have the best OOP practices :) which limits how we can actually structure all these files. So I don't expect you to re-write Roots but finding a better structure for implementing Mustache would go a long way towards adoption.
But like I said, this is awesome and I think it's only going to lead to good things.
Thanks for the quick feedback and good ideas.
I deliberated for a while between Rootache, Rootstache, Rustache and others... I imagine this will change at some point. Good observations about /lib /views and /contexts too. I imagine the php files have to live in the home folder for the theme for compatibility though? Doesn't the wordpress framework look for files like archive.php etc in there?
In any case, I'll try to shuffle stuff around and give it a better structure.
Re: twig. Yep, I've had a quick look at that too, but it just reminded me too much of django templates. Working with django regularly, I noticed that in many projects there's a fair degree of application-logic-creep into the templates. At the same time, this kind of template language always seems to be missing some functionality when you're looking for it. So in my mind this class of template languages, this "middle-ground", gets the worst of both worlds. You end up with application logic in your templates, but use a second-grade language for doing app logic.
I therefore think it's better to either have a fully capable language (like php, and I believe erb), or a completely minimalist approach, like Mustache.
Anyway, there's a potential for a whole discussion that can spiral from this, but hope we can stay focused on Roots and Mustache happily living together.
p.s. just moved stuff to lib folder as you suggested. Thanks again for that.
https://github.com/welaika/wordless is a good example of getting around the "template" php files in root. That theme has a lot of cool ideas but just goes a bit too far in my opinion.
Here's their "router" (index.php): https://github.com/welaika/wordless/blob/master/wordless/theme_builder/vanilla_theme/index.php
Thanks @swalkinshaw . Wordlress seems like a very interesting find indeed. Requiring ruby and completely departing from the wordpress structure does seem a little too far to me too. haml is also interesting, and perhaps it can also be added to the mix later on. Didn't quite occur to me before. I'd rather feel more solid about having simple mustached-html-templates within the theme first, and then think about other extensions.
As far as the Wordless routing specifically, it doesn't seem to use any of the existing wordpress template hierarchy. Perhaps it's a benefit, because the wordpress hierarchy can be confusing and requires getting used-to. But that being said, it is quite flexible and re-inventing it sounds a little risky to me.
Going back to your point about moving the standard .php files from the root folder, I'd say that whilst I like this idea, leaving them there is a reasonable price to pay. You get the benefit of instant familiarity for people already using wordpress. The Mustache templates in Ginger-Roots stick to the same structure too, with each .mustache file providing template for its .php counterpart.
I actually agree about the dreaded "middle-ground" for templating languages. Haml actually fits into this category too since you can execute any code you want in it. My only concern with moving to Mustache is that it's a huge change for Roots and a lot of WordPress users/developers aren't exactly used to things like logic-less templates.
I like that each PHP file has a Mustache counterpart which is one of the reason why I think it would be good to have parallel folders for them so that they're match up even more so. I'll put some more thought into this since I haven't really considered a solution beyond what Wordless does.
just to clarify my comment about "adding haml to the mix". I thought about having a haml+mustache hybrid-templates. Providing extra brevity without any logic. i.e. the template will get rendered by mustache first, then haml, or vice versa. (haven't used haml before, so not sure how feasible this is though). In any case, it feels too early to consider this right now.
Would love to get more ideas from you and others. I do realise Ginger Roots suggests a rather big shift, adding in Mustache templates. I hope it's a positive shift however.
That's definitely possible. Just need to render Mustache first since it's basically text agnostic (http://ozmm.org/posts/haml___mustache.html). Of course then we'd be adding two levels of additional rendering which has performance impacts but people should be caching WP anyway...
Few more thoughts:
ob_start();
wp_head();
$context->wp_head = ob_get_clean();
This pattern is used a lot. It would be good to abstract it out into a function although it might be messy with PHP since we shouldn't require PHP 5.3 yet with WordPress (don't have true anonymous functions).
I don't think $context should be a global variable that's just an instance of Rootache. Might as well just use Rootache as a singleton or access it with static methods if it's only being instantiated once.
Check out this Rails 3 gem for using Mustache: https://github.com/goodmike/mustache_rails3
Basically, a ruby "view" file is equivalent to a php template file. Each PHP file would subclass Rootache (or Mustache::Roots if we're being really literal). Then on rendering it would instantiate that subclass and render out the corresponding Mustache template.
Just some more ideas I had.
Thanks again @swalkinshaw. All very good comments.
Re ob_start()...
stuff - would be VERY happy to find a nicer way. I also felt it's ugly and repetitive (non-DRY?), but at the same time, doing things like get_buffer('function_name', 'argument1', 'argument2')
and using call_user_func
isn't much cleaner. PHP 5.2 support was also a consideration. I wish I didn't have to use output buffering at all, but some functions just don't have the get_ method at all and always echo stuff out... lots of wordpress is built around echoing (things like get_template_part
, get_header
, get_footer
and many others).
As far as the global access to Rootache. Another good observation. This evolved gradually, but perhaps is not yet fully evolved. I started with each php file instantiating its own Rootache context. But then came across things like wp_list_comments('type=comment&callback=roots_comments');
. This function gets a string with a callback function for each comment. I wanted to make the callback function add stuff to the existing context. That's where the global context started. As far as making Rootache a singleton - perhaps, but I don't see the big risk with leaving it as is. There's nothing wrong with instantiating your 'own' Rootache if you want. It might be slower or less memory efficient, but perhaps some cases would require a completely independent context, unaffected by the (currently) global one... Since wordpress isn't very object oriented and uses lots of globals and functions, I didn't particularly want to make Rootache a class/object instance either. However, since Mustache.php uses classes, it was just easier to sub-class it. Hope I explained this clearly.
@swalkinshaw I've added you as a contributor. (Hope that's the right way to allow you to push code/changes? still quite new to github...)
@gingerlime it is, thanks!
I should have known WordPress wouldn't let us have nice things. I'm just glad you've put some thought into these issues as you came across them. Obviously you know the problems better than I do. I'm not sure when I'll have time to work on this but it's gotten me interested.
@gingerlime not sure if you've seen this, but it was linked in the rebuild issue: https://github.com/newsapps/wordpress-mtv
Tutorial: http://blog.apps.chicagotribune.com/2011/10/19/turning-wordpress-into-a-framework-with-mtv/ Wiki: https://github.com/newsapps/wordpress-mtv/wiki
Some interesting ideas there with some parallels to your fork.
Thanks @swalkinshaw ! Very interesting find. How do you hear about all those things?? Sorry I've been distracted by other stuff recently, so haven't had much time to focus on roots / ginger roots. Thanks for keeping me posted.
I'm mostly dealing with django day-to-day so it feels like familiar territory. Nevertheless, it seems a little awkward to say the least (what were they thinking with those backslashes??!!). The urls.py (erm... urls.php) implementation looks interesting and one of the things I do like in Django. Kudos to those guys for this. I wonder if we can borrow/steal some ideas for roots from it. Also interesting to see how they separated the templates. The choice of twig seems very logical because it's very similar to django templates. I personally find it lacking (we've already discussed this murky middle-grounds some time ago).
Looks like it's interesting time for Wordpress, and there's definitely a breath of fresh air and some really interesting ideas coming from different directions.
Well someone else found that but I'm always reading and clicking links :)
I agree that some of their implementation is awkward and kind of insane the lengths they go to to bypass WordPress. but Interesting nonetheless.
I got to say i have just spent the last 40 mins reading this article and was very impressed with all of it, and the comment pros and cons.
With the developers projects i think sometimes that have to see the userbase of it make it too complex small but well developed projects can be chucked away at the roadside.
I am not a programmer more of an general ICT operator so i can service your printer, design system flows and network your bathroom and put a working server in it and maintain with a website on the back and then have it integrate with other systems via structured design and a bit of the coding .. but i can manage it all ...
i am still learning web, and languages all the time ... and i think the main thing that interests me is will it help stream workflow and i can keep learning a core product thus learn more about it the more i use it and understand and develop it further
the problem is i have used so many systems to try and find the hat that fits ... i spend so much time not getting to grips and wanting to use it more and more.
i came across boilerplate and saw this was a structure, i used wordpress and joomla but never really thought the development time outweighed the hand code time in xhtml and php and some jquery / ajax stuff ..
i am know at the time where i am looking to spend more time web developing not big project small to medium companies where there isnt going to big budgets etc but looking at making a small bit of money over many projects hence a framework like this seem to be a good choice
i do like the idea of structure / presentation / logic separation but again for non full time developers or trained professional it becomes a full time job just learning .. when i need to be earning .. i did like the look of mustache it did seem an accessible control system ... most people understand variable injection, loops, counters etc or can quickly
i am all for what ever both roots and gingersroots brings and the ver 6 of roots i am sure will be well anticipated and alot of features.
I wait with anticipation for new findings and readings and to see how these projects go forward
just my 10 pence worth !! :)
I mentioned this briefly on #209, but I thought I should try to spread the word around, see if anybody's interested in this direction.
Roots is a great theme, and it immediately felt good to use. It introduced some very neat changes to the way things are done with Wordpress, most of which I had similar thoughts about.
However, regardless of how amazing any theme is, and how organized the php code might be, when it comes to the presentation layer itself - the templates that get displayed to the user, I always felt PHP is just too messy. Mixing presentation and logic was always a little annoying (escaping characters inside echo etc). So when I bumped into {{Mustache}} a few months ago, I really wished there was a wordpress theme using Mustache. Then when I figured out there isn't any, I decided I should try to build one myself. Or adapt an existing theme.
The end result is Ginger Roots - a roots fork with Mustache support. All templates can be edited using a .mustache file. Would be great if this is adopted and becomes part of Roots, but I realise not everyone would immediately jump on the idea. I would appreciate any feedback or suggestions regardless. It is still very fresh and probably has lots of bugs, but at least it's at a point where all base .php templates were converted and have a .mustache counterpart.
Cheers Yoav
p.s. just a quick thank-you to creators of Roots and to the fantastic help I got from @bobthecow on the Mustache.php project.