Hello. As he said, I'm Mike Gobbi. I'm one of the trainers here at Apple. And although I usually train in front of crowds of people, this is a first for me for a crowd this large. So if I seem a little bit nervous, well, I'm not. I'm just bluffing really well.

How many people here have ever used EOF WebObjects or any of these technologies before? Almost everybody. How many people here never have? Okay. Hopefully the people who never have will give you a quick sketch to go into this, but my basic assumption in this exercise is that you either have a basic idea of what's happening, or if you don't, you come and watch the previous demonstrations, you'll have at least a few minutes old knowledge of what's happening. I'll be talking about persistent object modeling with EOModelers, which is the technology we use to connect from a database through the web application and out to the browser on the user interface.

So WebObjects is a new technology from Apple that lets you build dynamic websites. And most of these websites are backed up by relational databases. Typically you'll have an e-commerce application that lets customers make purchases. You need to know what products can be sold and that's all stored in a relational database. And EOF allows the persistent access to that data within your object-oriented application.

Mike Gobbi In this presentation I'll talk about the basics of what is EOF, it's Enterprise Objects Framework, and what is WAF, the WebObjects Framework, and how these two technologies can work together to build your application. I'll talk a bit about EOModelers, the tool that you actually use to configure your application and tell it how to connect to the database.

I won't be talking in this too much detail about how databases work. So I'll give a quick sketch of the basic technology of what a table is, what a row is, but I won't go into very much detail beyond that. So what are the basic concepts we need to know? Well first we need to know the structure of a Web application, and the architecture of WebObjects and Enterprise Objects and how they fit together to make your application. And finally I'll talk about some entity relational modeling concepts.

Start off with a web application. Typically, this is a three-tier model. On the first side, we have a browser. In the middle, we've got your web application. And finally, backing it all up, we have a relational database. When some user somewhere on the internet types a URL into the browser, an HTTP request gets sent to your application. Your application will then send a SQL request off to the database to request the objects it needs to service the HTTP request.

The SQL database gives rows of data back to your application as simply raw data. But because this is an object-oriented application, those rows of data will get turned into objects that your application can use. Your application then takes those dynamically fetched objects and turns them into HTML to get sent back out to the browser. And all of this is something that we call the Request Response Loop.

Now WebObjects does more than just this. It also keeps track of the unique editing context for every user. So we already have one user who has fetched information from the database. Perhaps they've fetched the record and they're about to make a purchase, so we've fetched the number of available records from the database. But while they're making the decision, some other user comes along.

and that other user will send a request to the application, which will result in a SQL fetch and some data coming back to the WebObjects application. And even if the same rows are retrieved that have already been shown to the other user, EOF will create a completely different pool of objects that are stored in a separate editing context.

And that way the two users don't interact with each other until one of them actually tries to make a purchase or does something that will commit their changes to the database. And finally, those objects will turn into HTML to get sent out to the second user. So the WebObjects Framework represents the top half of this object-oriented application. The WebObjectsFramework knows how to take these enterprise objects and turn them into HTML to be displayed on the web.

The Enterprise Objects Framework, that's the part I'll be talking about in this presentation, knows how to talk to a database, fetch in rows of data, and then create objects that WebObjects can then use to produce HTML. So we have a layered architecture. At the very bottom, you'll have third-party database libraries. The Oracle database libraries, standard ODBC libraries, whatever third-party libraries you need. On top of those we have the adapter layer, which knows how to connect to the database and just fetch raw data.

The database layer, which knows all about the classes in your application and knows how to turn that raw data into an object for you to use. The Control Layer, which keeps track of what you've done to those objects. So if you make changes, you can eventually save those changes back into the database or maybe undo or redo the changes. And then finally we have the WebObjects Framework on the very top. And the WebObjects Framework knows how to take those objects and present them to the user in HTML.

And the database and adapter layer are what we'll be editing using EOModeler. All of the changes that we make to describe how the database and the application will interact live inside something we call the model file. And the model file just describes a straightforward one-to-one relationship. This class goes to this table, this column goes to this instance variable, although it can be more complicated if you have a class that spans several databases. And to edit the EOModel file, we'll use a tool cleverly enough named EOModelr.

And EOModelr knows how to configure the adapter to say which database you're connecting to. It knows how to work with the schema to edit the entities, the attributes, and the relationships. And it can identify the various stored procedures and let you create fetch specifications to be used later when you actually run the application.

the first step in EO model will be to configure the database adapter. You'll choose configure adapter from the menu bar and then from the list of available adapters you'll choose which database you want to pick. In this case we've chosen the Oracle database and once you go on from there you'll get a custom Oracle login panel that lets you configure which Oracle database to connect to, what the user name you want to use is, what the password is and when you say okay all of that gets put into the model file for later use by your application.

Once you've connected to the database we have to work with the entities, that is the tables in the database. In the database the entity is simply a table and in the application it's a class, not a particular object but an entire class of objects in your object oriented application. In this case the studio table and the studio class.

To create an entity using EOModelers, you'll choose New Entity and using the Inspector Panel you'll specify what the name of the table is, what the name of the entity is, in this case the Director Entity, the name of the table, and the name of the class in your application. And if you want to keep your life simple, you probably want to choose similar names like Director and Director, although EOModelers doesn't actually care.

And in fact, if you don't care about the class at all, we have a special class you can use called the EOGeneric Record, which is essentially a glorified dictionary. All it does is fetch data from the database and stores it as key value pairs in a dictionary so you can display the data, but you can't put in any custom business logic. If you wanted custom business logic, we'd choose a class name such as Director Class or even just Director.

EOModelers also lets us set up the attributes. In the database, an attribute is the name of a column, in this case, the name column of the studio table. In our object-oriented application, it's an instance variable in the various objects. So we have the studio, has the Warner Brothers and 20th Century Fox, and here we have two instance variables containing Warner Brothers and 20th Century Fox.

Now most attributes are what we call simple attributes. Just simple strings, integers, floating point numbers. An EOF automatically knows how to take that data from the database and convert it into the appropriate Java data types. We also have more complicated data that gets stored in the database as a blob. And a blob is just a large chunk of data, usually containing an image or a sound, quick time movie.

And they do get read out of the database into a special class called the NSData class. And in your model file, you specify which particular class, like NSImage or NSSound, you want that data to turn into, and which factory method will actually convert the data object into the particular class that you need. And finally, the third type of attribute we'll have are key attributes. Primary keys in database terminology are the column that uniquely identifies a row. And a foreign key is a column that uniquely identifies the row in some other table.

Now in your object-oriented application, we don't actually have primary and foreign keys at all, because we don't need them. Objects are intrinsically unique. This computer monitor and this computer monitor are different because they're at different places. In the same way, in your application, two objects are at different locations in memory, so we don't need a primary key to tell them apart. They're already unique.

So if we want to edit the attributes in EOModelers, first we'll select the particular entity that we want to work with, like the director, and once the director has been selected, On the top, we'll see a list of all of the attributes of that director. They're outlined in blue on the screen.

And if we bring up our Inspector Panel, We'll see that this particular attribute is called the Talent ID. Its database column is Talent ID. It's a long type in the database, and in our application it's stored as an integer. Relationships are a bit more complicated. In the database, a relationship is a join operation between the primary key of one table, in this case the Studio ID of the Studio table, and a foreign key of a different table, the Studio ID in the Movie table.

Now in the application, when you actually instantiate your objects, the relationship is represented as an instance variable that points off at other objects. So here we have the movies variable, which points to an array of movie objects. Now there's two kinds of relationships in the database that look very similar: a 2-1 relationship or a 2-many. But in the application they look quite different.

In the application, a relationship to one is simply a pointer, a variable that points directly to another business object. The movie points to its studio. A Too Many Relationship, on the other hand, points to an array of other objects. So here we have the movie variable which refers to the array of Alien and Star Wars. We also have the choice between a one-way or a two-way relationship.

In the case of a two-way relationship, The studio knows all about its movies, and the movies all know about the studio that they're in. But this does occupy more memory in your application and it also introduces the possibility of inconsistency where the movie may contain a studio but that studio doesn't have a back pointer to the movie.

So what you might choose to do to simplify your object model is taking out the back pointers and only have a one-way relationship. So now our studio knows about the movies, but a given movie doesn't actually know what studio it came from. and EOModelers the way you would do this is by only setting up one half of the relationship. You can figure the two of them independently.

So to use EOModeler to edit our relationship, once we've selected the entity, we'll go down to the bottom half of the screen and we'll see a list of all of the relationships. If we select a relationship, in this case the movie, and bring up our inspector panel, we see that we can give it the name "Movie". The entity is a movie, so it's a relationship from the director table to the movie table. and we're using the movie ID of the director and the movie ID of the movie table to actually resolve this relationship when we perform the fetch.

Many-to-many relationships in the database require a third table. This is a situation where a movie could have multiple talents who starred in the movie, but at the same time, a given talent, a given actor, could have acted in several different movies. In the database, we need a third table that's called the "join table," and it simply has the primary keys of the appropriate movie and talent to form the relationship.

In the application, we don't need that third class because we simply have the movie maintains an array of talent. Every piece of talent will maintain an array of movies. And when you update the relationships, EOModelers and EOF will automatically insert the appropriate rows into the acted-in table to form that relationship. Happens automatically.

To set up this relationship in EOModelr, you could create that entity, create the relationships, and put it all together by hand, but that's fairly tedious. So instead, the engineers of Apple gave us a nice graphical user interface way to do it. We'll simply select the two entities, in this case the movie and the talent, and from the property menu we'll choose Join in Many-to-Many When we do that, a third entity gets created, the Movie Talent Entity, and all of the appropriate relationships are set up, so that now we have the many-to-many relationship.

If we were to select one of the entities, in this case the movie, and choose the talents relationship, and bring up the inspector panel. We don't get the usual relationship inspector. This inspector panel just tells us that this relationship, talents, is actually a combination of the movie talent relationship in movie and then the talent relationship in movie talent. And we'll just use a dot notation to join them together.

We can also use EOModelers to set up relationships between more than one database. This is especially useful when we have to connect to legacy systems where we didn't get to design the databases and we have one system from one company that was used one database environment and then perhaps a newer company that has just been acquired uses a totally different database system and your application needs to talk to both. Well, in EOModelers, the way we'll set this up is first we'll open up the model file for one of the databases, in this case the video rentals. And now we have another database of all of the movies ever made: the Movie Stars database.

Within the Video Rentals, we'll simply select the entity that we want to create a relationship in. and bring up the Relationship Inspector. And there's a pop-up labeled Model. In this case it's set to Video Rentals, a relationship back into the same database. But all we have to do is select the pop-up list and change that to the other database, the MovieStars database.

And from there on we'll just wire things up in the usual way. Specify which entity in the MovieStars database we want to use, whether it's a 2-1 or a 2-many relationship, and specify the attributes that we'll use to create the join. And now at runtime, when you actually try to fetch a video rental, EOF will automatically perform a fetch across the databases, perform the appropriate cross-database join, and retrieve all the information that you need. If you update the relationships and then save your changes, EOF will automatically save the appropriate changes to each database to keep your relationships intact. So that was part one, the basics of how does EOF work, what is EOModelers, and what is a database anyway.

Well, the next thing to do is how to work specifically with the entities. We have a particular studio or talent or director table in the database. Well, what do we want to do with it? We'll probably want to generate some SQL code if we haven't already inherited a database from our legacy.

You might want to browse the data, see what's already there. If there already is a database that exists, we might want to just pull all that information into EOModelers and have EOModelers build our entities for us. And finally, to actually start writing our application, we'll probably want to generate some Java classes.

To generate the SQL, you simply select the particular entity, in this case the talent, and bring up the SQL generation panel. And here we'll say that we want to drop the old table, drop the old support for primary keys, create a new table, create the new primary key support, and we can see all of the SQL code that will get executed. And we can either execute it immediately or save it off into a temporary file so we can give it to a database administrator to execute on a remote server.

If the database already exists, we might want to browse the data. So in this case, we could select the Talent table, Talent Entity, bring up the Data Browser, and see a list of all of the talent in the database. We can also type in a particular qualifier, last name begins with F, and just see the talent whose last name begins with F.

And if we already have a database, which nine times out of ten is the situation because we already have existing applications and we're now trying to move into the Internet, We can just use the reverse engineering tools to specify which database we're using, in this case OpenBase Lite. Bring up the login panel to specify how to connect to that particular database and where it's located.

And then choose information to help us guide us through the creation process. Yes, we want to give primary keys to the entities. Yes, we want to use custom Enterprise Objects. So if there's a talent table, we want EOModelers to automatically generate the talent class for us to use. And then finally, select from all the tables in the database which particular tables we want to use in the model file.

And the last thing we'll want to do, once we've already imported our model and started to work with it for a while, and in the meantime our database administrator over in that corner of the world is busy working with our database schema, we need to bring these two worlds into sync again. And we can use that by, we can do that by bringing up the synchronized schema window.

And that window will list all of the new tables in the database or new entities in your model file, any new attributes that were added or any attributes whose properties were changed. And when you click the synchronize button, EOModelers will automatically go and make the appropriate changes to your model file and to the database.

Once we've synchronized and our application is now in sync with the database, we can generate some Java classes so we can start coding our application. So again, you'll just select the entity, the talent, say please generate some Java classes, specify where to save them, and if you do try to save them into a project, then the alert panel will appear asking you whether you want to add the files to the project as well as just putting them physically into the project directory. Mike Gobbi And at that point, those Java classes are now standard Java source code. You can fire up Project Builder, make any edits you need to make, and then build and run your WebObjects application.

And the last tool that EOModelers provides is a convenient diagram view to give you a graphical view of your schema. And you can just inspect this view to see what your various entities are and how they're related. Or if you want, you can actually do simple edit operations, creating relationships, breaking relationships, or renaming various attributes directly in the diagram view.

So now, we know some basic database concepts. We know how to use EOModelers to do a little bit of custom configuration. How do we generate the SQL? How do we generate the Java classes? Well the next step, now that we have our application up and running, is actually going to be to have runtime behavior.

How do we validate the data, keep bad information from hitting the database? How do we detect a conflict when two different users are both trying to edit the same record at the same time? Shared entities we can use for memory improvements. And then we can use stored procedures and Fetch specifications to also give our application better performance.

So there's different ways to validate. The simplest validation is done right within EOModelers. Bring up the Inspector panel for an attribute. Click on the second icon in the icon path and you can see the Advanced Inspector. And in this inspector we can say that this entity will not permit null values in the attribute. For example, a customer can't have null for a last name.

You can limit the string lengths. We won't sell to anybody whose name contains more than 15 characters because we have an old database that just can't cope with it. Maybe we can make our relationships mandatory. Perhaps every customer has to have a sales representative. Or perhaps every movie has to have a director.

and we can also specify what happens when we do a deletion. If I delete a studio, should I also delete all of the movies that studio created Should I set them up as movies with no studio? Or should I in fact refuse to allow the studio to get deleted until I've first gone through manually and reassigned its movies? And this validation is fairly useful, but often doesn't meet all of our needs. Maybe it's okay to have last names that are not null or null, but what if we want to put in rules that say the last name can't contain any spaces? That's more complicated than EOModelers can represent.

So to do that sort of validation, in your Java class, you'll create a special validation method. In this case, validate for save throws an EOValidationException, and before we try to save the changes to the database, we'll check. And if the person is too young but claims to have a driver's license, we'll throw the exception saying, "We're not going to let that data into the database." You can also write custom validation methods for every attribute.

So we could just say validateLastName and that method will automatically get called if the user tries to change somebody's last name. In addition to validation on a single user basis, making sure that a particular user doesn't try to let a young person drive a car, we can also get a problem of conflict detection.

Where perhaps over here in one application, I've decided that this customer is in fact only 13 years old because I just called her up, talked to her parents, and found out that no, she's not 26 after all. Meanwhile, off in another corner of the world, some other user has called up the same customer record and has just tried to give the user a driver's license. Now each of those operations independently is correct, but put together, they'll form a conflict. EOModelers and EOF supports two ways of dealing with those conflicts. If we use pessimistic locking, we're going to assume that there are problems.

And the way we make ourselves safe with that assumption is when EOF fetches the records out of the database, it actually locks those rows. And no other user can fetch those rows from the database until we either commit or revert our changes. That's very safe, but unfortunately in the world of web browsers, when people call up a screen, then follow a hyperlink, then follow another hyperlink, then they go for lunch, then the day is over and they go home, and they never did save or commit, pessimistic locking doesn't work very well. Because now all of a sudden nobody can use your database.

So EOF also supports something called optimistic locking. And with optimistic locking, we will allow two users to fetch the same record. But before any user saves their changes back into the database, EOF will automatically compare the record in memory against the record in the database and make sure that they match. And if they don't match, that means someone else has made a change and EOF will throw an exception and say that we can't save those changes.

And within EOModelers, you can use the little padlock icon. It's not a suitcase. and specify which particular attributes you care about. In this case, we don't want anybody changing the first and last name without both of them being changed or without one person having access to both of them, but we don't really care about the pay grade. If I want to change somebody's first and last name while somebody else changes their pay grade, we don't care.

So we have these exceptions being thrown by EOF, and now we have to know how to deal with them in your class. Well, we'll use the standard Java exception handling mechanism. Inside our Save Changes method, we'll ask the session for the default editing context. Remember, the default editing context is the little pool of objects that this particular user is using, and it's kept separate from every other user. will try to save our changes. And if there were any validation exceptions, then we'll generate an error page displaying the appropriate error message. If everything went through okay, we'll return null, save our changes, and redisplay the current page.

EOF also supports the concept of shared objects, because as I said, normally every user gets their own editing context. And that's good for security. The two users can't interfere with each other. But it's very bad for memory. As soon as we have five users hitting our database, every user looking at all of the products in our catalog, suddenly we've got more memory that our computer can handle. So we have the concept of shared objects. This is a new feature in WebObjects.

If you have a read-only entity, like the product in a catalog, you can mark it as a shared entity. And when your web application launches up, EOF will automatically fetch all instances of that entity into memory. and then all the different users will all share access to those particular objects.

And if, by chance, some user should try to change one of those objects, even though it's shared, that's okay. EOF is clever enough to notice that, and it throws one of those validation exceptions we talked about. Tell the user, "No, this is a read-only entity. You're not allowed to edit it." EOModelers also lets us create stored procedures. If there's a particular fetch operation we'll be doing over and over and over again, we can build it graphically in EOModelers.

Oh, sorry, that was the FEPP specification. That was stored procedures. Stored procedures is what we use to improve our performance. So we can create stored procedures within EOModelers And then they can get triggered automatically to inserts, updates, and deletes into any database triggers that we want executed. We can also have fetch specifications that we use to retrieve data from the database, build it once in EOModelers, and then at runtime we can just reuse that fetch specification time and time again.

In EOModelers, you'll select an entity, in this case the Talent entity, Create a new fetch specification and then graphically assemble the query that you want. So here we want a list of all of the actors based on the movie revenues. So we can actually build up a key path where the actors where the roles, movies, revenue is greater than the revenue.

And all that actors, roles, movies, date released are after a certain date and their movies date released is before another date. And when you actually execute this fetch, EOF will automatically perform the join operations to resolve that query. Because we actually have three different tables involved here. There's the talent table for the actor.

The Movie Table for the movie and the Roles Table, that was the Join Table I told you about, that actually relates an actor and the movies that they've been in. And EOF will automatically put all that together at one time. You don't worry about it. You just call the fetch Actor by Movie Revenue.

And your source code, the way this will look is again you'll create or get hold of your editing context. Declare an array variable to store the results of your fetch. And then use the EOUtilities class. This is a class that has a bunch of static methods for common operations. So here we'll ask EOUtilities: Please give me all of the objects with the fetch specification and bindings.

And pass in the name of the fetch specification: Actor by MovieRevenue. And then a dictionary of key value bindings. In this case the revenue and the before date. Now in this example, we actually had an after date in our fetch specification. The dollar signs represent the variables that will be looked up in the dictionary. So we have revenue, after date, and before date.

In our dictionary, we don't provide the after date, so EOF will automatically prune that particular clause out of the fetch specification. If you didn't provide a value, we'll assume that you don't care. And that's the essence of how EOF and EOModelers work together to build your application. First you use EOModeler to inspect the database, pull in all the data that you need to look at, set up the entities that describe how a particular database table corresponds to a class in your application.

Use EOModeler to do any custom entity work you need to do. Generate some SQL code, maybe set up some simple validation rules in EOModeler, or perhaps write some more complicated validation rules within EOF and in your Java code. And then finally, you actually build and run the application that will be displaying your information. And in fact, I'll do that for you right now. We can switch over to monitor number four.

And if I had a show of hands here in the audience, how many people here did not see the previous presentation where you saw how EOModel and Project Builder, how you saw WebObjects Builder and Project Builder work together? How many people here did not see that? So most people did. Good. I'll quickly sketch out the details of that, but I'll focus most of my attention here on EOModelers.

So I'll bring up the EOModeler application and I'll create a new model. I'll choose which type of database I want to connect to. In this case, I'll use OpenBase Lite. OpenBase Lite is actually a file system database. So we'll navigate off to in the file system where the database is stored. And that is in local library databases, the movies database.

I'll say that's the database I want to use. I then get to make some selections here. I do want to assign primary keys to the entities. I don't want to be asked about all of the relationships. I'll just trust EOF to do the right thing. I don't want to be asked about story procedures. Again, I'll just trust EOModelers and EOF to make the right choices.

And I do want to use custom Enterprise Objects. So I do want a Director class, a Talent class, and a Movie class in my application. On the next screen we have a list of all the tables in that database and I choose which particular tables I want to use in this model. Well, in this particular table I want the movie, and I want the movie role, and the studio, and the talent.

Although EOF is going to do its best to ask all the right questions, sometimes it does need to come to me for help. In the case of our movie role, there isn't a single column that's the primary key, because that was a join table between the movie and the talent entities. So EOModelers comes back and tells me, "I don't know which of these is meant to be the primary key." I'll tell it, "It's actually both the movie ID and the talent ID." and I'll finish.

So now we have our EOModel file. Because this is a live demo and I am paranoid, I'll save my changes right now. And I'll call this 403/ Movies It'll come up and tell me that the 403 directory doesn't exist. I'll say, "Yes, please create that directory for me." And here we are in EOModelr.

We can select a particular entity, the movie, and see a list of all of its attributes. So the movie has a category, the date it was released, the movie ID, which we'll see is the primary key of this particular entity, and it doesn't have the diamond icon. And that diamond icon tells us whether or not there's going to be an instance variable in our application that goes along with that column. And for the movie ID, the answer is no. We don't want the primary key to be visible inside the application.

Down below we have our relationships, the two movie rule and the two studio relationship. And I don't like those names, so I will change them to... The roles of the movie and the studio of the movie. And we can also look at the Inspector Panel. So if I select a particular attribute, the category, I'm going to bring up the Inspector Panel. We can see the name of it is Category. The column name in the database is, all caps, Category. External type is Character. And internally, it's a string, but we're going to limit the width to 20 characters because that's how many characters we can put into the database.

Similarly, I could select a relationship. And the relationship name here is "Rules." It's a relationship to the movie role entity, and it's a one-to-many relationship. So a particular movie has a relationship to many roles. And we're doing the join. Using the Movie ID and the Movie ID columns of the two tables.

EOModelers will also let me see the diagram view that I showed you about, told you about before. So here we can actually view our entire schema as a picture. And if we arrange it nicely, we can see the relationships between our various objects. So now we see that we have the movie and the talent are connected through this movie role and that the movie also has a relationship to the single studio.

Well, we also have more than one relationship between movies and talent. A movie stars a number of actors, but it's also directed by a particular director, and some movies have more than one director.

And we get another entity here called the Movie Talent, which I happen to know because I've seen this database before. It's actually called the Director. And the table is Director.

And now, once we've done all of this, we're ready to actually build an application. So I'll hide EOModelers. Actually, before I hide EOModelers, I'm going to have a look at this director table and make sure it does what I think it's going to do. The movie ID, the talent ID, the movie ID, the talent ID. Yep. Looks good. And we can do a fetch. It says that there is no talent ID on director. So rather than actually try to resolve what's going on, I'll just take that out because we don't need it for this demo.

So that was the basics of how to use EOModelers to explore a database, pull in all the information that we needed, and then construct a model file that described the mapping between the database and our application. I can put EOModeler away and bring up Project Builder. And now in Project Builder, I'll build a simple application that uses this data to actually display some information on the screen. We'll call this the Actor App. And it's going to be a WebObjects application.

We'll say that we want some help building this application and we're going to be using Java. And we'll open the model file that we just built. So we'll grab the movies model file. And because this application is called Actors, we want to display the talent in the database. I will show a table of all of the particular actors that match our query.

We choose which attributes we want to display. So this basic web application, if we go back to our previous screen, is going to display a query form and then a table of results that match the query. So what do we want to actually show in the table? Well, let's show the first name and the last name.

And which attributes do we want the user to be able to execute a query on? The last name, the first name, what do we want? Let's say we want to query on the... Let's put that back, because we want the first name to appear first, then the last name. And now the assistant is going to go away and actually build a project for us that once we build and execute it will give us the user interface we've asked for. So I'll bring up the build panel and I'll build this application.

Once the application has finished building, put that away and we'll bring up our launch panel. and will actually run our WebObjects application. Now after launching the server side of the WebObjects application, WebObjects is automatically going to launch a browser to display this information. And it does this for your convenience as a developer. One of your final steps before you ship an application and deploy it is to go into preferences and turn off that preference so that you don't have a browser firing up on your server, off in your server room.

And here in OmniWeb, we can see our application, where we can search for the talents, specify what talents we want to display. Let's say we want everybody whose last name begins with F. And we'll go out a list of all the talent in our database. Actually, all the talent whose last name begins with F.

So that was the simplest case of bringing up EOModelers, pointing at an existing database and saying, "Please build me a database that will work with this." and then using the assistant in WebObjects Builder and Project Builder to actually build an application that will display that information. Well, the more complicated case might be if we wanted to use one of those FET specifications that I told you about.

So we'll go back to Project Builder and in our resources we'll find the movies model file And here in our movies model file, we'll select the talent entity. And I'll say that I want to create a fetch specification that goes along with the talent. And the fetch specification, let's give it a name. We'll call it Fetch Actors.

And we want to fetch where the first name is like $firstname. And that $firstname means there will be a key in the dictionary whose value is the first name we care about. And whose last name is like $firstname.

So we'll save this model file now that we've added the new fetch specification. And now, rather than just doing query by example, we can actually use this particular fetch specification in our application. So, we'll hide EOModelr.

We'll go have a look at this component that Project Builder and WebObjects Builder built for us automatically. And this component has the query by example segment in which we specify the talents to display. We set their first and last name and we have the match button. And then we have the table segment where we actually construct the table using repeating rows and columns to display the information. Well up here, what I'd like to do is create another query field. So we'll say we also want to search by movie title. And in fact, I want to make all the fonts a bit larger.

Title. And because the query is simply a dictionary, I can associate arbitrary key value pairs in with it. So now we have our application which will display all the talent that we need to display. Save these changes. I'll add a special action because we can't use our default fetch. And this action will be called Search. And we'll have a look at our source code.

And our search action will say

And the results will be, we'll use eUtilities to get the objects with Objects with Fetch Specifications and Bindings Passing the editing context The name of the entity The name of the fetch specification, which I'm suspicious, so I'll go back and double check. Yep, and it is called Fetch Actors.

And our dictionary of bindings. And then say Talent Display Group Set Object Array Results. And the display group, I won't go into it in a lot of detail, but essentially the display group is an object that knows how to display objects, in particular a group of objects. In the case of Query by Example, it built the query on the fly. In the case of our query, we did the query by hand, so once we get the results, we just hand the results to the display group and say, These are the objects that you'll be managing.

We'll launch the application. And now, we could again ask for All the actors whose names begin with F by typing an F asterisk. Or, if we just wanted to know all the actors in a particular movie, we could say we want to know all the actors in the movie Star Wars. And it tells us that there is no title available. And since I have only one minute left, I'm going to say I'm not going to bother trying to debug this. And instead, I'm going to invite Steve up on the stage, and we'll have the question and answers.