Advanced Configuration

Once you've gotten farmiliar with the Slatwall platform and everything that it has to offer, you may find yourself really wanting to customize Slatwall's behavior.  This section will go into details about the folder structure and various configuration files for deployment.

Folder & File Structure

Folder & File Description
Holds the primary administrative web application. This directory consists of 3 sub-directories; controllers, layouts & views. The majority of the admin application runs through the /views/entity directory so if you are interested in learning about how we layout our administrative views, this would be a good place to start.

It's important to note that this directory is a FW/1 subsystem, and for more information on how FW/1 subsystems work please visit the wiki here: FW/1 Wiki
assets/ The assets directory holds some of the core CSS & Images for the application
The config folder holds all of the data, and setup that Slatwall uses to set itself up. This folder should never be modified, if you would like to make instance level configuration changes they should be done in the /custom/config direcotry.
  • dbdata/ - contains XML documents with the default data that gets inserted into the DB on install
  • resourceBundles/ - contains internationlization files for using slatwall in multiple languages
  • scrips/ - contains files that run during full updates to manipulate the database if needed.
  • configxxx.cfm - These files define the Hibachi setup information.
  • lastFullUpdate.txt.cfm - This file is written to every time an update reload is done. If your application is having issues you can delete this file so that the next request forces a reload.
Any customizations to how the application functions can be defined in this directory. Any code added here will not be overridden when the application is updated. You will notice that the folder structure mirrors the the same folder structure from the root.
frontend/ The frontend directory was previously used as the primary subsytem used by public facing websites in versions 2.3 and previous. This folder is deprecated so please use the 'public' subsystem for all new development.
integrationServices/ This directory is the primary place where you can extend the Slatwall application to fit your businesse needs. It contains a handful of integrations that we provide, and in addition you can add new directorys to this folder in order to extend / customize the application.
meta/ Contains a lot of meta information about the application, including these docs. It also has our Test suites, and some tools like snipits and dictionaries that can be used in your IDE or Text Editor
This is the beating heart of Slatwall, and contains all of the businesse logic that makes up Slatwall (with the exception of the /org/Hibachi directory). It is strongly suggested that you explore these sub-directories and especially the /entity directory as it maps out the entire database structure.
  • dao/ - Used by the services as the go-between from service to database.
  • entity/ - All of the persistent data entities are stored here.
  • process/ - Contains transient objects used by the "Process" service methods. Typically these objects are used to validate non-persistent data before it gets used in the application
  • service/ - The services in this directory control how the entities are managed.
  • transient/ - Contains objects that only exist for a single request, and pass data around the application.
  • validation/ - Contains all validation json files for all entities & process objects that get used both server-side & client-side.
The org directory is where we store all libaries, frameworks, etc. that are independintly managed. The primary external library is /Hibachi which is a framework developed by ten24 that sits on top of FW/1 to provide abstract ORM features for Rapid Application Development.
tags/ This directory holds some CF Custom tags that are used by Slatwall specifically in the admin and integrationServices

* Folder is save to make changes within, without fear of being overwritten during update.
* Folder is not needed, but recommended
* Folder is deprecated.

Deployment Configuration Files

In the /custom/config directory of Slatwall, 4 important files allow for an override of the default settings, and give you controle over how the application functions. Normally, none of these files will be defined this folder unless  Slatwall was installed via a connector plug-in.  In that case there may be some files that were automatically written to link Slatwall with that application.

Any config files added to the custom folder will be pulled into the application and override the defaults defined by Slatwall. The files will be loaded up in the order below.

File Description
/config/custom/configApplication.cfm Mostly this file is used to define a non-standard database connection configuration or a blended CFML application scope.
/config/custom/configFramework.cfm Customizing this file will allow you for some very granular control specifically around some security settings.
/config/custom/configMappings.cfm Very seldom used, again for the advanced CFML develop to include additional application level mappings.
/config/custom/configORM.cfm This file defines how Slatwall will connect with your database and allows you to configure some caching options.


Below you will find a list of all the setting avaiable to you in these files.  If you want to change a setting value just open (or create) the necessary setting file, and define the setting with the following syntax.

<cfset {setting_name} = {setting_value} />


For Example

<cfset variables.framework.hibachi.debugFlag = true />

Configuration File Settings

Setting Default Description
/custom/config/configApplication.cfm "slatwall{UUID}" Application name used by CFML engine "slatwall" Name of the datasource setup in CFML administrator
this.datasource.username   Username for the datasource, typically this is defined in the CFML administrator
this.datasource.password   Password for the datasource, typically this is defined in the CFML administrator
variables.framework.home "admin:main.default" Default action/screen that users see when they login.  This can be changed to be a custom action or an action built into an integration
variables.framework.error "admin:error.default" Default action/screen that users see when a server error happens.  This can be changed to be a custom action or an action built into an integration
variables.framework.reload "reload" URL Key for clearing application cache.
variables.framework.password "true"

URL Key Value used in conjuction with the setting above.

IMPORTANT: For security purposes it is best to set this password to something that is unique to you.  It will help to minimize DoS attack effectiveness

variables.framework.reloadApplicationOnEveryRequest false Only set to true for debugging or development purposes.
variables.framework.hibachi.debugFlag false Setting this to true will allow for more enhanced logging on both the client and server side.  Should remane false in production for performance.
variables.framework.hibachi.updateDestinationContentExclustionList "/.git,
Defines all of the files and directories that will be ignored when deleteting the current install of Slatwall on an Update.
variables.framework.hibachi.gzipJavascript true Allows for JavaScript to be gzip'd
variables.framework.hibachi.errorDisplayFlag false Setting this to true will allow for entire error messages to show with potentially sensitive information.  Should remane false in production.
variables.framework.hibachi.errorNotifyEmailAddresses "" List of email addresses that you would like detailed error reports to be sent
variables.framework.hibachi.fullUpdateKey "update" URL Key used when performing a Slatwall Update
variables.framework.hibachi.fullUpdatePassword "true"

URL Key Value used in conjuction with the setting above.

IMPORTANT: For security purposes it is best to set this password to something that is unique to you.  It will help to minimize DoS attack effectiveness

variables.framework.hibachi.loginSubsystems "admin,public" List of subsystems that have their own login screens.  If you have built an integration that manages it's own login screen, you should add it to this list.
variables.framework.hibachi.loginDefaultSubsystem "admin" Default login subsystem when a user doesn't have access
variables.framework.hibachi.loginDefaultSection "main" Default login section when a user doesn't have access
variables.framework.hibachi.loginDefaultItem "login" Default login action when a user doesn't have access
variables.framework.hibachi.useCachingEngineFlag false Set this to true if you'd like to use the caching engine setup as part of your CFML engine.  This can be great for doing things like clustered caches.
variables.framework.hibachi.noaccessDefaultSubsystem "admin" Default subsystem if someone is logged-in but doesn't have access to a resource.
variables.framework.hibachi.noaccessDefaultSection "main" Default section if someone is logged-in but doesn't have access to a resource.
variables.framework.hibachi.noaccessDefaultItem "noaccess" Default action if someone is logged-in but doesn't have access to a resource.
variables.framework.hibachi.lineBreakStyle {Server OS Name} Should not ever need to be overwritten unless instructed to.
this.mappings["/slatwall"] {Path To Slatwall Folder} This provides a CFML mapping to the slatwall root directory.  If you would like to add additional mappings you can do so in this configMappings.cfm file.
this.ormsettings.cfclocation ["/slatwall/model/entity", "/slatwall/integrationServices/"] Array of strings that define where there are .cfc's that will be used as persistent entitites for the database.
this.ormSettings.dbcreate "update"

Can also be set to "none" which will never run the implicet scripts necessary to update the database when performing an update or adding entities.

Also can be set to "dropcreate" which will whipe out all data every time the update key is used.  this is NOT recommended.

We recommend that you NEVER touch this setting unless you are 100% sure you know what you're doing :)

this.ormSettings.logsql false Setting this to true will output all SQL being run against the DB to the console output, or a logging file.  It is not recommended to be turned on in production.

Questions & Comments