The above
writeup is not quite
correct, and does little to show the goodness that is WebObjects. WO is, by far, the coolest thing to hit the
web development market. It is a completely integrated
solution for web based applications. It includes:
- A core set of Libraries - Foundation (from OpenStep), WebObjects, and typically EOF (Enterprise Objects Frameworks)
- A graphical builder - WebObjects builder allows you to build and layout websites, and manage relationships between your graphical objects and variables/methods in code
- A code editor/IDE type thingy - ProjectBuilder from the OpenStep development tools
- A server extension - An extension for Apache and IIS to handle the serving of WO apps, it really is just a tunnel to fetch and send data to the app and does no processing of it's own.
Basically, it's a complete development environment and application server. At the current time, WO apps can be built using Objective-C, Java, or WebScript (a scripting language based on Objective-C). WO5 will only work with Java. Kinda stupid if you ask me, since Obj-C is a much better language, but hey. On the bright side, at least with a server based app, Java performs reasonably well.
Anyway, on to what makes WO so cool. It's completely object oriented and application centered. Now, there are a lot of things that allow you to do object oriented web apps, but most of these aren't really object oriented. In the case of web objects, it truly is OO. What impressed me most is that you truly have interactive apps that overcome the lack of state on the web. For example, a submit button is bound to method in your code, just like a button in an application would be. To demonstrate, in something like PHP, you would have to do something like this to carry out the proper action:
switch ($submit) {
case "Add":
...
break;
case "Remove":
....
...
}
In WebObjects, you would simply bind the appropriate method to the button or link. Another thing it makes easy is returning a different page. With perl/php, you set your action in a form, and the data is sent to that page. If you want to send them to a different page depending on the results of the form, you either have to do includes or redirect them. With WebObjects, you just bind your form to a method which returns an object. That object can be any object representing any page, with no redirecting or extra effort on your part.
WO, of course, also supports session and application data. Each application has a Session and Application object. The session object is created once when the user first starts using the application, and there is one for each user. This object may contain variables and methods that will be available in every other object in the application. WO defaults to keeping state by URL rewriting which is transparent to the developer, but it can also use cookies. The application object is created when the application is started, and exists in the same context for all sessions for the life of the application. You could, for example, use this to keep a counter of how many active sessions there are.
Now, to expand on this concept a bit and why the Application object works... Every WO app is an application server. Read that again. What this basically means is that when you create a WO app, it is not actually an application that is served up by something else, it is it's own application server that is not dependent on anything else other than a web server to talk to. The libraries you build it with make this transparent, you do not have to create anything to handle the serving of the application (although you can of course rewrite/extend most parts of the process). What this allows you to do is easily keep state on an application basis, as well as do load balancing by running multiple instances of an application which can all talk to each other. That is, in my opinion, damn cool.
Finally, the last thing about WO that I think is really cool is that while the GUI builder tool is very nice and easy to use, you can also completely edit things with just a text editor. The layouts and relationships are XML (or will be, my version still uses custom WO tags which are a lot like XML), and are easy to understand so you are never forced to use the GUI tools if you are thousands of miles away and have to make a quick update with only a telnet client available to you. Yay!
So now to wrap up, let's look at how the thing is written and how it all works. First off, you have Application and Session files, this is where the code goes for those objects discusses above (or empty if you don't need anything). Next you've got an application file, this is just the code to launch the app which in almost all cases is just returns a WOApplication object. Then you've got code for your Main object. This is the default object that is returned when a session begins. And you've got a file for each other object used in the application. For each object, you've also got some assosiated files stored in subdirectories. The first one is your html template, which tells WO how to draw the page. Next you've got a wod file (web objects defenition) that set's up the object. This includes mappings between the html objects on the page and variables and methods in the class, as well as parameters such as text field lengths, etc. Finally, you've got a woo file, which sets up various other things for the object (for example, the version and the class). These things are transparent unless you want to see them, by default you handle relationships and such by connecting them with the GUI builder.
So, hopefully this clears things up! There's more too it, but I'm tired of typing and if you really want to know, the information is out there. Also, keep in mind there is a GNUStep equivalent called GSWeb. It's pretty cool in what it can do, but does not have all the features, capabilities, and GUI tools that WO has, but it's worth playing with. I'll create a node about it some day...