John Hagel has a great list of his favorite authors.
All posts by ajohnson
CFMX & HttpServletRequest/HttpServletResponse
I’m doing some research for an article I’m writing for Macromedia Devnet (hopefully to be published in May or June). I won’t go into the details of the article, but part of it deals (tangentially) with CFMX and Java integration. Specifically, I’m using CFMX to call a relatively simple Java API that consists of a couple methods, ie:
doSomething(javax.servlet.http.HttpServletRequest req, javax.servlet.http.HttpServletResponse res, long someObject)
Looks pretty imposing doesn’t it? It’s actually pretty easy to call using CFMX.
<cfscript>
myObject = CreateObject(“java”, “com.thirdpartyApp.OtherClass”);
// retrieve the long value from the third party class
t = CreateObject(“java”, “com.thirdpartyApp.Class”);
longValue = t.SOME_CONSTANT;
// get a javax.servlet.http.HttpServletRequest object from CFMX
req = getPageContext().getRequest();
// get a javax.servlet.http.HttpServletResponse object from CFMX
res = getPageContext().getResponse();
myObject.doSomething(req, res, longValue);
</cfscript>
One interesting to note is that if you do getClass() on the req and res objects like this:
<cfoutput>#req.getClass()#</cfoutput>
<cfoutput>#res.getClass()#</cfoutput>
above you get the following class names:
req = jrun.servlet.ForwardRequest
res = coldfusion.jsp.JspWriterIncludeResponse
and although they don’t look like javax.servlet.http.HttpServletResponse and javax.servlet.http.HttpServletRequest objects, they actually extend the javax.servlet.ServletRequestWrapper and javax.servlet.ServletResponseWrapper classes, which are wrappers (as their names imply) for the javax.servlet.ServletRequest and javax.servlet.ServetResponse interfaces.
Anyway, interesting journey.. great help from Sean Corfield for his post about the getClass() method you can use to find out the type of an object and to Charlie Arehart for his comprehensive Java/CFMX archive.
Solar eclipse
SolarEclipse: a collection of plugins for Eclipse 2.0 Web-Application Development (XML/HTML/JSP).
Going for bird
My main man Mike .NET hooked me up big time today with a set of irons from Cobra, a dozen balls from Titleist and a FootJoy bag. Now I just need to learn how to play golf.
On a related note, today at MINDSEYE we announced our new Content Management product, called Element. Titleist, FootJoy.com, FootJoy.co.uk, FootJoy.com.fr, FootJoy.de, FootJoy.nu (and soon Cobra Golf and Scotty Cameron) are using the ASP version of the product. I know we’ll have more information about the product in the coming weeks, but, gosh darn it, we’re pumped!
MountainDew® LiveWire
MountainDew® LiveWire, coming to a soda fountain near you.
Smack
Smack is “… an Open Source library for communicating with XMPP (Jabber) servers to perform instant messaging and chat.“
OpenOffice & SWF
The newest version of OpenOffice includes the ability to export presentations to swf format. If Microsoft added that ability to PowerPoint, I wonder how long it would take for Flash to become *the* presentation client viewer? [source: Daemonite]
Wedding Day
Spent the majority of the day at Joe and Amy’s wedding at Park Street and reception at Les Zygomates Wine Bar & Bistro. Beautiful wedding and great food. I only wish I could be on my way to Kauai for a honeymoon. The forecast in Boston called for ‘Light Ice Pellets’.
Top 12 Reasons to Write Unit Tests
From ONJava.com: Top 12 Reasons to Write Unit Tests
- Tests Reduce Bugs in New Features
- Tests Reduce Bugs in Existing Features
- Tests Are Good Documentation
- Tests Reduce the Cost of Change
- Tests Improve Design
- Tests Allow Refactoring
- Tests Constrain Features
- Tests Defend Against Other Programmers
- Testing Is Fun
- Testing Forces You to Slow Down and Think
- Testing Makes Development Faster
- Tests Reduce Fear
Definition of Object-Oriented programming
Object-Oriented programming. The C# book I’m reading has an excellent definition; it says “… object-oriented programming encapsulates the characteristics and capabilities of an entity in a single, self-contained and self-sustaining unit of code.” Pretty obvious stuff. So my purely theoretical question for the late night: given an object oriented system with classes that describe entities … where in the system do you put the retrieval of objects? For instance, let’s say I have an ecommerce system that has classes ‘Order’, ‘Product’, and ‘Consumer’. Order will have methods like return(), commit(), cancel(), Product will have methods like getPrice(), updateStock() and so on… The bottom line is that methods are the way we access (getting) an objects properties and also the way that we manipulate an objects properties (setting). So lets say that somewhere in this system, I want to be able to query all the orders in system, returning open orders, closed orders, orders over $500.. It doesn’t feel right to write a method like this:
[java]
public static Resultset getOpenOrders()
[c#]
public static DataTable getOpenOrders()
for the Order object. Where does a method like this fit in the system?