English 
Español
한국어
print pageBuilding Idiot Proof Templates
This article looks at how to build idiot proof templates. These are templates that have very basic controls and restrict the opportunities for less skilled users to make mistakes when editing content.
Maintaining the balance between making the system as easy as possible to use but having enterprise level features is one of the great challenges when developing a CMS. Even with the huge advances in WYSIWYG editors they can still cause some frustrations to ordinary users and developers/administrators need to offer alternative interfaces for adding and updating content. ShadoCMS has a number of tools to make this possible.
By default the standard content type of a container is "HTML" which means when you add a container to a page the system will generate a WYSIWYG editor when the user goes to edit the container. Using the "Content Class(Container Type)" controls, users can also change the content type to a system defined content type such as an include or form. There is also capacity in the system to allow templates to be developed with custom content editors and renderers. To show you what I mean, in the default code for a container you would use the following:
<cfset request.oPageObject.addcontainer2page(2, "Main Content", request.container2edit,"html")>
Which would produce a WYSIWYG editor when editing content.
Alternatively you could add something like:
<h2 class="leadin">
<cfset request.oPageObject.addcontainer2page(page_position=1, description="Lead In",
container2edit= request.container2edit,custom_render_path="/#request.sitecontext.dsn#/app_templates/customeditor/textrender.cfm",customeditor="texteditor.cfm",
defaultcontent="This container should have a statement around what the page is all about.")>
</h2>
This logic uses a custom renderer and a custom editor to display a basic text input control to the user rather than the standard WYSIWYG control. As you can see, to ensure this logic works you need to use named arguments and you have two arguments that ensure your custom editor and renderer work. These are:
custom_render_path
This should be the full path (from the webroot) to the custom renderer file
customeditor
This should be the name of the custom editor file
We'll now cover how to create the custom editor and and renderer and what each file does. The render file will be used to output the content to the page when a user is viewing the page, the editor is what is presented to the contributor / administrator when editing the text / data in the container. So in the basic example of a text editor the text will simply be rendered to the screen by the renderer and when in edit mode the editor will display a simple text control to the user. There is a little bit more to it than that but those are the base principles.
Comments
There are no comments for this page as yet.
Full RSS
