Skip to main content ↑ ↓
Topic: Theme/template class (Read 12013 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Theme/template class

Reply #15 –

Thank ..

Re: Theme/template class

Reply #16 –

Quote from: emanuele – On a somehow related note: recently @gallant mentioned about Twig, we should think about the possibility to give the option to use other template engine "easily". Well, somehow. :P
Twig seems popular these days.. but I'd personally favour Mustache.. It's a logicless template engine and available in various programming languages (PHP, Javascript,, Ruby, Python)..
https://github.com/bobthecow/mustache.php
Thorsten "TE" Eurich
------------------------

Re: Theme/template class

Reply #17 –

I should change Theme::subtemplate($template, $args) to render($template, $args) which aligns it closer to other template engines.

Re: Theme/template class

Reply #18 –

Interested to hear some opinions: could subtemplates ( $context['sub_template'] ) be replaced with layers? The subtemplate is just the inner most layer, right? It just doesn't have _above or _below.

Re: Theme/template class

Reply #19 –

TBH I don't know, layers are a bit of pain to understand and handle properly (just the fact that "after the center" you are forced to think the opposite of what you want to obtain is... counter intuitive. lol

At some point I had two opposite, but somehow similar, ideas about what to do here:
1) a layout manager java-like,
2) a stack of sub-templates.
The first would be something like the way simple portal handles blocks, the second would be similar to layers, but just a "add this sub-template in this place" kind of thing, without any above/below.

The first option could be rather complex to code and to work with, the second could be enough in most of the cases.
Bugs creator.
Features destroyer.
Template killer.

Re: Theme/template class

Reply #20 –

I just think it makes it easier to understand the flow. Currently, it jumps from the layers to get all of the above layers. Then it goes away from that and gets the sub/main template. Then it goes below to get all of the below layers. I guess you'd still have the same idea but now it would be in one class. I guess I would call it the "core" template to play on the layers idea ;)

Re: Theme/template class

Reply #21 –

Another crazy idea I just had... stop playing with layers in the controller. Instead, move all of that to the theme. The controller loads the theme. The theme contains options and more importantly, methods that tell what layers to load, in which order, and what templates to call. I used to think it was a huge waste to have to define what goes above and below a template, but this adds a layer of abstraction which makes that a non-issue. I don't know of any "themes" that change layers or templates so this level of abstraction doesn't really get in the way. It does allow for something cool though - other template engines. Now, it would work the same way that Twig does - load and then render. Don't worry about layers.

So, how does it look? Let me try with action_display() from the display controller.

The way it works now is the controller loads 'Display' and assigns the sub_template 'messages'. Then it adds a layer at the end 'messages_information'. It does a bunch of stuff like loading up the topic, its messages, attachments, members, etc and putting them in to $context. It also loads up some Javascript files and other stuff. Then it returns (null) and obexit() does all of the work of outputting that. It reads the layers array, calling the templates _above() and then it calls the sub_template and then it does the _below().

That's pretty much how it works for all actions. The display action is about 550 lines. It's mostly a bunch of assigning $topicinfo to $context variables. The developers (Spuds and Emanuele mostly) did an awesome job at removing the queries from the actions, but they are still very heavy. Anyway, let me outline the proposal.

Just like before, somewhere early on the template will get loaded. $theme->load('topic.display') would load the template but it would return any settings that it thinks the controller should have. It then loads the topic, messages, attachments, members, etc. All of that gets put in to containers which are automatically passed to the theme. So, the controller explicitly passes the topic id and that's about it when it calls $theme->render(['topic' => $topic]) at the end of the function. Alternatively, you can just return an array and it would be handled. So long as you don't return a separate kind of response (XML or JSON) it accepts a ThemeResponse. When you call load() it checks if there are any functions/services that match it and changes the layers (in this case, it would call the display init function) and that would set the layers. It could also just do that on render. Probably better in render(). When it renders, it does the same thing as obExit().

Notice that I didn't say anything about setting up $context variables. Context handlers accept an object (Topic, Message, etc.) and return a new object with easy-to-access properties like href, link, etc. You call it in the template by using $msg = $this->context($message) and then $msg is a magic MessageContext object.

I think it would make everything a little bit nicer. It certainly reduces the size of the controllers which is always awesome (fat model / thin controller). You might think it adds logic to the "view" but that's not true. The templates don't contain any more logic. The theme has the same amount of control (layers were always available in the theme). You are only changing settings.

Please ask questions. There's some things that I didn't explain so there has to be some. I am excited about it.

Re: Theme/template class

Reply #22 –

Since the theme is loaded before the controller is dispatched, the theme should set any event listeners at that time. There are really very few times that the theme needs to talk to the controller or model so that's not a big deal. There are 19 _init templates including the theme's template_init(). All but two are just loading one of the generic templates so they don't need to be done before the controller. Only 1 actually makes any changes.

So, really, the render call can be exactly like Twig. That means we can have swappable template systems with ease :D

Re: Theme/template class

Reply #23 –

offtop?

More templating! (express)

Example:
Code: [Select]
$app->default_view_engine = 'php'; // if extension is empty
...
$response->render('/path/to/file', $data); // php
$response->render('/path/to/file.php', $data); // php
$response->render('/path/to/file.twig', $data); // twig
$response->render('/path/to/file.jade', $data); // jade
$response->render('/path/to/file.haml', $data); // haml
Sorry for my English

Re: Theme/template class

Reply #24 –

I just reread this. No wonder there wasn't a response. It was confusing. I don't want to retype everything, but let me know if it's confusing to anyone.

Re: Theme/template class

Reply #25 –

I never managed to find a way to deal with templates that satisfies me completely in all these year.

I think I got most of what you described, but now I started adding too much to it and probably missed the point, so I'll re-read it this evening. lol
Bugs creator.
Features destroyer.
Template killer.