March 12 2008 by
Andrew Powell
After talking to
Ben Stucki at
360|Flex, I decided that I should create a
Google Code site for my code samples and preso posts. I am currently in the process of moving all my os code and preso samples into this repository for public consumption. Going forward, you will be able to find all my code samples there. It is released under the MIT License, which basically means, it's released "as is" and without warranty. Some things will be posted and never updated again. Other things will be updated and improved. There is no set schedule for projects to be updated, it's just a central point for you to find my code samples.
My Google Code Site
Posted in Java | ColdFusion | Flex | Caching | General | Conferences | BlazeDS | Spry | JMS | ColdSpring | StockQuoter | Google | Spring | Adobe | Universal Mind | Hibernate | Air | Hessian | XML | Speaking | 
0 comments
November 20 2007 by
Andrew Powell
Yes, I said cache, not cash.
In my work with Hibernate, I've started using
EHCache as my caching provider. It's small, it's lightweight, it's fast, and it's free. It's also totally written in Java, which is no sweat for us CF developers to implement, right?
I wanted to try to use it in some of my ColdFusion applications, so I built a facade for it. The overall goal of this project is to make this powerful caching engine available to CF developers who do not want to get their hands dirty with Java code. So with that in mind, look for a lot of the complex functionality to be abstracted to a few methods to keep it simple.
It wasn't too difficult to build this, seeing how easily ColdFusion plays with Java. The cache is fully configureable with xml files. You can define how many elements can go to memory, if it overflows to disk, etc. Pretty cool stuff.
I've included the latest beta version of EHCache (1.4) and the required Java lib files. There is one catch though. It requires CF8 because the latest version of EHCache was compiled under JVM 1.5. There are full installation instructions included in the zip as well as a sample xml config file and the XSD document to validate against.
This is just Prerelease 1 of this element. I am already working on a way to use EHCache's
distributed cache. This means that you can easily share your caches across clusters with minimal configuration. Getting that nailed down is my main goal for Prerelease 2. Look for that sometime after Thanksgiving.
Posted in Java | ColdFusion | Caching | General | Adobe | Universal Mind | Hibernate | 4 comments
September 06 2007 by
Andrew Powell
I've been a big advocate of caching within ColdFusion, where needed, to help speed up performance. Until recently, I've been using CFCs to provide my caching mechanisms. i decided that I would try migrating a caching provider of mine to Java and see if it worked. Well, I dropped it right in, in place of the cfc, and the functionality was identical, yet faster, than the cfc provider.
Read more...
Posted in Java | ColdFusion | Caching | 0 comments
November 16 2006 by
Andrew Powell
IE has a problem with caching the results of a XMLHttpRequest call. It will not acknowledge the useCache: false argument in the constructor of the Spry Dataset. You have to use these two steps:
1. Disallow caching in the header of the page that makes the Spry call, not the XML doc itself.
<cfheader name="Cache-Control" value= "no-cache">
<cfheader name="Expires" value="0">
<cfheader name="Pragma" value="no-cache">
2. Setup sometype of dynamic url for your XML. i.e. add the current datetime object to the end of your url as a parameter.
<script type="text/javascript">
var ds1 = new Spry.Data.XMLDataSet(null,null,{useCache:false});
function loadMyData()
{
var d = new Date();
ds1.setURL("http://myserver/myxml.xml?cacheBuster=" + d.now());
ds1.setXPath("root/element");
ds1.loadData()
}
</script>
<body onload="loadMyData()">
...
</body>
This is a known bug with IE and can bite you if you have some dynamic data in Spry that needs to be reloaded at any interval.
Posted in ColdFusion | Caching | Spry | AJAX | 1 comments
October 17 2006 by
Andrew Powell
Ok, so maybe the title was a bit misleading.
One side effect of having CF generate your XML files for Spry datasets is that every time a dataset is loaded or re-loaded, you're making a call to CF. This call to CF is eating up a processing thread, of which there are a limited number. On a high-traffic site, with a lot good number of Spry regions (in one case, dynamic drop downs), you can see ColdFusion's load actually increase b/c it is doing more work "behind the scenes" to build and deliver the XML files to the browser.
Read more...
Posted in Apache | ColdFusion | Caching | General | Spry | IIS | XML | AJAX | 6 comments