Blog

Luis Majano

October 04, 2010

Spread the word


Share your thoughts

Our CacheBox 1.1 release is coming real soon and we have now completed our standalone CacheBox monitors so you can monitor the cache by using our custom tags. Not only have we created this reporting engine, but it is skinnable and today we are announcing a contest sponsored by our mothership company, Ortus Solutions. So here are the rules:

Prize:

  • $75 Amazon Gift Card for 1st Place

Rules:

The contest involves the creation of a new reporting skin for the ColdBox CacheBox Caching Engine. The latest ColdBox code can be downloaded from our github repository or by clicking here. The latest Cachebox documentation can be found in our wiki.

  • The code has to be submitted to us at the following address: lmajano@ortussolutions.com in zip format by October 22nd, 2010 midnight with your contact information (Full Name and Email)
  • The winners will be announced on Monday October 25, 2010 and Ortus Solutions will contact the candidates so they can claim their Amazon Gift Cards.
  • Ortus Solutions will choose the winning skin according to its implementation, look and feel and overall code design. Ortus Solutions has the right to revoke or chose any candidate it sees fit and retains its discretion to announce it.
  • The code that is submitted to us has the potential to be open sourced with the Coldbox Platform and CacheBox distribution, so all of its assets and code MUST be distributable and adhere to its licenses. The ColdBox Platform is executed under an Apache 2 License.
  • Please play fair and if the code is not yours, don’t submit it, we are not responsible for any license or infringements, you are!

Creating Skins

The distribution download has a sample skin built in and also a quick template that uses it. The skins can be found here:

/coldbox/system/cache/report/skins

and the sample usage can be found here

/coldbox/testing/cases/cache/report/index.cfm

A simple usage is below:

   1: <!--- Import Report Tags --->
   2: <cfimport prefix="cachebox" taglib="/coldbox/system/cache/report">
   3:  
   4: <!--- Create CacheBox --->
   5: <cfif structKeyExists(url,"reinit") OR NOT structKeyExists(application,"cacheBox")>
   6:     <cfset application.cacheBox   = createObject("component","coldbox.system.cache.CacheFactory").init()>
   7:     <cflocation url="index.cfm" addtoken="false" />
   8: <cfelse>
   9:     <cfset cachebox = application.cacheBox>
  10: </cfif>
  11:  
  12: <cfoutput>
  13: <html>
  14:  
  15:     <head>
  16:         <title>CacheBox Monitor Tool</title>
  17:     </head>
  18:     <body>
  19:  
  20:     <!--- Render Report Here --->
  21:     <cachebox:monitor cacheFactory="#cacheBox#" />
  22:  
  23:     </body>
  24: </html>
  25: </cfoutput>

You basically need to import the taglibrary path: /coldbox/system/cache/report and then use the following tag:

<cachebox:monitor cacheFactory="#cacheBox#" />

The attributes for the monitor tag are:

  • cacheFactory – The instance of cachebox to report on
  • baseURL (Optional=cgi.script_name) – The base URL for all AJAX operations or calls to the page containing the tag. By default it uses cgi.script_name but you can set it to whatever you like.
  • skin (Optional=default) – This is the skin you want to use for the report. By default it uses the ‘default’ skin and of course this contest is about skins, so you will use your own name here. This matches the name of the directory containing your skin in the /coldbox/system/cache/report/skins directory.
  • contentReport (Optional=true) – A boolean flag that denotes if the content report will be shown or not, usually a skin would implement this as it is in this case.

The skin can also require attributes as it sees fit. They will be available in a structure called attributes in the variables scope in any of the rendered templates just like normal tags. They will also have access to the caller scope by using a variable with the same name: caller within the skin templates.

The following files are what makes up a skin for CacheBox reporting. Please note that you can have more assets, images, js, etc but the following are the only requirements:

  • cachebox.js – A javascript file that will be included into the header by the reporting monitor
  • cachebox.css – A css file that will be included into the header by the reporting monitor
  • CachePanel.cfm – The main shell of the cache panel. Usually has polling monitors, cachebox info and some commands
  • CacheReport.cfm – The report for a specific cachebox cache provider
  • CacheContentReport.cfm – The content report of a specific cache provider

All of the skin templates are rendered within the /coldbox/system/cache/report/ReportHandler.cfm component and you can use its internal methods for processing commands or rendering sub panels. Please look at the code or here are the most common methods:

  • renderCachePanel()
  • renderCacheReport(cacheName)
  • renderCacheContentReport(cacheName)
  • renderCacheDumper(cacheName,cacheEntry)

As you will see from the ‘default’ skin, you can make ajax calls into the tag location to process commands or render debug panels. The available debug panels that are rendered via AJAX calls are the following, but please remember that you can pretty much handle incoming calls in any way you like. The URL variable used for this is called “debugPanel”:

  • cache (default) – Rendering of the cache panel via the rendercachePanel() method.
  • cacheReport – Rendering of a specific cache provider report via the renderCacheReport() method, which uses an incoming URL variable of URL.cbox_cacheName
  • cacheContentReport – Rendering of the content of a specific cache provider via the renderCacheContentReport() method. Uses the same URL variable of URL.cbox_cacheName
  • cacheViewer – Renders a dump of the cache entry specified in the incoming URL variables: URL.cbox_cacheName, URL.cbox_cacheEntry via the renderCacheDumper() method.

As noted and from the sample skin, you can emit commands to the tag itself by passing the following URL variable: URL.cbox_command. If this URL variable is detected and it matches the following commands, the tag will execute an internal command and then return a TRUE in the output buffer and nothing else. This denotes a CacheBox command execution. You can create more as you see fit by just implementing them in your own caller tag, remember you are just referencing a tag for reporting.

  • expireCache – uses URL.cbox_cacheName – Executes an expireAll() on passed in cache provider name
  • reapcache– uses URL.cbox_cacheName – Executes an reap() on passed in cache provider name
  • delcacheentry– uses URL.cbox_cacheName, URL.cbox_cacheEntry – Deletes the passed in cache entry from the provider
  • clearallevents– uses URL.cbox_cacheName – Executes a clearAllEvents() on said ColdBox CacheBox provider
  • clearallviews– uses URL.cbox_cacheName – Executes a clearAllViews() on said ColdBox CacheBox provider
  • cacheBoxReapAll – Executes a reapAll() directly on the cachebox instance
  • cacheBoxExpireAll – Executes a expireAll() directly on the cachebox instance
  • gc – Tries to send a garbage collection suggestion to the running JVM

That’s it folks. If all else fails, look at the default skin for guidance or ask away in the ColdBox mailing list. Good luck and happy coding!

Add Your Comment

Recent Entries

BoxLang 1.0.0 Beta 23 Launched

BoxLang 1.0.0 Beta 23 Launched

The latest release of BoxLang, Beta 23, marks a significant step forward in our journey to create the ultimate dynamic language for the JVM. Packed with powerful new features, important bug fixes, and thoughtful optimizations, this update is designed to make your development experience smoother, faster, and more reliable, especially after now starting to take 100s of comments and bug reports from our community.

Luis Majano
Luis Majano
November 23, 2024
TestBox Latest Updates and News!

TestBox Latest Updates and News!

We’re thrilled to have launched the new TestBox website and TestBox 6.0! If you haven’t had a chance to explore yet, visit TestBox to discover updated documentation, powerful resources, and features that make testing more efficient than ever.

Maria Jose Herrera
Maria Jose Herrera
November 21, 2024
Is Your ColdFusion Application Ready for the Future?

Is Your ColdFusion Application Ready for the Future?

In a rapidly evolving digital world, maintaining performance, security, and scalability for ColdFusion applications is more challenging than ever. Whether you're using Lucee or Adobe ColdFusion, legacy systems can become a bottleneck for growth, innovation, and user satisfaction. The need to future-proof your ColdFusion applications has never been more critical.

But where do you start?


The Hidden Costs of an Outdated ColdFusion Application

As you...

Cristobal Escobar
Cristobal Escobar
November 21, 2024