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.

How to add custom stylesheets and javascript

Here was the tutorial on how to do it:

http://framework.weblite.ca/documentation/how-to/custom_javascripts

Basically you just add the code at the delegate class, or application class:

function block__custom_stylesheets()

OR or javascripts:

function block__custom_javascript()

You can also use the dataface application class object which has a function called addHeadContent, and what this does is it will add any thing you enter as a parameter into the slot in the head (the same slot that has the custom stylesheets and javascripts.

For example:

$app =& Dataface_Application::getInstance();
$app->addHeadContent("HELLO");

This will add the words 'HELLO' to the slot section of the html.

The main difference between using this addHeadContent function and the block__custom__stylesheet/javascript function is that you can use the addHeadContent function inside any other function. The block__custom__stylesheet function is isn't own separate function that can't be used in any other function.

But you can do something like this with the addHeadContent function. For example:

function field__recent_offerings(&$record){
$app =& Dataface_Application::getInstance();
$app->addHeadContent("HELLO");
}

So inside of this field function we call the addHeadContent. It has the same effect as the block__custom function, but you can be narrow it down to exactly when you want to include it. Like say you wanted to include the recent_offerings field and you want to apply a custom CSS class to it. You can just call the addHeadContent function.

This is opposed to calling the block_custom function and added the css style there. You would then probably have to add a comment to beside the style sheet there just to remind yourself why this style sheet is even in there.

So it's just for convenience sake.

Using the table relationship permissions function

Inside of each delegate class, we can use the function rel_nameOfRelationship__permissions(&$record) to specify the permissions on that relationship. The reason this works is because when we click on a tab to go to the relationship we are still in the original table.

For example, say we have a companies table that had a relationship to an offerings table. An offerings tab will be present. You can control the permissions on the tab (as in whether the user can add new offerings) by using that rel_nameOfRelationship__permissions(&$record) function.

In the event, that you want to actually remove that tab from the view, then you need to do this in the relationships.ini file of that table folder. Like this:

[offerings]
__sql__ = "SELECT * FROM offerings WHERE company_id ='$company_id'"
action:condition="isAdmin() or ($record->val('company_id') == getCompanyID()) or ( isBrokerDealer() and $record->val('company_id') == getDealerID())"
actions:addexisting=0
action:label="offerings"
section:sort="date_reported desc

1. The __sql__ is just the SQL statement to retrieve the records


2. action:condition is the part that determines whether the tab should appear or not.


3. actions:addexisting makes it so that the add existing option doesn't appear

I found this strange bug (not sure if it is a bug). But if the try to enter action:condition = 0 just by itself it won't hide the tab. You have to enter action:condition = "false" in order for it to work...

Setting up Drupal Editing in Eclipse

Found a cool article that teaches us how to setup Drupal editing inside of Eclipse. Pretty cool actually.

The idea of adding like extra content types for a language can probably be extended for future use.