[Coldbox 3.8.1) model advice for form fields

I have a general structure question.

Let’s say we have an app like a shopping cart (or whatever) where we provide a form select element with a list of regions or U.S. states (among other items, e.g. countries). If these regions we stored in a database what would be a good way of retrieving them? If the handler function is user.edit we could have userservice.GetRegions and userservice.GetCountries but that doesn’t seem right. These regions and countries are likely to be used for other things so I suppose we could have geoservice.GetRegions and geoservice.GetCountries but that seems odd to have model cfc that just returns regions and countries and never actually does anything with them.

What it feel like to me is some sort of helper maybe. I’ve looked at the 'helper" info I can find and none of the explanations or examples that I’ve seen seem to really be about this sort of thing. I realize I can put it about anywhere and make it work. Just looking for advice as to a proper way to structure these types of things. A config item doesn’t seem right either. ??

Thank you!

That’s the nature of OOP… If the Geo Regions was a service then you could maybe justify it!

I’d do a cache lookup in the handler method for this data and if found set it into your pc, if not found call your geoservice that you have injected into the handler with wirebox and pull the data and set into both your prc and the cache (this type of static data should be cached).

Ok, thank you both. I found this:

* Get some blog categories from the database or cache
function getCategories(){
    var cacheKey = "q-blog-categories";
    //Check if data exists
    if( cache.lookup( cacheKey ) ){
        return cache.get( cacheKey );
    // Else query DB and cache
    var data = blogDAO.getCategories();
    cache.set(cacheKey, data, 120, 20);
    return data; 


at http://wiki.coldbox.org/wiki/CacheBox.cfm

Of course it’s incomplete as the variable “cache” doesn’t exist. So I set up my service as follows -


Does this look proper? In particular am I creating the cache variable in a proper fashion? It appears to work. Just wondering if this is the suggested way to get the cache mechanism into a service. I went over everything I could find on Coldbox’s site pertaining to cachebox and nothing really seemed definitive. Some of it seemed quite old.

Thank you!

​There is no need to inject both, cacheBox can get to the cache by calling a method from it. Unless you need cachebox, then stick with the cache or if you need cachebox, inject it and use it to get the cache.

Also it is not clear what sort of component that this is, but regardless unless you’re dealing with older models / services then stay clear of sending it through the init method.

That is off the top of my head, you may need to tweak the inject, but that gets the OCM so it should be correct. This is provided that this is a model or service that is not legacy code. But as you’re already injecting something else then it is safe to say you can do this as well.

Yes, that worked. Thank you! I had tried something similar but got errors I couldn’t get around so thought couldn’t be injected for whatever reason. This works however. Thanks again!


You’re overthinking it :slight_smile:

In the past I’ve just created a utility or service to handle retrieving that data whenever it is needed. Even if you don’t do the normal CRUD operations, don’t worry. The point of a CFC isn’t that it needs to be big enough to justify its existence. It just needs to encapsulate a bit of functionality somewhere and make it reusable. It’s also a great place to add some caching later since this data never changes. Also, there’s not much functional difference between a service, utility, or helper. They’re all mostly just singletons that deal with a given domain.



The injection DSL namespaces for CacheBox are documented here on our WireBox docs:


property name="cacheFactory" inject="cacheBox";
property name="cache" inject="cachebox:default";
property name="data" inject="cachebox:default:myKey";

Generally speaking, don’t ever use createObject(). While your original code might have created a CacheBox instance, it is a separate copy from the one ColdBox already has created for you and doesn’t use any of the same config.



ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com

ok, thanks. I was looking at http://wiki.coldbox.org/wiki/CacheBox.cfm and saw the following (below). I didn’t really see anything else on that page for getting it into a model and ended up messing around with trying to inject cachebox.system.cache.CacheFactory or something like that. What you sent is perfect. Thanks!

/ Create CacheBox with default configuration
cacheBox = createObject("component","cachebox.system.cache.CacheFactory").init();

If you scroll up right before those code samples, the paragraphs above talk about how those examples are only for people using CacheBox standalone outside of the ColdBox framework.

"If you are using CacheBox within a ColdBox application you do not need to worry about creating or even configuring the framework, as ColdBox ships already with a default configuration for ColdBox applications. "


In summary, CacheBox has two modes of operation:

  • Standalone Framework
  • ColdBox Application

If you have downloaded CacheBox as a standalone framework, <snip…> ColdBox application users already have an instance of CacheBox created for you in every application and it is stored in the main application controller and can be retrieved via the following function:

*// Get a reference to CacheBox controller.getCacheBox();*

Also, have you seen our CacheBox PDF Ref card? It also covers standalone usage as well as within ColdBox, but it is more brief than the comprehensive docs but still covers some of the basic injection DSLs for use within ColdBox:




ColdBox Platform Evangelist
Ortus Solutions, Corp

E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com