All <xen: tags should be enabled (form, options, selectunit submitunit etc) for public templates too

[Chris D]

It's clear that all <xen: tags have been created for the purposes of making a developer's life easier, yet not all <xen: tags can be used in all types of template.

In the Admin Templates although you can use tags such as:

• <xen:radiounit>
• <xen:hint>
• <xen:option>
• <xen:textbox>
• <xen:spinbox>
• and many more...

You can't do the same in public templates.

If I wanted to produce this:


In an admin template this takes 8 lines of code.

In a public template, the exact same thing takes 32 lines of code.

Although these elements aren't widely used in public templates, they can still be useful.

Especially for add-on developers.

 

[sonnb]

Agree.

 

[Chris D]

Agree.

Something that may help...

I'm currently working on making my Notifications add-on available outside of the admin area. Essentially it's similar to Notices. If you imagine the 4 tabs you have when you create a Notice with criteria. That's all built using <xen: tags that aren't available on to public templates.

If each option takes 32 lines of code, I'd be looking at well over 1,000 lines of code being rewritten.

Thanks to ragtek, there's another way...

In this example, I'll just fetch one admin template, but can easily be done with as many as you like.

Added to my template:

<xen:hook name="notification_edit_user_criteria" />

Then, in my listener:

if ($hookName == 'notification_edit_user_criteria')
{
$db = XenForo_Application::getDb();
$query = "SELECT `template_compiled` FROM `xf_admin_template_compiled` WHERE title = 'helper_criteria_user'";
$result = $db->fetchRow($query);
 
$template->setTemplate('helper_criteria_user', $result['template_compiled']);
 
$contents .= $template->create('helper_criteria_user');
}

There we have it. The Admin template now renders perfectly. Obviously as we're fetching the template from xf_admin_template_compiled, it's after all the <xen:tags have been converted to proper HTML.

Thanks again to ragtek for this.

 

[Robbo]

This won't happen. There is a reason they are only in the ACP. That reason is the public area is meant to be easily customized. The ACP is designed to stay as it is so they can make these shortcuts.

 

[Chris D]

Making those xen:tags available to the public area would make it even easier to customise the public area.

 

[Robbo]

No, it wouldn't? Make people have to a) learn more new syntax and b) have less power? This has been answered by the actual devs, I think I asked the same thing. They said something along the lines as what I did ^

 

[Chris D]

It's easier for beginners, and surely that kind of methodology should be targeted towards the public templates even more so than the admin templates.

The screenshot in my first post, this is the code necessary to create that control unit in the admin template:

<xen:radiounit label="{xen:phrase show_image}:" name="showimage" value="{$notification.showimage}">
<xen:hint>{xen:phrase do_you_want_to_display_an_image_in_your_notification}</xen:hint>
<xen:option value="0">{xen:phrase no_image}</xen:option>
<xen:option value="avatar">{xen:phrase show_visitor_avatar}</xen:option>
<xen:option value="image" label="{xen:phrase specify_an_image}:">
<xen:textbox name="image" value="{$notification.image}" />
</xen:option>
</xen:radiounit>

And this is how much code is necessary to create exactly the same thing in a public template:

<dl class="ctrlUnit">
<dt>{xen:phrase show_image}:
<dfn>{xen:phrase do_you_want_to_display_an_image_in_your_notification}</dfn>
</dt>
<dd>
<ul>
<li>
<label for="ctrl_showimage_0">
<input type="radio" name="showimage" value="0" id="ctrl_showimage_0" {xen:checked "{$notification.showimage} == '0'"}>
{xen:phrase no_image}
</label>
</li>
<li>
<label for="ctrl_showimage_avatar">
<input type="radio" name="showimage" value="avatar" id="ctrl_showimage_avatar" {xen:checked "{$notification.showimage} == 'avatar'"}>
{xen:phrase show_visitor_avatar}
</label>
</li>
<li>
<label for="ctrl_showimage_image">
<input type="radio" name="showimage" value="image" class="Disabler" id="ctrl_showimage_image" {xen:checked "{$notification.showimage} == 'image'"}>
{xen:phrase specify_an_image}:
</label>
<ul id="ctrl_showimage_image_Disabler">
<li>
<input type="text" name="image" value="{$notification.image}" id="ctrl_image" class="textCtrl">
</li>
</ul>
</li>
</ul>
</dd>
</dl>

32 lines of code vs 8.

Therefore, in that respect, the Admin Templates are easier to customise, and the syntax being available to public templates as well would therefore make them easier to customise.

And of course I'm not proposing all of a sudden the traditional way becomes unavailable, I'm just saying as an option, it certainly would make things easier.

It's ok for you to disagree, but I just feel this is a beneficial suggestion. One that shouldn't at all be tricky for the devs to implement and one that can make people's lives easier if they wish to use it, and make no difference at all if people don't want to use it who prefer the traditional way.

 

[Adam Howard]

I'm going to agree.

Maybe because I use to code things in vBulletin or phpBB, but find myself really pushing to code XenForo.

 

[Alteran Ancient]

This would make sense to a level, but if you exposed every class and object to a template used in a public area or front-end, then I do believe that you'd be introducing additional security risks to the system as a whole. "Expose only what you absolutely need to" is the expectation in today's security-conscious society.

I could be talking a load of old tosh, though, because what you said in the OP about being able to "short-cut" things like UI elements completely makes sense.

 

[Adam Howard]

This would make sense to a level, but if you exposed every class and object to a template used in a public area or front-end, then I do believe that you'd be introducing additional security risks to the system as a whole. "Expose only what you absolutely need to" is the expectation in today's security-conscious society.

I could be talking a load of old tosh, though, because what you said in the OP about being able to "short-cut" things like UI elements completely makes sense.

That's actually why the admincp templates and the front end templates are kept a part (have their own masters). Exposing any short cut code (even the ones we already use), is only as insecure as the product its self. XenForo, IPB, phpBB, vBulletin, and even WordPress use short cut code.

So using the remaining code onto the public will not have a direct ill effect.

 

[Chris D]

And we're only talking about basic template tags anyway. These template tags can only be used in Admin CP, and once they are compiled and rendered, the original code isn't visible to the end user, it has already been converted to HTML.

 

[Robbo]

Which is the issue because it removes power from the designer. This isn't going to happen regardless, they already said so... I'll try to find the thread to confirm.

 

[Robbo]

Okay I was sure they answered... maybe I read it on someone elses thread because mine has nothing heh... http://xenforo.com/community/threads/xen-form.14500/

 

[tyteen4a03]

Bumping this because this really needs to be implemented to ensure concise design across all addons.

 

[tenants]

Agreed, it would make life a little simpler, as long as there is no significant impact on performance / memory ...

Keeping the core trim and slim, and only adding things that are required by core is good design for performance / requirements

So if there is an impact, then it's really not worth it, plug-in desgners can add their own helpers