My company has haphazardly upgraded the production server of our website to CF9, and while we were relatively lucky with very few incompatibilities, I am running into one problem that over the last week has caused me a considerable amount of grief.
Our sites use the Coldbox framework with the Transfer ORM, with function inheritance through abstract objects. Previously in CF8, when I would cfdump an object, I could view all of my setters and getters that existed in the object. However, CF9 modified the cfdump function to dump only the metadata for the object. The new CF9 documentation states that there is a metainfo tag that when set as true, should dump inherited objects (like my setters and getters for my database columns), but in this instance, it does not work.
While ultimately this isn't a back-breaking problem, it's become a considerable pain for me as I don't have rote memorization of all the functions in these objects; I'll be looking to dump a function because I know what I'm looking for but don't quite remember the name, only to find that it's not being dumped because of the way it's inherited from Transfer. I've tried the following things so far as solutions without any luck:
cfdump metainfo=true
Creating dump function in the abstract decorator
creating a dump function in the base decorator
Creating dump functions in defined override decorators
We're using the latest versions of Coldspring and Transfer, and Coldbox 2.6.4. Any insight as to workarounds or resolutions would be appreciated.
If you're not getting cfump to do it for you, first thing to do is file a bug at http://cfbugs.adobe.com/cfbugreport/flexbugui/cfbugtracker/main.html
The next thing I would do is use the Component Browser in a separate tab to keep an always ready copy of your full component documentation ready to use:
http://[yoursite]/CFIDE/componentutils/componentdoc.cfm
Faster than cfdump, save, reload, check, undo, save, retest. The component docs should show you all of your inherited methods.
if your still really want the old functionality back and you happen to have a CF8 install somewhere CFDUMP was implemented as a custom tag internaly so you grab the old one from CF8 and port it into your cf9 install.
just copy /WEB-INF/cftags/dump.cfm and rename it as you go..
how about creating a dump function that does this
<cfdump var="#myobject#" label="built-in dump">
<cfdump var="#getMetaData(myobject)#" label="object metadata">
getMetaData() would give you back your getters and setters
Related
I am trying to create global functions in Lucee. I have followed the directions here and have it "Kind of" working. Inside of Application.cfc I placed the following code:
public void function onRequest() {
URL.IsInternalUser = function() { return (SESSION.user.ID ?: 0); };
}
This seems to work fine in some cases but if we need to access this function in a subdirectory that contains an Application.cfc that does not have the function re-defined it will error out saying the function doesn't exist.
The ultimate goal I am trying to achive is to have a cfc file that contains several user defined functions and then have them accessible throughout the entire application without redefining things over and over again.
Is there a better way to accomplish what we want? I ask this because on the page I referenced earlier in the comments section there is a quote:
I concur. Wouldn't surprise me to see it somewhere else in the future.
What I like about Railo's method is that it is completely sandboxed.
Host A's tags & functions libraries never cross/conflict with Host B's
libraries unless they're put into the global server folders. It's the
same way for the virtual file system too and pretty much everything
else (datasources, etc).
It specifically mentions Railo having a way to create UDF but I can not find any documentaion on this anywhere. Since we are using Lucee which is a fork of Railo I figure it must have what Railo has for creating UDF. Hoping someone that reads this can help me out and point me in the right direction.
Railo/Lucee support custom functions. You can declare them in /WEB-INF/{railo|lucee}/library/function/ of the site. Save the function in a .cfm file and name the file the same as the function. The server needs a restart after creating new functions. Here is Railo's blog post about it.
Adobe ColdFusion doesn't support this AFAIK. So you have to store your functions in the SERVER scope here.
I'm using the CreateObject() method to create an instance of a CFC and then interacting with this newly created 'instance'. I'm doing this because that's how it seems to be done, but I don't understand why we do this.
Why can't we just interact with the CFC directly instead of creating an instance of it?
A CFC is just a file with some code in it, so it makes little sense to suggest "interacting" with it, just the same as you might suggest "interacting" with a CFM file without <cfinclude>-ing it or similar.
A CFC defines a component, and to use a component, one creates an instance of it. In some languages - eg Java - one can have static properties and methods, and one can access them via the class rather than necessarily object, but CFML does not have this concept. CFCs define components which are used as objects, just the same as in other languages a class defines what it is to be an object, and to use an object, one first needs to create an instance of it.
You can call the cfc directly using cfinvoke. You just have to realize that cfinvoke creates an object of the cfc first, then executes the method you invoked. Also, once the method is invoked, the object is no longer available.
If your .cfm page is only going to use one method of the component, cfinvoke is ok because there is less code for you to write. However, if you use two or more, it's less efficient because a new object has to be created each time.
In other word, while you don't have to create an instance of the cfc first, it's often a good idea to do so.
I hope you have read OOPs and its practices. CFC is your 'blueprint' (say a car design) and object is your own data model (say a car of blue color (method to set color), with nitrogen filled tires (method to set pressure in tires) and runs on LPG (method for fuel type)). CF allow you interact directly with CFC (CFINVOKE) and you do not have to create an instance each time but it just only make sense that you would not want to go to workshop/design lab each time you want to change a configuration for your car.
I'm running my applications on CF 9. I created a CFC to concentrate my cookie handling instead of all the tags strewn about. It is simple. It has two attributes (name, value), and has 5 methods (setCookie, deleteCookie, verifyCookie, clearAllCookies, and init).
Since I wanted this method to be available throughout the application, I put this code in the onApplicationStart method of my application.cfc file:
application.oCookie = createObject("com.mycookie").init();
When I need to set a cookie in any code file I just call it like so:
application.oCookie.name="testCookieName";
application.oCookie.value="testCookieValue";
application.oCookie.setCookie();
My question is: Do I need to put a lock on this code each time I do this? If two separate users were to be on pages accessing this code at the same exact instant, can I end up with mixed up cookie values being set?
To make your oCookie thread-safe, it has to be a singleton (with no state) that only acts as a thin layer to the <cfcookie> or the cookie scope.
Therefore you should design your com.mycookie so that it accepts application.oCookie.setCookie(name, value) instead. And make sure you var-scope everything and don't store anything in the variables scope of mycookie.
And I don't think you need to use cflock.
If you haven't already, you may want to checkout WireBox.
I am currently in the process of writing a custom DataProvider. Using the Intergrate External Data documentation.
I've managed to show the external data in the Sitecore back end. However whenever I try to view the data in the items I created, I am getting an error
Null ids are not allowed. <br> Parameter name: displayName
There seems to be precious little on the subject on how to create a custom DataProvider on the Sitecore Developer Network.
The example on their website seems to only show how to import a SINGLE item into a static database. However I am simply trying to merge some items into the hierarchy and I can't find any useful documentation.
It seems that one of your methods that should return an ID doesn't. It might be GetChildIds and/or GetParentId.
Nick Wesselman wrote a good article about it gathering all the information including an example on the Marketplace. I think that is your best start. You can read it here.
Turns out I needed to include at the very least, the Fields->Section->Template in the GetParent method. To be on the safe side I included the Fields/Sections/Templates into my implementations of
GetChildIDs
GetItemDefinition
GetParentID
It wasn't obvious that this was the case, since I had in fact implemented the GetTemplates method correctly, and I had expected that should be enough.
Would it be ok to get a CF app to check for a valid database before proceeding to process that request?
This is because there may be instances where the database server may be down or being upgraded, hence an error comes when a db dependant request is made.
If there is no connection to the db server, the user can be safely redirected to a safe page.
Or can cfcatch work?
How can this check be done?
Thank you.
in your onRequestStart method of your Application.cfc file or in an Application.cfm file you can run a simple query to check that the database is available. Wrap the query in cftry/cfcatch. If the query fails, you can redirect the user in the cfcatch, if it succeeds, you can be reasonably sure that your database is "alive".
I've used such a check in one project. Code may looks as follows (not sure if it will work in versions of ColdFusion lower than 8), consider this sample as chunk of UDF written in CFScript:
// service factory object instance
factory = CreateObject("java","coldfusion.server.ServiceFactory");
// the datasource service
dsService = factory.DatasourceService;
// verify the dsn
return dsService.verifyDataSource(arguments.dsn);
Oh, I have even found small note in the code I wrote on my old laptop couple of years ago:
// [performance note] this server check takes 1-3ms at local PC (Kubuntu 7.10, CF8 + Apache2, Sempron 3500+, 1GB RAM)
While time looks like small I have found out that doing this check on each request is not really useful for my application. Any way I have a habit to use the try/catch extensively for errors handling. But if your datasources may cheange frequently it may have more sense.
Adding an extra query to every request to make sure that the database is up is a patently bad idea. A better approach would be to build a "maintenance mode" switch into your application, that you would manually enable when you are doing planned maintenance (upgrades, etc).
If you want to have a "friendly" page displayed when an error (like database issues) occur, then use the onError() method in Application.cfc and/or the <cferror .../> tag in Application.cfm, as a global error handler.
If you are worried the db could vanish, I would implement a "SELECT 1 AS A" query in your OnRequestStart handler that runs only every N minutes. This can be accomplished by using the query caching feature. I'd start with performing the query every 30 min.