WebObject Builder Bone Yard

Todays fun task is figuring out how to resolve this little problem. It seems that WOBuilder like to keep around the definitions for delete/moved WO objects in the .wod file for the pages it generates. I discovered this last night while retooling some pages. I got a ton of errors and found that the problem was that as I moved and deleted objects the definitions did not always get removed/relocated. One page ended up with 40+ WOTextFields which I now need to go through and find the dead ones. What a pain in the rear! WOBuilder is definitely the black sheep of the WO toolset.

Flattening and Retooling

As I am nearing the initial version of my first major WO App , it had become apparent that I really should have loaded tons of data into the initial database model. Because for both performance and integrity reasons I was forced to spend last night taking object->location structure used in three different tables and flattening them into simple standalone objects. I am sure some WO or SQL guru could find a better solution but it was the most direct and obvious path to the goal I wanted to achieve. So in the wake of last night my lesson for today is load those models up with tons of data right away!

In the end though it reinforced my newly found belief that WO is a time saver. The retooling went mch faster then I had feared. The only downsides I found were that you really have to recreate your model to avoid weird little bugs in EOModeller.

Beyond EO and 17,000 rows

The first big WO project I undertook was morphing a PHP-based Help Desk application into a WO Customer Relationship Management app. This has been quite a learning experience and has definitely shown me the different planning can make.

Unlike PHP, WO actually forces you to design your database structure upfront with the relationships. But coming from a PHP background I fell into the habit of simply assuming that all memory I would need would always be there. Since PHP does not hang around as an application on the server, generally it just smashes on through the script and outputs the results, hopefully dying gracefully at the end. Where WO is an actual living and breathing application hanging in there regardless of what is being asked of it, unless of course you ask too much of it.

This bring us to this tip on how not to use WODisplayGroup and EOObjects to retrieve a complex set of data for 17,000 rows with 6 related tables. Of course during my design process everthing looked awesome and the related information in other tables made agreat deal of sense. During the testing of the initial version thing ran just as smooth as I had hoped. But once I filled the new database with actual data the flaws began to show themselves massively. The load times were sluggish and the List page would crash the application while loading, running out of memory. The culprit in this was the reliance on WO basic use of EOObjects to retrieve the 17,000 records. As a newbie I had overlooked the overhead casued by trying to create this massive number of complex Enterprise Objects jut to view a list. Big mistake!

The solution was simple once I figured it out with the help of the OmniGroup and Yaho mailing lists and archives, but time consuming and frustrating to reach. It all boils down to not using EO, instead using "raw rows" to retrieve the data. The pieces to this solution were spread everywhere but no single place gave the answer to this approach.

The solution is to either programatically or using an EOModeller Fetch Specification tell retreive the only the exact data you want to display as "Raw Rows". This simply returns an array of NSDictionary (key/value pairs) that can then be using in a repetition and/or display group. This trick is to replace the "item" object in your repetition with an NSDictionary instead of the particular "type" of object you may have been using before. If you do not then you will get an error since and NSDictionary is being passed instead of the expected "Type" of object. then edit the different WOstring, etc to use the NSDictionary and manually add the ".variablename" to each object to get the value to show up. This will now display the data to show up as expected. In order to move on and edit the data we need an EO instead of a NSDictionary object and getting one is simple. But here are the detailed steps I used to to this.

- In EOModeller setup a Fetch Spec to “Fetch Specified Rows and Raw Rows”
- Select the desired attributes for each row returned
- Setup my sort ordering unless you want to do it later in the DisplayGroup

- In WOBuilder edit the display group
- Select the Entity, Entries Per Batch, Set Fetch on Load, and choose the Fetch
Spec created above
- Replaced “Item” key object in the repetition with a NSDictionary object
- Manually set each WOString to display the Dictionary and added “.keyname” to
match the attributes defined in the fetch spec.

This is the code I used to create a EO that I could then pass to a component to edit the object.

object = (ObjectClass) EOUtilities.objectFromRawRow(session().defaultEditingContext(), "Entity", NSDictionaryItem);

Well that is todays tip from the world of WO.

This blog will be a little out of sequence since have been learning WebObjects for a couple of months already. But I have learned that WO is more of an arcane science then a widely known skill. Once you learn the power of WO you can see the potential immediately, however the process of learning everything is trying and frustrating at times.

If nothing else it will be a great tool for myself to reference and if anyone else gets something out of this great!