Displaying actions in a html select object

Here is an interesting example of how to use actions in an html select from object.

In our actions.ini file (delegate or conf.ini) we have a set of actions each with the category attribute set to bd_company_filters. Like this:

[show_only_approved_news]
;; Show only companies that have been approved by this broker dealer
url="{$this->url('approval_status=2')}"
condition="$query['-table'] == 'news' and isBrokerDealer()"
label="Approved News"
category=bd_news_filters

In our delegate class, we can access these actions like this:

$at =& Dataface_ActionTool::getInstance();
$actions = $at->getActions(array('category'=>'bd_company_filters'));

The first line retrieves the Dataface_ActionTool object which we then use to return an array of actions underneath the category bd_company_filters. Each action in the array of actions will contain the attributes specified in the actions.ini and can be accessed by simply using the normal array key like this:

foreach ($actions as $action){
echo action['url']
}

Here we are accessing the url attribute of each action under this category.

So putting it all together, we can do something like this (NOTE: this code is in the block__before_result_list() function):

$at =& Dataface_ActionTool::getInstance();

$actions = $at->getActions(array('category'=>'bd_company_filters'));
echo '<select onchange="window.location=this.options[this.selectedIndex].value" class="company_filters">';

echo '<option value="#">Filter Resources in this Category</option>';

foreach ($actions as $action){
echo '<option value="'.$action['url'].'">'.$action['label'].'</option>';
}

echo '</select>';

Here we are creating a html select object and then we are placing the different actions as options for the select valuelist. The labels of the actions act as the labels in the select list, and the urls are used as the values of the options.

A little simple javascript is used to change the window.location to the value of the selected item in the list on change.

Using the df_display() function

You can use the function df_display() to actually include html files (or I think any other file) in your templates folder that can then be displayed in your delegate class functions. For example,

function block__before_header(){
df_display(array(), 'offeringApprovalForm.html');
}

Here we have included the offeringApprovalForm.html file into block at the top or the page. You can then like use javascript to get elements from the form if you need it.

Additionally, the 1st parameter for the df_display() function actually takes an array of variables that can be used in the template as a smarty tag. For example, if we had an array and sent it into the df_display() function

$context = array();
$context['approved'] = 3;
df_display($context, 'left_menu.html');

Then the left_menu.html file can access the approved variable using a smarty tag like this {$approved}. This will display 3 in the location you specified.

Smarty Tags

So Xataface employs smarty templates throughout its application to apply its styles and stuff. I am not 100% sure how it works, but there are list of ENV variables which are available to be used throughout any template file in xataface. These ENV variables can be found at this link.

Changing preferences in the conf.ini file

The conf.ini file there is a section called [_pref] which you can use set different preferences through the application. For example, show_search = 0 will turn off search. How this works is that the various template files the application uses has special "Smarty" tags which have a line of code like this:

{if $ENV.prefs.show_search}
// some code
{/if}

This example was taken from the Dataface_Main_Template.html file. The $ENV.pref.show_search line basically checks the conf.ini file to see if the preference show_search has been set to 0. If it hasn't, then it will show search.

Another example is in the Dataface_List_View_summary.html file (which is an alternative template to list view of a table) there is a line of code:

{if !$ENV.prefs.SummaryList_hideSort}

Notice however, that there is a ! symbol. So in order to actually turn it off, the preference must be SummarList_hideSort = 1.

This idea can be extended across all templates.

Changing the default template for list view

You can actually change the default template list view (or maybe any other template) by doing something really simply. For example, we can use the Dataface_List_View_summary.html file (it's in the Dataface/templates folder) to replace our normal view of the list. To do this, go to the actions.ini file (can be the application one or a delegate class one) and enter this code:

[list > list]
template=Dataface_List_View_summary.html

The code list > list just says inherit everything from the list action and then add this new code and call it the action list. We are just like overwriting the default list action.

And some we point our template attribute to the template file we want and volia!

The debug option

You have the option of turning on debug = 1 in the conf.ini file in the application folder of a Xataface application. What this will do is basically display all the possible blocks you can insert code/templates into.

Slots will not be displayed in the page, but rather they will be present in the html code in comments.

Dataface record checkPermission() function

The dataface record class has a function called the checkPermission($permission) where the parameter is a name of a permission specified in the permissions.ini file.

Different users will have different permissions and so if the user who is currently logged in does not have this permission they won't be access the block of code that requires this permission. For example:



The the user who is currently logged in must have the view_stats permission. So assume like the user who is logged in has the role "REP" So if you go the permissions.ini file in the main application folder, then open it up you should be able to find the role "REP" which has permissions like this:



Notice how the last line is view_stats = 1 meaning they have the permission view_stats. And so they will be able to access the block of code.