HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Please upgrade here. These earlier versions are no longer being updated and have security issues.

template confusion - default.master.php versus default.master.tpl?

codegruntcodegrunt New
edited January 2011 in Vanilla 2.0 - 2.8
Howdy. I have been playing with Vanilla for a bit now and my main complaint has been that true template support is missing. While trying to sort out where the "Panel" layout was actually coming from in "default.master.php", I was reading the theming guide and noticed that the mobile friendly theme actually does use true templates (Smarty templates which actually have some separation of layout and logic). So support is there, it is just not used in the default theme which is why I missed it initially.

The theming guide talks about "default.master.tpl" but the only such files in the current version are for the mobile and embed friendly themes, not the main one.

What I am hoping I can get some clarification for is how the templates are actually integrated. Do they take precedence over the ".php" version? Is every case of a ".php" file under "views" replaceable with a Smarty template or do only some of these support Smarty templates? Right now it looks like a hodgepodge even under the mobile view (which has a custom "helper_functions.php" so it is hard to tell what the intent is by the Vanilla developers.

Any help appreciated on understanding the proper approach here (the theming guide is not helpful in this regard as it assumes that the main theme already has a "default.master.tpl" which it does not).

Cheers

Comments

  • edited January 2011
    The only difference I see between ".php" and ".tpl" files is that the only the later supports tags, i.e. {dashboard_link} and seems to be stripping php code.

    If you've got both in your views folder, default.master.php takes precedence over default.master.tpl, but I see no reason to use both.

    I'm using .tpl because tags look cleaner. If you need advanced php wizardry, use .php.
  • @xatrix

    Thanks for the followup. I was thrown initially because there appears to be some sort of caching going on and moving default.master.php out of the way was not being picked up immediately by Vanilla.

    As to using TPL, it is definitely preferred as it makes layout much more obvious but the two are not equivalent. For example, the ".php" version includes an event hook towards the end of it:

    <?php $this->FireEvent('AfterBody'); ?>

    There appears to be no similar tag for use with templates so presumably some plugins (and / or stock functionality) might not work with the ".tpl" version.

    Cheers
  • SS ✭✭
    edited January 2011
    Smarty templates is a true templates
    ^ LOL.
  • TimTim Operations Vanilla Staff
    Yeah, one is smarty and one is straight PHP. Smarty is something that a lot of pure designers seem to like, so we've included it for their benefit.

    Vanilla Forums COO [GitHub, Twitter, About.me]

  • codegruntcodegrunt New
    edited January 2011
    @tim @S

    Thanks for the feedback.

    The reason Smarty is preferred is because it reduces the amount of program logic tangled up with layout. For anyone that has ever had to deal with legacy applications such osCommerce, ZenCart, phpBB, etc., the need for this separation becomes very apparent.

    A very clear current codebase example of the reason why going with something like Smarty is a better choice than straight up PHP would be Prestashop. The choice of using a true templating system means it is simple to make fairly dramatic changes to the look of a site without having to wade into program logic. This makes it much less likely to have your template completely break when the next codebase upgrade comes along as well since it abstracts what is going on internally.

    Another huge bonus is that layout becomes *much* clearer.

    Which of the following is more obvious as to what you will like get at run time?

    <?php $Session = Gdn::Session(); if ($this->Menu) { $this->Menu->AddLink('Dashboard', T('Dashboard'), '/dashboard/settings', array('Garden.Settings.Manage')); // $this->Menu->AddLink('Dashboard', T('Users'), '/user/browse', array('Garden.Users.Add', 'Garden.Users.Edit', 'Garden.Users.Delete')); $this->Menu->AddLink('Activity', T('Activity'), '/activity'); $Authenticator = Gdn::Authenticator(); if ($Session->IsValid()) { $Name = $Session->User->Name; $CountNotifications = $Session->User->CountNotifications; if (is_numeric($CountNotifications) && $CountNotifications > 0) $Name .= ' '.$CountNotifications.''; $this->Menu->AddLink('User', $Name, '/profile/{UserID}/{Username}', array('Garden.SignIn.Allow'), array('class' => 'UserNotifications')); $this->Menu->AddLink('SignOut', T('Sign Out'), Gdn::Authenticator()->SignOutUrl(), FALSE, array('class' => 'NonTab SignOut')); } else { $Attribs = array(); if (SignInPopup() && strpos(Gdn::Request()->Url(), 'entry') === FALSE) $Attribs['class'] = 'SignInPopup'; $this->Menu->AddLink('Entry', T('Sign In'), Gdn::Authenticator()->SignInUrl(), FALSE, array('class' => 'NonTab'), $Attribs); } echo $this->Menu->ToString(); } ?>

    Or this:

    {discussions_link} {profile_link} {inbox_link} {custom_menu} {event name="BeforeSignInLink"} {if !$User.SignedIn} {link path="signin" class="SignIn"} {/if}

    The latter is an order of magnitude easier to understand from a layout point of view and allows both programmers and designers to immediately see what is going on. The former PHP based version requires far more understanding of the codebase and also is much more likely to lead to all sorts of problems since it encourages the designer to mess with program logic that in most cases they probably should not be if all they want to do is move a link around or add some graphics here and there.

    I am more of a programmer than a designer but when I am having to do extensive greps of the entire codebase to figure out which class file layout has been embedded into, it is arguable that the templating system is not fully realized.

    For example, this is what "themes/[themename]/views/discussions/discussions.php" looks like:

    <?php if (!defined('APPLICATION')) exit(); $Session = Gdn::Session(); if (!function_exists('WriteDiscussion')) include($this->FetchViewLocation('helper_functions', 'discussions', 'vanilla')); $Alt = ''; if (property_exists($this, 'AnnounceData') && is_object($this->AnnounceData)) { foreach ($this->AnnounceData->Result() as $Discussion) { $Alt = $Alt == ' Alt' ? '' : ' Alt'; WriteDiscussion($Discussion, $this, $Session, $Alt); } } $Alt = ''; foreach ($this->DiscussionData->Result() as $Discussion) { $Alt = $Alt == ' Alt' ? '' : ' Alt'; WriteDiscussion($Discussion, $this, $Session, $Alt); }

    That is straight up program logic which not a hint of layout in site. Changing the layout in fact requires editing "helper_functions.php" which is a just a set of procedural functions with layout embedded in it. That is not a template and it also creates a far harder to maintain system.

    Cheers
Sign In or Register to comment.