Sugar Developer Guide Version 5.1

Creating New Custom Displays

In this scenario, you wish to take advantage of the metadata framework to do some of the processing for a subset of the fields. However, the provided user interface generated does not meet the needs of your module which requires richer UI functionality. Typically this scenario occurs when the EditView or DetailView for the module contains UI components that do not fit the framework of a table layout that produced by the metadata. For example, in addition to displaying the properties for the bean instance of the module, there is also a lot of information to be displayed for related beans, mashups, etc.

This type of customization may be achieved by a combination of overriding the footer.tpl file in the templateMeta section of the metadata file and creating a view.edit.php file to override the default MVC EditView handling. For example, consider the Quotes module's editviewdefs.php file:

'templateMeta' => array('maxColumns' => '2',

'widths' => array(

array('label' => '10', 'field' => '30'),

array('label' => '10', 'field' => '30')

),

'form' => array('footerTpl'=>'modules/Quotes/tpls/EditViewFooter.tpl'),

),

Note: You don't have to necessarily create a view.edit.php file, but usually at this point of customization, you will want to add variables to your customized template that is not assigned by the generic EditView handling from the MVC framework. See the next example (Overriding the View) for more information about sub-classing the EditView and assigning Smarty variables to the resulting templates.

Your EditViewFooter.tpl file can now render the necessary user interface code that the generic metadata framework could not:

{$SOME_CRAZY_UI_WIDGET} <----- You can either create this HTML in edit.view.php or place it here

<applet codebase="something"> <---- Let's add an Applet!

</applet>

{{include file='include/EditView/footer.tpl'}} <--- Include the generic footer.tpl file at the end

Had you wished to edit the top panel to provide customized widgets then you could override the header.tpl file instead and control the behavior there. In that scenario, the smarty tag to include the generic header.tpl would likely appear at the top of the custom template file.