Please upgrade here. These earlier versions are no longer being updated and have security issues.

How to use php functions inside smarty templates?

For example, we need to access some variables on view files so in case of php i.e <?php echo $this->Username; ?>

so how to achieve the same in smarty. I have tried this {php}$this->Username{/php} but it is not working at all.

Any help much appreciated.

Note: We are planning to make every views in smarty so is it possible via vanilla or smarty support is only for master layout and inner views should be in php?

Kindly confirm.

Comments

  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    Views in Vanilla are normally rendered with a call similar to that: $this->render('edit', 'user');. Which in this case means that Vanilla searches for a view with a file name of either edit.php or edit.tpl
    So yes, you can use Smarty templates for everything.

    But you shouldn't. Replacing every view normally means that your developers do not know how to work with css and or Vanilla.
    You can insert html or prevent html output with php code in the theme hooks file. That requires php skills and some time to learn Vanilla.

    You cannot use php directly in Vanillas Smarty templates. But you can create your own Smarty functions: https://open.vanillaforums.com/discussion/27767/how-to-create-custom-smarty-functions
    There is a Foundation based theme (I forgot the name) that uses this, just if you need an example.

    You can insert {debug} in the default.master.tpl to see available information for Smarty.


  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    @jenis said:
    Note: We are planning to make every views in smarty

    As I've said before, that is a real bad idea. Updating Vanilla will either be impossible without a lot of extra work or it will make new features unreachable since the GUI simply doesn't show them.

    Also plugins might break the design of your forum and you will have to theme them to. By sticking to Vanillas css classes you can avoid that.

    A superb example of good implementation is the Bootstrap theme. It lays Bootstrap over Vanilla without overwriting anything but the main template. Don't let your designers/developers tell you they need to rewrite the interface. That most probably isn't true.

    If you want to, you can ask a few questions like "how to show/hide this information before after this and that place" and I might be able to show you the Vanilla way to do so.


  • x00x00 MVP
    edited July 2018

    views are a weaker point of vanilla.

    there is no distinction between views and templates but then again it is MCV not MCVT. So while controller logic is done in the controller methods, the view process that data for output and contain a fair amount of code, so beyond the master template that yield the views, smarty is not of much use.

    Smarty as used isn't like dgnago blocks, where you can do post manipulation.

    view overrides are possible but not recommended often due to potencial limiting upgrades.

    grep is your friend.

  • Thanks for your inputs.

    But actually, we are going to create a new separate application as an add-on in "applications" folder and will not touch "vanilla" and "dashboard" applications so that in future any updates come, we can easily do the upgrades.

    Just curious to know that is it worth to use smarty in all our application views?

  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    @jenis said:
    Thanks for your inputs.

    Just curious to know that is it worth to use smarty in all our application views?

    Whether a templating engine is useful or not is wildly discussed throughout the net and my opinion on that question in this context is that you a) should do what helps you achieve results quicker and b) re-use as much of the framework as possible. That can be a contradiction, though.

    If you have designers that know Smarty, you will torture them with PHP and they might even make mistakes which creates security issues. The same goes for the opposite: if your designer knows PHP, why make him write Smarty in a project like Vanilla, where Smarty is available, but used for one view only (Vanilla in fact uses Smarty only for the main view)

    There are views available and reusable, but those views are php scripts. So if you want to benefit from the available source code, using php for your views is better.

    Instead of asking if it is worth to use Smarty you should ask yourself, what benefits you see there. Without knowing your resources, I would advice not to use Smarty in Vanilla. But if you can reuse Smarty blocks from another project or that new application shares code with a project that uses Smarty, it might be wise to use Smarty. The answer is, as in most cases: it depends...


    Bleistivt
  • @jenis said:
    Thanks for your inputs.

    But actually, we are going to create a new separate application as an add-on in "applications" folder and will not touch "vanilla" and "dashboard" applications so that in future any updates come, we can easily do the upgrades.

    Just curious to know that is it worth to use smarty in all our application views?

    Well you could. I think you need to create a paradigm first. Not to do away with vanilla convention altogether but do something to further separate concerns.

    Like I said controller data is one thing but there is still a lot of processing in views. You could use views to separate the data into blocks with no specific template for the block then use templates to to yield those blocks.

    That means doing the ground work first to support your architecture. You can take a leaf out of vanilla and do in an implicit way where you follow a convention for the flle the declare that blocks. Or you go for more a more explicit way including the block files.

    Of course this is all down to your developers ability to do craft this architecture.

    grep is your friend.

  • x00x00 MVP
    edited July 2018

    There are also a lot of pre-existing convention in vanilla like modules. Technically you could hyper modularise everything as module can be a way of separate module logic from the module view. You can then use smarty or php views to yield these modules as kind of blocks. The vanilla team has mostly used modules where it is not specific to controller view. However you could use it this way. The module can get the controller data, it doen't have to be standalone pulling is own data. Modules don't use smarty themselves but their view are more like templates.

    This is not necessarily less work, but it can make it a bit more maintainable.

    Arguably they have used too many approaches but none of this has completely tamed views yet. So they only reason to add to this architecture in your application would be to make it more versatile and also make it easer to understand and modify. If you are just adding complexity you are wasting your time.

    grep is your friend.

    Bleistivt
  • @x00, @R_J thanks for your inputs.

    For finally we have decided to stick to Vanilla's architecture and conventions so using php views instead of smarty.

Sign In or Register to comment.