Some people think that because Apple no longer supports Windows as a development platform that WO is "dead".

The reality is that WebObjects is supported about as well as any non-Microsoft web application development system is supported on Windows. Look at Hibernate/Struts/whatever. There's no "support" for these systems, merely an "active user community". 

So what we think of as "support" for Windows really means that "the community deals with it". I don't blame Apple for stopping official support. 

In this case, this means using Eclipse and WOLips to develop under Windows. Given that many WO users use Eclipse anyways, its not much of a stretch really.

Here's how to get started.

When you have a particularly thorny problem with WebObjects, you may want to back up a step, because the problem you're having may be one of architecture, not the particular symptom you're experiencing.

A couple of times I've been asked:

How do you handle an optimistic locking failure?

The question always makes me cringe, because if you're asking that question, you have a schema problem, not a problem with WebObjects; you're asking the wrong question. The optimistic locking failure you're trying to work around is a symptom of a system problem. You need to back up a step and look at the bigger picture.

The real question you should be asking yourself is: Why do I have multiple processes trying to write the same piece of data at the same time, and what can I change the schema to prevent that? 

If you ask yourself that question, you may find that the right answer for dealing with the error is actually to turn off the columns WO is locking on, because if your system is correctly designed, then the right answer to an optimistic locking failure is:

1. Failure. The failure is correct.

2. Ignore. The system can robustly handle duplicate changes.

3. Transactions. WO and databases support transactional changes, use them.

I have yet to see a system where dealing with the optimistic lock after it happened was the right answer. 

Ok, so you've got some sort of performance problem. What do you do?

First, measure what's going on. The best thing I've found to use is some sort of sampling profiler that can go and sample all the threads and see what's going on. WebObjects applications have multiple possible bottlenecks, and its much easier to see what's going on with a 10 second snapshot of the stack then hours of speculation. The "sample" tool works particularly well with ObjC, but with Java you can use the Shark tools if you have access to the GUI. 

Next, architect. Now that you know where the application is spending its time, backup a step and look at the system as a whole. Waiting for the database? Well, why are you doing so many database fetches? Can you optimize those away? At Marketocracy, we found that we were spending 1/3rd of the time doing date arithmetic which was mostly due to allocating/deallocating NSCalendarDates. Since we only needed one date per day, rather then optimized the date math, I made it so that we created all the dates since the beginning of the website at startup. 10K of memory made the site 30% faster. 

Similarly, you have to design for scalability. It's not free. If your database is slow, and you have to do the fetches you're doing, then yeah, maybe you need to move the database to a faster machine. But maybe some parts of your system could live with a read-only replicated copy.

Finally, optimize. Sometimes, the right answer really is to optimize the code. But less often then you think. Optimizing can make something 10% faster, architecting can make something 10x faster.

Your home page should be static. Robots, search engines, and browsers are just a fact of life, and 90% of the home page views won't go deeper. Why load up your server generating that page anyways? Design the page using direct actions and let the webserver do all the work.

If you like, you can still have it dynamically generated, just have a cron task to pull the web page once/day using curl and archive it.

Seriously, if you're a WOBuilder user, you need to think about going down to the bare metal occasionally. WOBuilder has its uses, but long term WO programmers end up doing most of their own editing. 

If you have a component that manually pulls its values out of the bindings, if you have a ^ in front of a value name in a .wod file, that tells webobjects to look for that value in the bindings where the component is used. That is:

value = ^ value;

in a component’s .wod file, will let you pass through bindings without having to add accessors or instance variables. This makes it easy to pass through any options on your sub-components out to clients of your component. 

This need not be a declared binding. Since WebObjects will pass through any declaration on a basic dynamic element through to the HTML, any HTML attribute can be used as a setting. You can even change names as you pass them through, so that you can have:

height= ^imageHeight;

So the binding for your component will be “imageHeight=10” but it will be written into the HTML as height=”10”.

The settings for the WebObjects adaptor have this very temptingly named distribution method called “load balancing”.

Don’t use it. Use round-robin, its simple, and it works. If you have multiple webservers, be sure and tweak the round-robin order that you distribute requests to or use random.

Why: The LoadBalancing method leads to a cascade failure because what really happens is that the adaptor forwards ALL incoming requests to a single instance, bringing that instance down. That’s because the load balancing isn’t live, its the load as of the last successful request. 

In Detail: Lets say you have 3 instances, 1, 2, 3. To start, let’s say requests have been coming in slowly enough. So the instances will show up in the load balancing with various loads:

Instance 1 load: 3.4

Instance 2 load: 2.3

Instance 3 load: 4.5

Now lets say your CEO goes on TV, and so 50 people fire up their browsers and jump to your site in the same moment. Where are those 50 new sessions going to go? All of them will go to instance 2, because it has the lowest load. 

Now sure, instance 2 now has a higher load, but that’s the real-time load. The load number that WebObjects uses for the load balancing is based on the value returned from the last completed request. So until the first of those 50 requests come back from instance 2, the adaptor will continue to forward requests to instance 2. 

Even then, it won’t help you, because then it might look like this:

Instance 1 load: 3.4

Instance 2 load: 52.3

Instance 3 load: 4.5

So the next 50 requests will go to instance 1. The same thing will happen:

Instance 1 load: 53.4

Instance 2 load: 52.3

Instance 3 load: 4.5

Now they will all go to instance 3. The same thing happens:

Instance 1 load: 53.4

Instance 2 load: 52.3

Instance 3 load: 54.5

Ok, so now the surge passes, and instance 2 now has the lowest load average again, and completes some successful requests so that the adaptor pulls is lower load average:

Instance 1 load: 53.4

Instance 2 load: 2.3

Instance 3 load: 54.5

It will now be almost impossible for instance 1 and 3 to ever be used again. You’ve gone from having 3 instances to effectively having 1. 

That’s with 3 instances. If your site is as busy as ours so you need something like 45 instances to deal with load, the problem is even worse because what happens is that having all those requests go to a single instance basically destroys that instance. So then the adaptor sends the next set of requests to the next instance in the list, destroys that, etc. 

A cascade failure, which brings down the site. 

Round-robin on the other hand is brutally simple, and always works if you have one webserver, because each instance gets allocated new sessions evenly. If you have multiple webservers, its a bit more tricky, because their roundrobin won’t be in sync. So instead of new sessions going to instance 1, 2, 3, 4, with two webservers it goes 1,1, 2, 2, 3, 3. You can fix this by either having one webserver allocate in reverse order 45,44,43 by editing the XML config file or by just having both use random.

Direct Actions are easier to use than regular actions because you can setup your application so that they don’t require any new code. Component actions require a method per action, which gets tedious quick.

Override performActionNamed() in your DirectAction class to map action names over to pageWithName(), then pull the values out of the request and shove them into the page using takeValueForKey(). Remember that the values coming in from the request are always strings, and all you need add to the page are accessors like setValueS() that convert the strings and store them in their proper place.

If you add those accessors to a common superclass for all your pages, you only need write them once. 

After that, you can define a hyperlink to a page directly from the .wod file. directActionName becomes the page name, and you can simply add ?valueS=value for each parameter the page needs.

If you have a common base class that for all your components, pages, ajax actions, and EOF objects, you can keep from repeating yourself. 

You’ll want your base component class to inherit from WOComponent, your ajax action class to inherit from that, and your page component to inherit from that. 

WOComponent: BaseComponent : BasePagelet : BasePage

BaseComponent should have general utility functions useful for all components. BasePagelet should have functions so that it can pull values out of a DirectAction URL, but it should tell Session not to store the results in the backtracking cache, BasePage should tell Session that it does need to be stored in the backtracking cache. 

Stateless components are a huge win with WebObjects. All of your basic UI components should be stateless. Occasionally, you’ll want to have pages with state, especially forms. That’s fine, just take the extra time with the things you use on every page like navigation bars, etc. 

If you can set all the instance variables of your component to NULL in sleep(), it can be stateless. 

90% of your pages could be built with a URL of just the page name and the primary key of a root object. That is:

/cgi-bin/WebObjects/MyApp.woa/wa/MyPage?pkey=12

Write code to grab a single object out of the editing context using objectWithPrimaryKeyValueEntityNamed() and setup the page’s object via a direct action and you can add new pages with minimal coding. 

If you set as much as you possibly can to NULL in sleep() you’ll get along with the JVM and Garbage Collector much better.

Additionally, on MacOSX, this is an even bigger win, because MacOSX has this three-stage lifecycle for objects. 

If you find yourself marking all of your instance variables NULL, consider making the component stateless. 

AJAX as a technology involves a lot of different pieces. You need to understand the HTML Document Object Model, JavaScript, XMLHttpRequest, how the application server deals with requests, not to mention the particular Javascript library you’ve chosen and what it’s doing.

Once you have those down, integrating with WebObjects is actually very simple, because WebObjects has an outstanding component model that will let you build super-smart components. 

This book can get you started.

WebObjects will happily provide name attributes for form fields but you don’t have to let it. Just add a name=”foo” binding, and WebObjects will name the form field foo instead. If the form field is inside a WORepetition, you’ll have to make sure the name field is unique since normally WebObjects does this for you. 

Similarly, you can put id=”foo” or really, anything=”foo” on any dynamic element and WebObjects will pass it through into the HTML for you.

So if you have a Javascript WYSIWYG editor or other smart component, and you want to attach it to your WO form fields, id=”xxx” is all you need to add to your wod file.

Instead of using awake and sleep, consider lazily building things in your accessors, making your components stateless, and using reset instead. Stateless components are a huge win in WebObjects and most people don't realize it, but their components could easily be made stateless.

Component actions are great when your page has state. Almost anything that involves a form submission works much more simply and fluidly as a component action (links that look like 1.2.3.4). Component actions let you But 90% of the pages on your site are going to be read-only. For a read-only page, a direct action make much more sense. 

Unless there was a <FORM> tag involved, you probably don’t need a component action.

If you’ve built these super-smart ajaxified components, ‘ware the backtracking cache. Component actions rely on the backtracking cache to map numbers: 1.2.3.4 to a specific page state. 1 Ajax-savvy page, followed by 20 ajax requests might burn through the backtracking cache. 

In general, you should setup your pages to cache, and your ajax responses NOT to cache. Alternatively, if your Ajax actions are also direct actions, you won’t have anything to worry about.