Parse Custom Tags Parse Includes

For a demo of ParseDog click Here Using ParseDog

Parsing Custom Tags Converting Custom Tags to Module Calls Parsing Includes How does this work? Report Definitions

Custom Tags

ParseDog needs the following two fields in order to operate correctly. 1. Root Folder - This is the root folder of your application. 2. Custom Tags Directory - This is the custom tags directory of your application. (this may be the same as your root folder depending on your application architecture.) The other fields apply if you are converting custom tags to module calls. *note ParseDog is designed to parse custom tag calls in this format ie <cf_custtag> You also have the option through ParseDog to change the format of these calls to <cfmodule template="custtag.cfm"> or <cfmodule name="custtag"> *If you would like to parse custom tag calls in the format of <cfmodule template="custtag.cfm"> use the inludes parser. ParseDog will not find <cfmodule name="custtag"> at this time.

Converting Custom Tags to Module Calls

This aspect of ParseDog offers unique functionality! The initial requirement came about when we had a large application that was filled with custom tag calls in the format of <cf_custtag>. The application worked, however we wanted to set up a dev environment on the same machine. I know this is bad! The problem surfaced that all custom tag calls were referencing the same custom tags directory. Thus, there was no way to change custom tags without changing production code. The solution was to change the calls to module calls. This actually performs better and allowed us to specify "Dev Custom Tags" on the same server. There are several variables that you can specify when changing custom tags to module calls. 1. Global Custom Tags Path - This variable will be inserted into the beginning of your custom tags path. ie <cfmodule name="#yourvariable#.custtag"> or <cfmodule template="#variable#/custtag.cfm"> this allows you to globally specify where your custom tags are located. 2. Tags to be left alone - You may have tags that you would like ParseDog to leave alone! ie custom tag calls with a closing tag <cf_custtag> with </cf_custtag> include the filenames of tags to leave alone in a comma separated list. For the above it would be custtag.cfm. 3. Exceptions: - This works in conjunction with the exception path. They are parallel lists containing the exception filename and the exception filename path or variable. Once you parse an application, You may have exceptions to the rule or tags that need a different module variable than the standard. If ParseDog Does not find a file associated with a custom tag, it will search through the list of exceptions. If an exception is found, it will look at the path for the exception in the exception path list. The exception will then be used in the module call. ParseDog may encounter <cf_custtag> in a file. It will look in the list of all the files under your custom tags directory for custtag.cfm. If it is not found, ParseDog will look in the exception list. If found, ParseDog will use the associated path in the exceptions path list in the module call. 4. Exception Paths: - (See above) must have the same number of elements as the exceptions field. 5. Tag Format: - When converting custom tags to module calls, you can use different formats. either <cfmodule name="#yourvariable#.custtag"> or <cfmodule template="#variable#/custtag.cfm">. 6. View / Rewrite Files: - If you choose view files, nothing will be written. You simply will get a textarea for every file and you can view the syntax of the new custom tag calls. This is a great place to check and make sure that everything is functioning as expected. Rewrite Files: Rewrites all your custom tag calls in your application to module calls. Make sure you make a backup before running this. It is rather permanent!!

Parse Includes

This requirement was to enable us to find errors before they were moved into production. In addition, we also needed a way to check case in these areas. Case sensitivity became an issue when moving from NT to Unix. The includes parser offers a powerful recursive search for includes, form actions, and hrefs. In order to operate the includes parser, you must specify the root directory of your application.

How does this work?

The technology behind ParseDog is rather simple, other than some tricky string functions, Here is the nickle tour: ParseDog takes your directory root: (With the custom tags this can be a different directory) From the root, a list of all the cfm files are built. Using the same recursive engine, ParseDog goes back through the directory and reads each .cfm file into a string. Within the text string, includes, custom tags, hrefs etc are parsed out. The filename is obtained, as well as the path in relation to the file we have read. viola! We can now re-create relative paths. We now look for files in the first list that was built and also determine if the paths are correct. Known limitations If variables or mappings are used, we cannot check path and file.

Report Definitions

The following is a list of the report definitions that come back when ParseDog is run: Custom Tags The first row in the table lists the tag that was parsed. You may click on this to obtain the file. The second row first column displays the name of the custom tag call that was found. This will also show the case that it is in the file. The second column displays the status of the custom tag call: All Systems Go - The file has been found, and the case is correct. Exception Used - The file has not been found, but an exception has been used. Case Difference - The file has been found but the case is different. The correct case will be displayed in red. Custom Tag Not found! - There is a call to a custom tag that was not found. ------------------------------------------------------- Includes, Hrefs, Form Actions The first row in the table lists the tag that was parsed. You may click on this to obtain the file. Link Type-This is the link type ie..template, form, cfform, href File-This is the target file. Status-This is the status regarding the target file. Note ParseDog searches in a list of all the files from the root of your application. It will find the first occurance of the target file name. If you have files of the same name such as index.cfm, it will only find the first occurance in the list. It is a loose confirm. The real confirm will be in the path box. Possible status messages are shown below:    File Found- Found the file (loose confirm)    404 file not found- The file was not found.    Case Error!!!- The file was found but the case is different the correct case is given. Path-This is the path to the referenced file. Possible path messages are below:    Confirmed- The path is confirmed.    Path is wrong!- The path appears to be wrong    Path Case Error!!!- The file was found but the path case is different. The correct case is given.    Path recurses too far!- The path recurses too far too many ../../      (note: some paths may appear wrong however they are resolved at runtime by the produced html!!)