Archive

Posts Tagged ‘ColdFusion’

Cannot perform web service invocation – Premature end of file

July 12th, 2010 Gareth 2 comments

I’ve been getting a ColdFusion error on a remote server that I’m not getting when testing locally so obviously something is different between those 2 servers. I had thought to just try using a webservice call to the remote server to see if I could debug it better (the error I’m getting in Flex isn’t detailed enough to begin to track down the issue). The webservice I was testing is supposed to return back a complex object, but I was getting the error

Cannot perform web service invocation – Premature end of file

If I tested a return of just a string, it worked, but it did not like returning the complex object. After browsing around via Google for a bit, it seems that it may be related to nulls being returned in my complex object. Now I’m not sure how to fix this other than to add default values to my objects when they are returned (which I really don’t want, or *need* to do as calling it via Flash remoting works nicely), but debugging them via CF, not so optimal.

XMLSearch in ColdFusion – Unusual Behavior

July 8th, 2009 Gareth 5 comments

Well, maybe not completely unusual behavior, but I figured I would document my findings for others anyway.

ColdFusion allows managing of XML documents with relative ease. From the dot notation for traversing an XML document to the various functions to manipulate the document, just about everything is pretty simple when using ColdFusion. Recently, however, I came across an issue with using XMLSearch() It’s probably more of my (previous) understanding of the function call itself rather than it not working correctly, but it still seems a little unusual behavior to me.

I had an XML document that parsed fine.

<cfset INST.parsedData = xmlParse( INST.config ) />

From here I did an XMLSearch for a certain type attribute in my parsed document:

(I grab the first item of the array and set it back to itself so I’m not creating an extra temp variable. The @type is always present in the file so no error will be thrown)

<cfset INST.subObject = xmlSearch( INST.parsedData, "//object[ @type= '" & INST.eachType & "']/") />
<cfset INST.subObject = INST.subObject[ 1 ] />

From here, I wanted to grab a specific item from INST.subObject, but doing the following would always return all of the property nodes with identity=”true” rather than just those specific to the INST.subObject variable

<cfset INST.identityProperty = xmlSearch( INST.subObject, "//property[ @identity= 'true']") />

I guess that the INST.subObject is actually just a pointer of some sort to the original document and when passing the xmlDoc argument into xmlSearch, it then uses the whole original document to perform the actual search.

The solution isn’t too difficult, but may not be completely apparent at first. You just have to create a new xml document of the returned data, thus wiping out any references to the original parsed XML document.

<cfset INST.subObject = xmlparse( tostring( INST.subObject[ 1 ] ) ) />
<cfset INST.identityProperty = xmlSearch( INST.subObject, "//property[ @identity= 'true']") />

INST.identityProperty will now contain the one node within INST.subObject that has an attribute “identity” of true (rather than returning all nodes in the original document with attribute “identity” of true).

Categories: ColdFusion, Errors, code Tags: , ,

Builder Design Pattern In ColdFusion

May 19th, 2009 Gareth No comments

Recently at work, I had been puzzling over object creation and sub-object creation within each of those objects (e.g. how do I create deep nested objects without bringing down my database server and my ColdFusion server trying to loop over everything). After checking out the design patterns books, and the good ol’ Gang Of Four (GoF) book, the solution that seemed to meet our needs the best was the Builder design pattern. This will probably just be a general overview to start with and then I’ll try to get into some of the code, and ideas I implemented to make all of this happen, and in a relatively efficient manner.

In order to create all of the objects, I wanted to have as much autonomy and encapsulation as possible, so that no parent need know how their own child objects are created…the only thing they would know is which child objects make up “themselves” (if that makes sense to anyone other than myself :) ). So, in order to accomplish this, all objects that need to be built start off with a director.

The director knows how to build itself and which objects it is composed of. The director (in my use of the pattern) calls other directors to build the objects that it is composed of. For example, if a User object is composed of a role object, and an organizational unit object, these would both have their own directors, RoleDirector and OrganizationUnitDirector, which would also build them, along with all of the basic properties of the User object, and return them back to the UserDirector to build all of the composed object. The basic properties of the User would be created in a Builder, the UserBuilder, which would also handle (in my case) returning identity values for attaching the role object and organizational unit objects to each User object in the director.

In order to reduce the amount of database calls, I wanted to get all of the necessary objects for all of the top level parent objects at once. For example, if I had 50 users that were being built, I wanted to query the database for role objects for all 50 users, and the same for the organizational unit objects. This way, no matter how many objects I had, the total number of database calls would be equal to the number of objects that composed the top level parent object. In this case a User with a role object and an organizational unit would be 3 total database calls (one call the get the 50 users, 1 to get the role data and 1 to get the organizational unit data). If each one of the child objects had a child object, that would still be only 2 more database calls. If I handled this as each object was being built, it would be 50 users * 3, or 150 database calls…and so on, and so on, so quite a bit of savings to the database. The only problem I then had was how to call the database without using the “WHERE…IN” statement which we’re all told to avoid like the plague, or at least try something else if at all possible.

I had chatted with our DBA to see if there was a better solution than just passing a huge list of IDs to a WHERE…IN statement and he suggested using a solution he came up with that actually parsed out the IDs from a list and places them into a table that can be joined on just like any other table. This is the method he felt would allow us to use the method described above while still keeping pretty good efficiency from the database. I’d also asked about moving to stored procedure calls which should also allow for some improved efficiency…maybe not a lot, but at least it keeps the database management contained in a central area. For testing, I kept with the WHERE…IN, but once we move to production, I’m going to push as much as possible to stored procedures with no WHERE…IN allowed :) …no really good reason to keep them in the code, but several good reasons to push them out.

My final problem was when building the objects in the director, how could I access all of these objects that my other directors had created without having to loop over arrays of objects over and over again in order to get at the data I needed. As structs in ColdFusion can be called via Associative Arrays, I figured why not come up with a solution to create an associate array using some kind of value that is passed in from the calling Director, that could be used as a reference when needing a specific object from that associative array. Thus, taking a note or 2 from Flex, I created the ColdFusion ArrayCollection.

I’m going to stop now, but I’ll hopefully be able to take a few of these ideas and show how I went about creating the directors, builders, the ArrayCollection object, and perhaps even the database portion. I’ll at least go more in depth about the whole layout of things. I’m supposed to document this for work, so perhaps this will become a nice document for them to use also :)

Problem solved transferring typed objects to Flex

January 14th, 2009 Gareth 7 comments

I really do like using the struct method of transferring typed objects from ColdFusion to Flex. However, today I ran into an issue when passing them to Flex from ColdFusion.

I had been following along with Dan Vega’s posts on RocketFM, and I decided to download the code and tinker with it (as all good little programmers should :) ). I had added a FileInfo VO to Flex and one to ColdFusion. Then within the FileManager object, I was returning the newly typed object ( temp['__type__'] = “RocketFM.src.org.vega.FileInfo”; ). However, every time I returned the the data, I kept getting a plain, ol’ generic object. On to the debug steps:

I had recently removed my CF7 install, so I thought that maybe that had messed something up within my CF8 install. I restarted my CF instance ( a couple of times in the end), turned various settings on and off, all to no avail. I tried changing where I was pointing my CFC and my aliasing of them, but everything seemed to be correct there also. I then fired up an old project that I had previously used that I knew was returning typed objects. I ran it through the debugger, and lo and behold…typed objects still. So, I ruled out CF as being the problem (I’m using the same instance across all of my projects…not the best method, but until I get more than 5 different CF projects I’m working on, I should be ok)

I then decided it must be something on the Flex side of things. I got distracted with something else, and just as my mind had begun to relax, the solution hit me…I haven’t included the FileInfo class in my project anywhere (queue head slapping moment). Flex only includes classes that are referenced somewhere in the project, even though the VO was included in the project directory structure, I was not referencing it anywhere in the code (as all I cared about at first was that the data would be returned as typed objects). I then added the import statement and created a private variable that would all me to just reference the VO in Flex. Once this had been added, the typed objects were returning like champs back to the Flex project. A somewhat simple solution in the end, but unless you’re actually thinking about it, very easy to overlook as well.

Inheritance between ColdFusion and Flex

September 12th, 2008 Gareth 6 comments

I ran into a problem today with inheritance in an object in ColdFusion and passing that object back to Flex.  This is the second time I’ve encountered it, and was reminded by an old co-worker of the solution, in one of those “Duh!”, forehead-slapping moments :)

I had created all of my objects in Flex, and then they were mapped by a coworker to the ColdFusion objects on the backend.  He was returning objects back to my Flex components via AMF, but for some reason, the returned object only had the properties for the object that was specifically being called, with none of the properties for the item that it was extending, even though, the properties were being set correctly in ColdFusion.

It turns out that all that was needed was to add the <cfproperty> tags for each of the inherited properties.  Once those were added the previously missing properties were exposed to Flex and passed back correctly.

e.g.
Activity object

<cfcomponent displayname="activity">
<cfproperty name="action" value="" />
<cfproperty name="type" value="" />
</cfcomponent>

Review object

<cfcomponent displayname="review" extends="path.to.cfc.activity">
<cfproperty name="reviewDate" value="" />
</cfcomponent>

If the review object was returned to Flex, it would only pass back “reviewDate”, but none of the properties of the object it is extending. This is due to the review object only having the reviewDate cfproperty. In order to get it to return all properties (from review and activity), you would have to do this:
New and Improved Review object

<cfcomponent displayname="review" extends="path.to.cfc.activity">
<cfproperty name="action" value="" />
<cfproperty name="type" value="" />
<cfproperty name="reviewDate" value="" />
</cfcomponent>

Now you will get all of the review object properties, plus the properties inherited from activity.

Categories: ColdFusion, Flex, code Tags: , ,

New job

June 11th, 2008 Gareth No comments

It was a tough decision for me, but I just started a new job at KForce I had some good friends at eAutoclaims, and the coding was always something new, but hopefully I’ll be able to keep my skills in Flex by writing my own code at home, or perhaps even doing some contract gigs.

I’ll be back to developing mainly with ColdFusion again, but there definitely seems to be some momentum for a push towards Flex.  I’ve still got my fingers crossed that they’ll go to CF8 soon due to its struct/object creation improvements, and the LCDS express data transfer back to Flex.  They’re using the Mach-II framework (which I have done zero work with before, but looks very similar to just about every other framework out there), which will be nice to get my feet wet.

I’m still going to continue publishing Flex content on the site, but as I’m not going to be working with it at my job as much, I may not have as much to talk about (considering my last post was May 22nd, I had better start writing more often or I’ll be posting once a year :) ).

Categories: Professional Tags: , ,

Returning typed objects to Flex from ColdFusion

April 14th, 2008 Gareth No comments

Back in January I saw Brian Kotek’s post about returning typed structs to Flex. When I first read this article, I wasn’t sure how useful it was (I guess I was getting a little confused with the addition of Transfer and AOP in the article, and figured it was just something for that framework). A few weeks later I came across another article about the same idea, and something clicked and I realized just how brilliant this was.

Previously in order to return a typed object to Flex from Coldfusion, you would usually set up aliasing within both your ActionScript object and your CFC

AS:

[RemoteClass(alias="com.mySite.UserVO")]
public class UserVO {

CFC:

<cfcomponent alias="com.mySite.UserVO">

Then, when you transfer objects back and forth between ActionScript and ColdFusion, they are automagically converted to that specific type (along with all of the methods that go along with them). The only bad thing with this method, is that in order to transfer the CFC VO back from ColdFusion to ActionScript, you have to create that object in ColdFusion. Now this doesn’t create much overhead for one object, but if you query the database and return those query rows as separate objects, you have to createObject on each query row, which is an insane hog of memory and server resources. Plus, ActionScript cannot use any of the extra methods that CF is returning, so really anything other than the CFC object’s properties are just extraneous information.

Using the newly discovered technique, you can return the CFC object’s properties as structs rather than having to use createobject each time. You create the properties of the CFC as keys in the struct, such as

myStruct['firstName'] = "John";
mystruct['lastName'] = "Doe";

All that’s needed is to set one extra key in the struct e.g. myStruct['__type__'] = “com.mySite.UserVO” When the items are returned to ActionScript any struct that has __type__ as a key is automagically converted to an object of that type. What’s even more brilliant is if any items within the struct also have an __type__ (e.g. if the user has a company, and that company is returned as a company struct using the same __type__ methodology) then they also get converted to that typed object, so some sort of recursion is happening also.

Now for the sad news (on my part at least). After spending 3 days trying to get this to work on CFMX7 (I had read in a couple of different places that this supposedly would work in CFMX7), I finally found that it apparently only works via LiveCycle or CF8 (which has Flex Data Services Express, I think). After trying everything imaginable, I ended up just having to write a function to convert the returned data to objects. Now I’m hoping that my company will upgrade to CF8, but I don’t think that will be happening. It looks more likely to be Java + WebORB. I’m not sure if this same capability is possible with WebORB, but I’m hoping it does. Certainly is a nice feature to have. Anyway, hopefully this post will be informative for those with CF8 (or LiveCycle) and save those others with CFMX7 from going down the same path as me for 3 days :)

The original post with a little more details is on the CFTalk Mailing List

isDate function for Flex…found!

April 9th, 2008 Gareth 1 comment

Well, sort of…

ColdFusion has a very nice “isDate()” function that allows you to pass in a variety of formats, and check whether the passed in value is a date. I had been searching for something similar in Flex, but had very little success until I started playing around with different functions myself.

I had been writing a custom controller for a datagrid which allowed passing in data from an object or table and displaying it in an editable datagrid. The problem I ran into was that depending on the data returned, trying to set those values back to the object that I was using, caused me some issues (such as trying to set a date stored in a text field, back to the object as a “new Date” value). After trying many different kinds of things, I found that the parse function of date works very nicely.

You can do something like

    if ( Date.parse( myDateField.text ) ) {
        myObj.recordingDate = Date.parse( myDateField.text );
    }

If you pass it a value that is not a valid date, the statement returns false.

Anyway, I had been searching around for a while trying to find something that would allow me to check for isDate and this fit the bill nicely. It also allows you to pass in quite a varied type of date formatting and it still recognizes it. Very powerful feature, it seems.

Categories: Flex, code Tags: , ,

Wrapping up my background

April 5th, 2008 Gareth No comments

This should finish up my technical background and can get on with the good stuff.

After proving that I could actually program given something interesting to do, the web development company promptly offered me a position. It consisted of one man who had been working for himself for several years. I worked on all kinds of projects there, large and small, and was allowed to develop my skills in other ventures, not just ColdFusion. However after several years, I felt myself stagnating and not being challenged enough, so, once again, after getting bored, I decided I should look for something new. I had been looking into going towards something of a more OOP design, and needed somewhere that would allow someone with a self-taught CF background, to begin somewhat a-new but bringing all of the coding background along for the ride.

Enter my current company and Adobe Flex. I had no idea (before beginning the position) how much programming and OOP was involved in Flex and ActionScript. I thought that it was all just Flash (which I never thought of as anything more than a design program). After playing with Flex and ActionScript for a couple of weeks, I’ve got a whole new appreciation for it.  It has challenged me more than anything I’ve done so far, and forces me to rethink my previous procedural style of thinking every day. There always seems to be something that can be re-written better or more logically, or encapsulated to save time later. And on that point, I think this article just about sums up me, my programming, and a good portion of why I do what I do The Nerd Handbook (better than I could explain myself :) )

Anyway, if anyone actually made it this far, thanks for reading and hopefully I’ll have the time and patience (and the code) to post something helpful.

Categories: Personal Tags: , , ,

A Little Background

April 4th, 2008 Gareth 2 comments

Well, not really too little, but hopefully I won’t bore anyone…it’s all great stuff…really
I learned programming in high school, mainly Pascal on UNIX PCs (yes, we all thought that was way too much money to spend on computers that we were just using to type short Pascal programs on), with some Hypercard on Apple II’s, and some TC Logo on any PCs they had lying around. Before this I had really just tinkered with my old Commodore64 and BASIC, so nothing too crazy. Not seeing any of the potential work or monetary gains in this, I switched gears and went with Biology in college. In my junior year, I realized that I really did not like the biology I was learning (that plus my grades weren’t up to par with being that doctor my mum always wanted me to be), I figured it was too late to change course so I might as well finish up and figure out what I wanted to do after graduation.

I ended up going back home and looking for whatever would earn me some cash, that did not involve manual labor (grocery store stocking and assisting my dad with home repairs taught me early about the benefits of an education). I began working as a temp, then worked as a DBA (well, they called me a DBA, but I don’t think MSAccess really counts, but I still keep DBA on the resume :) ) at a mortgage company. I transitioned to their web department (this involved my boss leaving and them saying “Here, you have to do the web site now as well”). Luckily they hired a company using ColdFusion to develop their external site, as I had been having fun with classic ASP before that.

I ended up getting bored just working on the intranet (they used frontpage to manage it), and asked if the web development company needed any help building the site. Not ones to turn down free coding help, they jumped at the chance. From here I got to see (and learn) some not so useful coding practices for ColdFusion (pound signs everywhere), but hey, it was a start and I did manage to fix them going forward. I began working with CF4.5 with MSAccess as the dB, and was well on my way to becoming the CF Guru I am today.