Good afternoon. Before I start, I recognize a few faces in the audience. Can I see how many people have already done any WebObjects development before? Would you forgive me for asking the question, why are you here? This is an introductory session on learning to develop using WebObjects. If you've already done a few weeks' worth of WebObjects development, this is probably not the session for you. If anybody wants to take the opportunity to find something more advanced to go to, please do so now.

Okay. What will we cover? This is going to be, for those of you who've been on any WebObjects programming classes, about the equivalent of the first week's worth of WebObjects programming class in about 55 minutes. I wonder, though, if I might just ask if the clock has started yet, just so I can count down.

So, it's going to be necessarily a very rapid run-through. We're not going to be able to go into any great deal of depth on the subject. We're going to cover a little bit about what WebObjects is, how you use it, some of the basic design principles that you use with WebObjects as a technology, some of the main features, and some of the benefits that you get from using WebObjects.

In particular, as we go through, we're going to highlight some of the more useful aspects of the technology. In some respects, WebObjects is already doing, and has been doing for some time, what a number of other technologies are aiming to do in separating the business logic from the presentation layer. What I want to do is illustrate some of that with demonstrations as we go through.

As I go through this presentation, there are a few things I'm expecting of you. The sorts of technologies that WebObjects developers need to know about in order to be successful with this technology are, first of all, Java. It's possible to learn Java as you're developing and gaining experience with WebObjects. Who here just out of interest has not done any Java development before? A few of you. If you have a look on Apple's website, you'll find a document, Java for WebObjects developers.

Many people have found that that's a very useful document for learning just enough Java to figure out how to use WebObjects. It's actually quite a good introductory document just for learning Java itself. It's also useful to know something about databases. So why are databases useful? How do you interact with them? And so on. And, of course, because it's a web-based development environment, it's useful to know something about HTML as well. As important as any of these other technologies, though, to be successful with WebObjects, you need an ability to think in terms of objects.

This is a theme that I'm going to repeat again on a couple of occasions throughout. For those of you who have come from a procedural background, for those of you who are used to scripting and so on, this may mark a fairly major paradigm shift for you, a different way of thinking you'll find quite foreign.

The common theme throughout is objects for the web. What does WebObjects provide for you? WebObjects aims to give you a high degree of abstraction. So we've got object representations of a number of the different state management entities and so on that you'll use during typical web development. We therefore get all the benefits that you traditionally associated with object-oriented design, so reuse, simplicity of concept, and so on. I want to emphasize that last point, simplicity of concept.

One of the, I'd like to suggest, myths that's commonly associated with WebObjects is that it has a steep learning curve. Kudos to Steve Heyman, then, for pointing out that the benefit of a steep learning curve is it means that you learn an awful lot in a short space of time.

What I would also like to suggest, though, is that many people find that WebObjects has a steep learning curve because they do not bring to the table The knowledge that I listed earlier is a set of prerequisites. People who typically have difficulties with WebObjects are people who don't know Java, don't know anything about databases, and don't know anything about HTML. If you bring a knowledge of all those technologies to the table and think in terms of objects, you'll have a much easier time.

So bear that in mind as you approach the technology. Another thing to bear in mind is that having done a lot of training courses using this technology in the past, I've often noticed that people have a tendency to make things difficult for themselves. If at any stage you find yourself struggling with a technology, if you can't figure out how to get things connected, if you can't figure out how to do something, stop for a moment.

Pause. Sit back. Think back to this session. So take a moment, just have a look around the room and familiarize yourself with this environment. Think back to here, and think back to my voice on stage saying, "It's probably easier than you're making it. You're thinking that it's more complicated than it really is." Often to do something complicated in WebObjects takes a couple of lines of code. The difficulty, of course, is figuring out what those couple of lines are.

Let's have a quick recap then on what WebObjects is all about, and in particular, for those of you who might have been to one of the previous sessions or read a bit about the technology and so on, what is WebObjects from a developer's perspective? So as you sit here, what use will you make of the technology? From the perspective that we're looking at it from today, we're looking at WebObjects as a web development environment. So it's a set of tools and a set of libraries for doing web-based development.

As you're probably aware, WebObjects is actually useful for creating other sorts of application as well. So web services, for example, you can use it to create desktop-based applications and so on. But we're concentrating on its initial strength here of building interactive, dynamic websites. The main strength and the main reason that many people are interested in the technology is because it's particularly good at talking to databases.

So if you need to create a dynamic website that talks to an Oracle database, a database or whatever, WebObjects gives you an excellent set of technologies for doing that. It's also especially scalable. So if you bear in mind that, for example, the iTunes Music Store uses WebObjects as a backend technology, that gives you an idea of how robust, how scalable, and so on this technology is. It's been around for a long time, so its heritage goes back a decade or so.

In terms of where WebObjects sits, in many respects, it can be considered as being middleware. If we look to this report card, one of its main goals is to play well with others. So it doesn't matter what web server you use, it doesn't matter what database you use, it doesn't matter what HTML you want to produce and so on, WebObjects fits in with the way that you want to work.

One of the advantages of this, one of the particular benefits of this, and the way the technology itself is structured, is that it allows you to concentrate on the part of the application that you're most interested in. As a developer, you're probably most interested in the Java, the application logic. It allows your database admins to concentrate on the database side of things, and your graphic designers to concentrate on the HTML.

Again, from the developer's perspective, what tools do you use on a daily basis? The main one that you're going to use, certainly on Mac OS X, so there are other options for some of these on other platforms. On Mac OS X, you'll use Xcode, so the traditional Mac OS X development environment. Can I just see, has anybody not used Xcode before? Okay, so a couple of you. But for the rest of you, familiar territory.

WebObjects Builder provides you with a graphical HTML editing tool. You can use others, but WebObjects Builder, we'll see in a moment, obviously has particular strengths for dealing with some of the dynamic elements that WebObjects uses. EO Modeler, finally, is our entity relational mapping tool. So it's going to be the key to figuring out how stuff in the database gets into our application on screen.

Some of the other things that WebObjects gives us as an entire package, it gives us a collection of frameworks for providing object abstractions for most of the entities or things that we want to deal with as web developers, in particular for representing dynamic web elements, that's individual strings, hyperlinks, web pages, and so on, and for doing state management.

One of the frameworks that I'll just mention in passing here is the Foundation Framework. Who's done any Cocoa development or heard of the Foundation Framework in Cocoa? For those of you, again, small number, there's a fairly strong correspondence between the foundation framework in Cocoa and the foundation framework in WebObjects.

It provides you with a set of utility classes for representing numbers, dates, dictionaries, arrays, and so on. In addition, there are a couple of other frameworks. The WebObjects framework itself provides the object abstractions for the dynamic elements, and then there's a couple of frameworks that are bundled together in something called the Enterprise Object Framework, which actually interacts with a database for you.

So that's WebObjects in a nutshell from the developer's perspective. In the remaining sections, what I want to look at are, first of all, some of the underlying design patterns that are going to be useful to you as WebObjects developers. So some of the main ideas that underlie the technology. Then have a look in greater detail at some of the frameworks that you'll be using. So what's in the WebObjects framework, what's in the Enterprise Objects framework. And see then, particularly illustrated using demonstrations, some of the tasks that you'll face on a day-to-day basis.

So, turning first of all to the concepts, to reiterate a point that I made on several occasions up until now then. Objects, objects, objects. Think in terms of objects. Many of the tools that you may have used in the past will require you to think in procedural terms, require you to do a lot of data munging or whatever to figure out what's going on in your application. WebObjects is, as the name implies, object-oriented.

So, we have object abstractions for web page and things on a web page that you can send messages to. We have object abstractions for records in the database. So, when you retrieve information from the database, you get objects representing the records. Even the HTTP request and response are abstracted out into objects. So, for those of you who may in some environments be used to doing your own parsing or messing around with HTTP request and response, don't have to do that. We'll see an illustration of that very early on. And then, of course, for state management.

So why are we interested in state management? Again, thinking about WebObjects as a traditional web development environment, one of the things that many people want to get out of a web environment is some sort of state management. If you're putting up a website, particularly commercial websites these days, you want to have an idea of a user, so that a user has a shopping cart that they can put stuff into and later give you a credit card number that you can charge, that you can earn some money. I know that's possibly not part of the traditional web development environment, but there you go. So WebObjects provides you with state management abstractions for an individual session, for an individual user, and then for an application, and then at the level of an individual page.

The design patterns, the main ones that you need to bear in mind, first of all, Model-View-Controller. Has anybody -- who's heard of Model-View-Controller before? This is going to be something if you go to many of the other sessions, particularly the Cocoa sessions, for those of you who are interested, you're going to get drummed into during the remainder of this week.

The idea fundamentally behind Model-View-Controller is the separation or the factoring out of function. As the name implies, you have different sorts of objects in your applications. Model objects, which typically correspond to records from the database. View objects, which in our case are going to represent web pages or dynamic elements within a web page. And then a controller object, which mediates between the two. The idea is that you should not pollute your model objects in particular with any knowledge of the user interface.

This makes them particularly reusable between applications. Similar story then with the view objects. If a view object is not particularly bothered about what sort of data it's presenting, they're reusable. The controller is a glue code which sits between the two, and typically that's unique to each individual application.

Another important design pattern, key value coding. Probably again familiar to some of you from the Cocoa environment, the idea behind key value coding is that it gives you a means of accessing an object's properties using the name of a property as a string. So if a person has a first name property, rather than using an accessor method or accessing an instance variable of that object directly, you can use a message such as value for key and then pass in a parameter first name as a string. The main advantage of this is that this gives you very good flexibility at runtime. You can determine at runtime what property of an object is that you want to access.

This is what gives WebObjects an awful lot of its flexibility. Another point to bear in mind here is that in addition to asking for just a single property, you can follow what are known as key paths. So if a person has a relationship to their manager, and the manager then is another person who has a first name, you can ask a person object for their manager's first name by using the key path manager.firstname. So key value coding gives you a means of traversing relationships.

The final design pattern that I want to draw your attention to here is one that's perhaps a little bit unexpected: target action. Again, anybody from the Cocoa development environment or from any other development environment who's heard of target action before? A very simple idea, basically, that when, and certainly in a desktop application, if you click a button, a message is sent to whatever object you've connected it to.

What we'll see, I think, straight up very, very early on is that with WebObjects, you get a development environment that's very much like, in many respects, a desktop application development environment. When you click on a button or a hyperlink, you can cause an action message to be sent to an object.

To return to frameworks, for those of you who haven't come across the jargon word framework before, you can think of a framework as being pretty much like a class library, a collection of objects. The main differences are, A, a framework may contain other resources. So it may contain HTML, it may contain documentation, it may contain EO model files. We'll talk about those later.

In addition, one of the main things that may affect you as developers here is that programming using frameworks is philosophically rather different to some of the programming that you may have been used to. If you're used to procedural programming or scripting or whatever, typically you're used to being in charge.

at the top of your program, you'll deal with getting information from the HTTP request. You'll do something with it, and at the end, emit HTML, perhaps.

People don't, or developers don't feel that they're in control of their application. If you find yourself in that situation, again, sit back, don't worry, relax. The reality is you're not in control.

But that's a good thing. What, again, I hope we'll see very swiftly is that letting WebObjects take care of the heavy lifting frees you from a lot of that responsibility and allows you to concentrate on the more interesting things. Which would you rather deal with, HTTP requests and responses or the actual application logic? I suggest that dealing with the application logic is going to certainly be a more productive way of using your time.

So, turning first of all to the WebObjects framework, and we're just going to discuss it a very little bit before going into a couple of demos. Remember that the WebObjects framework is the framework that contains the object abstractions for the dynamic elements you'll have on a page, a page itself, and provides the state management classes.

The base method, the root, I'm sorry, the base class for web pages and indeed for parts of web pages is Woe Component. As you create web pages or new web pages, you're going to be creating new instances or new classes subclassed from Woe Component. Let's illustrate that. with the first demo. So, quick reminder here.

I'm not expecting here for everybody to go away being an expert WebObjects developer. What I want you to get out of this is a feeling for what WebObjects development is about, what some of the typical processes are, and so on, so that subsequently, if you want to take a look at the product and start using it, you can feel comfortable having seen somebody else do this and seen that it's not particularly difficult.

Malcolm Crawford In Project Builder, I'm going to start off by creating a new WebObjects application that I'm going to inspiringly name WebObjects. Hello, Woe World. I'm not going to type it correctly. And because this is a demo, let's just ignore all these parts for the moment and go and look at the... So, just out of the box, Xcode gives us a project that contains a lot of stuff.

Let's just start off by building and running that to see what happens. Well, it goes away, builds, runs, and for your convenience, it starts up and displays the web page. At the moment, there's nothing in it. That's probably unsurprising. We haven't done anything. What do we have to do to actually configure this and get something to display? The page that we're seeing first of all is the main page.

Out of the box, the project template provides us with a main component, which comprises a number of different files, including this main.woe thing. Which is the template for the first page. If I open that in WebObjects Builder, straightaway I hope you can see that WebObjects Builder is a graphical HTML editing tool.

Since that's the first page that's displayed, in the fullness of time, I get the text that I wanted. That's not particularly exciting. I said that WebObjects was a dynamic

I can replace Woe World with a Woe String.

Let's see what happens when I click Add here. If I go to my Java code, We'll see that I've got a class called Main, which is the object that underlies this page when it's generated, that currently just has a constructor method.

When I say Add, let's add some accessor methods as well, you'll see I get an instance variable added and suitable accessor methods. In WebObjects Builder, I also get username added here.

The value for this string to be whatever username happens to be at runtime. In my constructor, let's say then I... Set that to be something not particularly dynamic. Oops. And build and run the application.

I'm going to pass on for the moment figuring out how we can actually get the user's name directly. It's going to come in the next session. So let's for now see how can we get something a little bit more dynamic than that. Let's suppose we want to display the current time.

Again, we're going to use a woe string and add another key for current time. In this case, though, This is one thing to just pause and think about for a moment. In this case, I'm only going to define an accessor method. This is, in effect, a read-only value. I don't need to have an instance variable for this. I just need a means of generating this value. So I'm only going to have a get method, current time, which is going to return an NS timestamp.

And I can connect that up. And without going into too much detail here, associate a date format with that. So that specifies how the time is going to be represented on the page. In my current time method then, rather than returning an instance variable, I'm going to return a new NS Timestamp. So when a new NS Timestamp is created with no additional Constructor arguments, it'll be set to the current date and time.

So if I build that,

In particular, a couple of things to notice there. We're sitting back being the passive recipient of messages. This illustrates the framework aspect. We're not actually doing anything very active. In particular, has anybody spotted where the HTTP request and HTTP response?

Rather than just displaying hello on the first page, I want to display a hyperlink, a hyperlink that's going to take us to a new page.

Hyperlink, you might guess straight off, is represented by an instance or a dynamic element, Woe hyperlink. If I select in this toolbar, I surround the text that I've selected with a hyperlink by clicking on the Woe hyperlink button. A hyperlink is associated with an action. So, to my web page, I'm going to add an action this time rather than a key.

The action method is going to be called GoToWelcome, and it's going to take us to the Welcome page. This is important because I'm getting a step ahead of myself here, deliberately. I want you to watch what happens when I add this. Here, go to welcome gets added to the list of variables. Because WebObjects Builder doesn't know any better at this stage. I'm going to specify that the action associated with the hyperlink is go to welcome and save that. And now I'm going to add the welcome component.

And a means of setting it, because I'm going to say, "Welcome username." If you watched or if you're watching very carefully when I saved that, go to Welcome.

A WebObjects component page and takes no methods is counted as an action method. Notice in the action method that was added to the Java file, I get a helpful little hint here, initialize your component. If there's an initialization that I want to do, I can do that after I've created the instance of the page I'm about to go to.

So again, we get our sort of dynamic content, click me, and I get taken to the next page with some new information on it. So that was a very quick run-through. Let's have a quick recap of what it was that we saw. First of all, actually, let's just illustrate one other point here.

I sort of mentioned that A component comprises a number of different files. There are three files that we're primarily interested in in a WebObjects page. First of all, the HTML that defines the template for the page. The Java file is the underlying business logic for that page. And then there's a WAD file. The WAD file is what defines the mapping between what's in the dynamic elements and what's in the code. The main component is created by WebObjects automatically.

points to make about the HTML file. Firstly, remember that WebObjects tries to play well with others. Just because you're using WebObjects does not mean that you can't use other web-based technologies as well. So if you want to use CSS, if you want to use JavaScript or whatever, you can use those technologies in a WebObjects-based application. The only thing that's different about a WebObjects page is that it includes a set of WebObjects tags to represent the dynamic elements.

The dynamic elements that we've seen so far, WoW String and WoW Hyperlink, later on we'll see WoW Image. He's got a collection of attributes, each of which you can set graphically using WebObjects Builder. The Java file then is the business logic. You can put whatever instance variables you want into the page. You can put whatever methods you want into the page and so on.

The only difference about some of the methods is that some methods may be action methods. Action methods have no arguments and return an instance of a subclass of WoE component. These are what you use for navigation. The WAD file then is just a simple text file that binds the two together, that specifies what attribute of the Java page is used for what attribute, such as the value, for example, of a string.

To go into some new areas then, let's have a look at state management. Typically, when you deal with a web-based application, you're interested in managing users. When a person comes to your website, you want to keep track of them so you can find out what products they're interested in buying and so on. Sometimes you need to maintain application-wide state.

WebObjects provides you with abstractions of both of these, as you might expect from the names here. A session represents the current user, which you can access from a page using a static method session, which simply returns the current session, whoever it happens to be. You don't have to do any work in figuring out who the current user is. Similar sort of thing with the application object. If you want to add states to the application object, you can access the application object from any page using the application static method of the application class.

If you're dealing with dynamic content, you typically need some means of retrieving information from the user. So, as you might expect from a web-based application, we have abstractions for a form on a web page and text fields and so on, and also be able to retrieve information from the user. We also have a Submit button, so a Woe Submit button that you can use to allow the user to submit their information. And again, let's straighten that in a demonstration. So going back to our previous application, rather than just click me, I want to add a form.

This time, however, I'm not going to collect that information on the current page. Username is probably something I want to collect at the level of the application.

I'm going to show you how to build a WebObjects application using the WebObjects application. I can rather happily remove code. I don't now need

From the second page that I'm going to, I'm going to get it directly from the session.

Again, build and run. Thank you very much. I hope that today or tomorrow you will get a collection of all of these examples on the downloadable disk image. If you haven't been following just now, you will have the examples to have a look at later. Plus, there is a wealth of documentation already available online.

So, where do we go from here? If we have a look at a little bit more about some of the other dynamic elements that we can use, there's a whole range of different dynamic elements that WebObjects provides you with. In addition just to strings, hyperlinks, and so on, in particular, a repetition to allow you to iterate over the contents of an array, conditional to allow you to specify whether or not, depending on what the current circumstances are, a particular part of a web page gets displayed.

We have support for checkboxes, radio buttons, and so on. In particular, then, we have support for partial components. The main page that we've been creating so far, or the welcome page, could actually be subparts of a page that we can reuse in different applications or on different pages.

One of the more exciting ones in some respects is the Woe component content, which I urge you to have a look at at some stage, which can represent the template for a page. We can actually have dynamic templates for our pages as well. The only one I want to have a look at just for now is the Woe repetition to illustrate how that can be used to iterate over the contents of an array in, again, another demo, this time starting With an existing project. So in this project, I've already defined a session class that creates for me an array of person objects.

In my first page, I want to display their list of all of the people in that array, and I'll do that by adding a woe repetition, which will iterate over all of the people in that array to be able to iterate over those I need a variable which will be set to each of those in turn, and that's going to be a variable of type person. You don't need accessor methods. So for each person in turn, I want to display their full name.

If I build and run that application then,

I can surround the person's name, or each person's name, with a hyperlink to -- let me just remind myself -- select A person. So the action method that will be invoked when the user clicks on the hyperlink is select person.

What that will do is go to the next page, which is going to be selection, and pass current person as a selected person. The selection page, you can probably imagine, is going to display the WebObjects application The name of the selected person. So, I'm passing information from one page to the next.

So dealing with iterations or repetitions within WebObjects turns out to be very simple if you think in terms of objects. Final thing, just to add here, to add a little bit of substance to it, let's add The ability to display a graphic. Another accessor method, That's a read-only value that simply returns the person's name with the suffix .jpeg. Which I can then bind to the file name of a WoW image. In the resources for my project, I've got a series of images.

So when I select an individual, I can see their picture. And so on. So I hope you're getting the feeling from this already that it's a fairly easy development environment, in particular very interactive. So there's not a big turnaround time. You can very quickly see the results of what it is that you're doing.

The final thing that I want to come onto is what many people regard as the crown jewels of this technology, the database access layer. Database access, as I mentioned, is mediated through the Enterprise Objects Framework. EOF, as perhaps sometimes confusingly it's referred to, is the collection of objects that mediate between what's in the database and the objects in your application. Loosely speaking, you can say that a record or a row in your database is going to correspond to an object in your application. In your database, you have tables and either records or rows, depending on your terminology. In your application, you have classes and instances of classes.

EOF is what maps the two things together. Typically, you're dealing at a high level of abstraction. One thing I want to reemphasize here, and something that applies throughout WebObjects, is that even though you're using typically a high level of abstraction, you are not precluded

Even though you're using WebObjects, you can still use raw SQL if you want. You can still use JDBC. You can still get the HTTP header information and so on if you want to, if you feel that you need to.

The other vital thing about EOF is that it provides a great degree of management for you. I said, loosely speaking, an object in your application corresponds to a record in the database, or vice versa, because if I simply say that a record in the database corresponds to an object in your application, there's a temptation to think from that that your entire database is going to end up in memory.

That is not the case. One of the things that EOF is particularly good at, for those of you, did anybody go to the core data presentation just now? When Andrea spoke just now about faulting, the same technology applies to EOF. You only retrieve into memory using EOF those records that you actually need.

If you are collecting a selection of persons from a person table in your database, you only get enterprise objects created for those persons that you retrieve. If a person has a relationship to a department, Until such time as you ask a person for the department to which they belong, the department record is not fetched from the database.

So, EOF puts bounds for you on the object graph that you create. In particular, it's We'll see illustrated in a couple of slides time. EOF also manages relationships between objects for you. How many people do database access? Who uses SQL here? Okay, so you're probably familiar with the concepts of primary key, foreign key, and so on.

We'll see that the way that relationships are represented in objects is very different to the way they're represented in a database, and EOF needs to do some extra work for you. How does it do its work? Well, again, for those of you who were at Andreas' session, it relies ultimately on a model. One of the key parts of developing your application is that at the outset, you should create an ER model that defines the mapping between what's in your application and what's in the database.

You can also create custom classes to represent your data objects. You don't have to if you don't want to. EOF provides for you an EO Generic Record class, which is able to represent any sort of entity. Typically, however, in order to add value, you'll do some customization. It also then provides you with a whole infrastructure for actually accessing the database for making changes to objects and then saving those changes back to the database should you wish. Ultimately, as I mentioned, though, everything is basically founded upon the EO model.

The EO model, you edit graphically using the EO modeler tool, which I'm not going to demonstrate now, I'm afraid. The picture should show you that basically it's an entity relationship modeling tool. With it, you can specify what class in your application is going to be used to represent what table in your database and what columns.

In your application, your database rows or records are represented by instances of enterprise objects. We have EOGenericRecord, and I mentioned on an earlier slide, EO Custom Object. EOGenericRecord is rather like a data dictionary. It's capable of representing any sort of entity.

As a historical footnote, it happens to inherit from EO Custom Object. In your applications, you'll typically just subclass eogeneric records should you wish to do so. In a subclass, you can add whatever custom logic, whatever behavior you want. Again, for those of you who are at Andreas' session, this corresponds to NSManagedObject in Core Data.

Some of the behavior that you might want to add may be very straightforward. If we have a person class, it may be that you simply want to have a consistent means of representing a person's full name. So a bit of custom logic would simply be to implement a full name method, which returns a concatenation of first name and last name.

If you want to edit enterprise objects, Thinking back to what I said about WebObjects as a technology as a whole, you're just dealing with objects. What do you do when you want to edit any other object in Java? Simply send a message. If you remember also what I said about key-value coding, You can edit a given enterprise object by simply using key value coding methods, such as takeValueForKey.

So you pass in as arguments the take value for key method, the new value, and the name of the attribute that you want to change as a string. Or, if you've implemented your own custom subclasses of Enge Generic Record, which have custom accessor methods defined, you simply call a relevant accessor method.

An important point here is that a similar sort of thing works when you're manipulating relationships as when you're manipulating straightforward attributes. WebObjects even handles many-to-many relationships for you. So for the DBAs amongst you who had to deal with join tables up until now, you do not have to deal with join tables using EOF. It's all handled for you, provided you've specified the model correctly.

So, if you're using, if you have a relationship, say, between a movie entity and a studio entity, and you want to set the movie, sorry, it's the studio to which a movie belongs, if you had a custom subclass of the original record, you might simply send a set studio message to a given instance of a movie class. There's a little bit extra work that you might have to do if you have too many relationships.

for Too Many Relationship to set the movies for a given studio, you might have custom methods, add to and then name of relationship, and remove from name of relationship. One of the issues here, though, relates back to the issue that I mentioned about the way that relationships are represented in objects versus the way that they're represented in your database.

If you remember in a database, a relationship is modeled by having a foreign key in a table. In the object world, things are a little bit different. With objects, we have references, whether it be directly to an instance of the destination of the relationship, or a reference to an array that contains a collection of instances of the destination of the relationship. Therefore, if we want to assign, in this example, an employee to a different department, Our employee, Jackson, happens currently to belong to the Events department.

If we simply tell Jackson that you're now in sales, if you think about this in terms of the real world, if all that we do is tell Jackson, his current department doesn't know that he's been reassigned. Moreover, the new department that he's going to doesn't know that he's being reassigned. We have to explicitly tell each of the two departments about the move. It's a similar thing in objects.

On the database, all that we would do is change the foreign key in a table. In objects, we have to be more explicit and actually send messages to. The other two departments. If I go back, one of the things that I skipped over at the end of this slide was that there's actually a rather long method name, AddObjectToBothSidesRelationshipWithKey, which at first is rather intimidating. When you start using WebObjects, you'll learn to like it because what it does is it manages all of this stuff for you.

So for those of you who are DBAs or have dealt with databases in the past, this is a fairly high degree of abstraction. You don't have to worry about primary keys. You don't have to worry about foreign keys. You don't have to worry about maintenance of integrity of relationships. EOF manages all of that for you. A lot of that's managed for you by the editing context. The editing context can be thought of basically as a sort of scratch pad. It's the object that mediates between you and the underlying connection to the database.

So it's the object that you turn to when you want to fetch stuff from the database and save stuff back to the database. It also observes all of the objects that you've retrieved from the database, looks for changes to them, and then in particular allows you to undo those changes should you wish.

You can get hold of it, sorry, each session, as you might expect, so every user wants to have their own collection of products that they're buying and their own shopping cart and so on, each session comes along with its own default editing context that you typically turn to when you want to do something like fetch information from the database. So to fetch information from the database, you have to specify what it is that you're after. You specify it using an object, again, known as a fetch specification.

Sending a message, objects with face specification, to the editing context returns to you a message

An editing context to ask the database through the intervening objects in EOF for, for example, all of the movies whose title contains the word Nemo. We might also add that we want to have the objects returned sorted by title. So we simply send a message, object specification, pass the parameter, the specification that we specified to the editing context, it returns then a collection of objects.

The fetch specification itself contains all the information that EOF requires to determine what's going to be got from the database. Minimally, we must specify the name of the entity, so what table is it in effect that we're interested in. We might also want to narrow our search. So maybe we say, as in this case, we're only interested in movies whose title contains the word Nemo.

This bit of code is a little bit dense, so apologies for that, but this bit of code basically does all of that for us.

So first of all, get hold of an editing context in the first line, create a new qualifier, Create a new set of sort orderings. It only contains a single sort ordering here. And then create our new fetch specification object and send that to our editing context. So, didn't give you very long to have a look at that, but I've got a prepackaged demo that does that. You'll notice that I've already got an ER model in my application.

I've already set up a repetition that's going to iterate over a collection of movies, one at a time, and display the name of the studio in this case that I'm interested in for no particular reason. If I have a look at the code, the code is basically the same as, in essence,

Create a qualifier, create a set of sort orderings, a fetch specification, and then use that fetch specification.

This is an introductory to intermediate-level session. You will see demonstrations of the WebObjects tools, design and flow of a typical WebObjects application, and a review of deployment scenarios that allow you to understand how to best take advantage of this technology. Is this going to be more kind? Thank you. That's more interesting still.

Now, I'm going to guess that this has something to do with some of the other setup that was done after I set my stuff up. What's happening is that for some reason I can't actually connect to the database. I suspect that it has something to do with the IP setup that was done afterwards. Such is life. And I don't think that there's anything that I can quickly do to rectify that, which is, shall we say, unfortunate.

I'm guessing from the lack of responses there that that's the answer, so I hope you will forgive me. That's going to be... Even less impressive a demo than we might have expected. If you could imagine that rather than a collection of error messages, This web page displayed a list of all of the movies that we'd fetched.

I hope you might agree that had it worked, This is actually not very many lines of code to go to a database, fetch some information, and collect a series of records back from the database. The subtle point that I wanted to make here, that I said I was just glossing over a little bit, was notice that in our qualifier, we'd specified that we're interested in the studio name for the movies.

So rather than just searching by title, - Which is searching within the single table that we were interested in, we're actually traversing a relationship here. So we're traversing the relationship from a movie to

We're traversing relationships in this query as well. Not particularly difficult. So for those of you who've used other environments, particularly anybody here use DJB? Anybody care to do a lines of code comparison between what we should have achieved here, had the database connection been up, and what you would have had to do in EJB? Fewer lines of code here? Honestly, there's somebody nodding in the front row.

So with that, I said it was going to be a very, very quick run-through. The goal here was just to give you some sort of a taste of what it's like to do WebObjects development. And as you can see, there's occasional frustrations with it. But I hope that you might also see that, compared with some environments that you're used to, it's actually quite fluid, very responsive, and in particular, there's not many lines of code to actually achieve quite an interesting result.

The example that I've been through, I will get up on the connect.apple.com site as quickly as possible after this session. It may be tomorrow evening that it goes up. In the interim, though, there's plenty of documentation available online. So WebObjects is very thoroughly documented. Basically, the main place that I would suggest that you start with is the aptly named Getting Started page.