Webobject 5.2.3 works well on Panther but the EOModeller and WOBuilder sucks still! :(

Unlearning the habits of PHP

Man is it a learning curve to get into WO! The old habits from PHP die hard and cause a lot of problems. Before I only had to deal with object for that single page being processed, now I have to manage them for the life of the application. This is a tough thing to get used to and really requires a lot fo patience. I have almost quit and gone back to PHP at least a half dozen times. It does not help that the documentation and reference code for WO is fairly difficult to use for learning WO.

Anyway back to work you loafer! :)

Memory Restored

Well thanks to the help of a lot a great people on the Omnigroup WebObjects list and Apple Discussion forums I found out I know little to nothing! ;) Actually, the problem was in my approach (PHP bad habits) being based on what is best described as trying to do session-less direct action type of design with a session.

So the problem was that I kept creating a new page every time someone clicked on a link. Instead of simply creating an saving the page for later use, or destroying it when done. I still have not gotten that whole destroy part down, but I am working on it.

Well this is really simply a difference in methodology, in a standard WO Application everything is persistent, where in PHP things only live until the the output is done. Once again the difference between a sprinter and a long distance runner.

The key elements so far has been removing redundant EOEditing Contexts, Saving the reusable pages in the Session and not creating new ones every time the section is visited, while also reducing the Page Cache from 30 to 2 (not sure about this one) and activating Refresh on Backtracking. Tomorrow I get to go through the entire app and decide what needs to be saved versus what needs to be destroyed and recreated as needed. Ick! Oh well, just another day learning how to wield the power of WO! :)

Damn I seem to remember too much!

Well I am on the hunt now for a big problem in my WO App. It seems that as you move through it form page to page, it remember everything. In other words, the memory is filled until it crashes. I can not find out why or how to stop it from happening. :(

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!