This chapter is under construction. Do not expect it to be useful... yet!
Building a good WO application is not just about nice data models and fast algorithms. Making the right decisions from the start and taking advantage of code written by the community is also very important. Here we'll talk about some stuff that you should care about from the start.
WONDER is a huge set of frameworks that fix and extend WebObjects in many, many ways. For more than five years, Apple barely updated WebObjects, and that shows. There are bugs that date from 2003 still unfixed, there are almost no new features. WebObjects 5.4 is a nice release that includes a lot of fixes and some new functionality, but it was only released in late 2007, with Leopard. During all that time, though, the community hasn't been sleeping. The WONDER team wrote thousands of lines of code, and made them available for the rest of us.
The WONDER framework most people use is ERExtensions. This framework is probably the biggest in WONDER, and contains a lot of great functionality you don't want to live without. Some of it's features are:
There are many, many more nice things about EXExtentions framework. You would be really bored if I described only 10% of them. Besides ERExtentions, there are also a number of cool extra frameworks in WONDER. Here are some of them:
By now, you must be thinking why would you make the learning curve even worse by learning WONDER and WO at the same time. After all, it's a lot of frameworks, a lot of information and, unfortunately, not a lot of documentation.
The point is: using WONDER will actually make it easier to learn WebObjects. WONDER fixes a lot of bugs and provides a lot of easier solutions, like EOEditingContext automatically locking, that would otherwise drive you mad if you use pure WO. So, the best option for you to learn WO easily is to use WONDER, at least ERExtensions. Although it seems you are complicating your life, you are really making it (a little) easier.
Many of us, WebObjects developers, are very conservative about upgrading and living on the bleeding edge of the technologies. WebObjects is used for real business, where many millions of Euros are involved. So, normally the advice would be: use the stable version.
Well, WONDER is different. WONDER is updated very fast, and at the same time the WONDER team makes a big effort to keep it stable. There are many small fixes every week, that will improve WONDER reliability, and new big features are usually included as optional, off by default. So, my advice on this is, use the nightly build, or, even better, the CVS head source code. Keeping the source code on disk will make it easier if you want to fix a bug and submit a patch. Instructions for compiling and installing the framework are included in the CVS. To install the nightly build, just uncompress it and dump all the frameworks into your /Library/Frameworks/ directory.
If you are creating a new application, you can just do the following after installing WONDER in your system:
That's it. This will create a new WO application, ready to be used with WONDER.
If you want to integrate WONDER with and existing Application, you must follow all the steps described in the integration page of the WONDER wiki. Note that it's not just adding the frameworks to the project, you really have to make all the code changes described there (it's easy to do, but don't skip it, or you'll have problems).
Many web application are not really a single application. Even if the end user interacts with only one application, many times you need to create back-offices, maintenance application that run scheduled jobs, etc.
When you need to do it, you basically have two options:
It helps keeping most of your code in the model. Maintenance tasks usually have to do complex operations that share code with the main application itself. So, keeping it all in one place avoids code duplication and makes your life easier.
Besides, it's really easy to create a framework:
Then, you need to link your application to the framework:
Done. Now you're project is linking with your framework. If you think this is overkill, think again when you need to do a maintenance application of a backoffice. You'll love the time you spent separating the model code from the application. Also, this helps you write better code, because model code shouldn't need to know anything about the presentation layer. If you try to do that in your framework, you'll get an error, so you really can't do it!
If you don't want to create the model framework now, at least take the advice of keeping the model layer fully independent from the presentation layer. This will make it easier if you decide, in the future, to separate the model code to a framework as described here.
« Overview Model »