Difference between revisions of "Customizing an Application at the Site Level"

From ADF Docs
Jump to: navigation, search
Line 1: Line 1:
== Application Site Customization ==
+
== Overview ==
See the [[Custom_Application_Site_Level_Customization|Custom Application Site Level Customization]] wiki page for more detailed information on site customization.
+
Most ADF Applications contain [[Application Components]] which control a lot of the functionality for the Application.  In most cases, the Application Components control everything from storing/retrieving data from a Custom Element to rendering data on a page.
  
# Locate the ''_cs_apps'' directory on the site.
+
While building an [[ADF Application]] it can be difficult to think about all of the ways your application will be used and what customizations will be needed for each site that uses your applicationsLuckily, customizing (or extending, overriding) applications at the site level is very easy.
# Verify that the ADF application directory exists in ''_cs_apps''; if not, createFor example, the Profile Application will have the directory ''_cs_apps/pt_profile''.
+
 
# Place an [[Site_Application_Bean_Config|Site Application Bean Config]] file in the ADF application directory in the site "_cs_apps" directory.  
+
The general concept: You download an application from the [[http://community.paperthin.com/projects/browse.cfm CommonSpot Community Site] and there is a change in one of the components that you need to make.  Instead of modifying the component (for example /ADF/apps/pt_profile/components/profileService.cfc) directly within the /ADF/apps/appName/components/ directory - you would make a copy of that file and make the modification within the copy
# Update the [[Site_Application_Bean_Config|Site Application Bean Config]] variables for site name and application name.
+
 
# Ensure that the ''appComPath'' variable is correct.
+
== Step by Step ==
# Update the [[App Bean Config|App Bean Config]] of the site app to use any components at the site level, or server app level.
+
Using the example from above:
# Update the sites ''ADF.cfc'' to load the new application name into application scope via the ''loadApp'' function.  See the [[Site_Configuration#ADF_Applications|Site Configuration - ADF Applications]] wiki page for more details.
+
# In the site where you will make the modification create a directory within the sites /_cs_apps/ directory that mimics the name of the Application you will be customizing (for example: /mySite/_cs_apps/pt_profile/)
# For example, if we created a site customization for the Profile Application for ''SITE01'', then the ''loadApp'' function will reference the application as:
+
  Note: it is important to name the directory the SAME as the original app directory
  loadApp("ptProfile", "pt_profile_SITE01");
+
# Create a /components/ directory in the newly created [[Site Level Application Directory]] (e.g. /mySite/_cs_apps/pt_profile/components/)
 +
# Copy the component you would like to customize/override/extend from the applications /components directory/ (e.g. /ADF/pt_profile/components/) and place it into the Site Level Application Directory (e.g. /mySite/_cs_apps/pt_profile/components/)
 +
# Make the newly copied component extend the original:
 +
<source lang="cfm">
 +
  <cfcomponent extends="ADF.apps.pt_profile.components.profileService">...</components>
 +
</source>
 +
# Remove any of the functions within the component that you are not going to modify.  Components that you do not modify at this level will use the main apps components code.
 +
# Make the modifications to the component that you would like
 +
# [[Reset the ADF]]
 +
 
 +
== Best Practices ==
 +
* It is a good idea to keep the arguments and return variables the same in the method you modify.  The goal of the override should be to change the internals of the function, not the function itself
 +
 
 +
[[Category: How-To Guides]]
  
 
[[Category: How-to Guide]][[Category: Customization]]
 
[[Category: How-to Guide]][[Category: Customization]]

Revision as of 04:22, 5 April 2010

Overview

Most ADF Applications contain Application Components which control a lot of the functionality for the Application. In most cases, the Application Components control everything from storing/retrieving data from a Custom Element to rendering data on a page.

While building an ADF Application it can be difficult to think about all of the ways your application will be used and what customizations will be needed for each site that uses your applications. Luckily, customizing (or extending, overriding) applications at the site level is very easy.

The general concept: You download an application from the [CommonSpot Community Site and there is a change in one of the components that you need to make. Instead of modifying the component (for example /ADF/apps/pt_profile/components/profileService.cfc) directly within the /ADF/apps/appName/components/ directory - you would make a copy of that file and make the modification within the copy

Step by Step

Using the example from above:

  1. In the site where you will make the modification create a directory within the sites /_cs_apps/ directory that mimics the name of the Application you will be customizing (for example: /mySite/_cs_apps/pt_profile/)
Note: it is important to name the directory the SAME as the original app directory
  1. Create a /components/ directory in the newly created Site Level Application Directory (e.g. /mySite/_cs_apps/pt_profile/components/)
  2. Copy the component you would like to customize/override/extend from the applications /components directory/ (e.g. /ADF/pt_profile/components/) and place it into the Site Level Application Directory (e.g. /mySite/_cs_apps/pt_profile/components/)
  3. Make the newly copied component extend the original:
  <cfcomponent extends="ADF.apps.pt_profile.components.profileService">...</components>
  1. Remove any of the functions within the component that you are not going to modify. Components that you do not modify at this level will use the main apps components code.
  2. Make the modifications to the component that you would like
  3. Reset the ADF

Best Practices

  • It is a good idea to keep the arguments and return variables the same in the method you modify. The goal of the override should be to change the internals of the function, not the function itself