Good afternoon, everybody. I am James Dempsey. Some of you may recall that I've been doing technical training for the past four years. In the about February timeframe, I moved over to software engineering and since have written and deployed WebObjects application. So I'm loving the technology. I wanted to ask a few questions before we got started.

The first thing I wanted to ask is how many folks here are absolutely brand new to the Enterprise Objects Framework? So a good chunk of people. How many of you have done a little bit but that's about it? Not too many. And how many of you have our old hands at the EOF framework but you just come to every EOF session? Okay, and how many of you worked on the WebObjects team? Okay, there we go.

The rest of the crowd. All right, so we got some brand new folks. We got some folks who may know this stuff fairly well. The second thing I wanted to ask folks is how many folks are looking at or interested in the Enterprise Objects Framework because they're planning on doing some sort of HTML or XML based WebObjects applications? So a good chunk of folks. And how many folks might be interested in EOF because they heard about the redistribution license of EOF that allows you to do desktop applications with EOF? So another smattering of hands.

Good. We got you all covered for today. And how many of you saw the episode of Friends where Joey goes for this acting job and then he's in Charlton Heston's shop? I know. I'm serious. I want to know. In Charlton Heston's shower. Did anybody see that one? What was the... Well, we'll get into it later.

That was just a very funny episode. Anyway, what are we going to talk about EOF related today? When I first started learning EOF about four years ago now, what I found was that I came and saw a number of demonstrations and I saw a lot of data flying out of databases and onto screens and what have you.

But I was never really sure how that magic was happening. And that always bugged me. So I've spent the past four years figuring that out. And I think I have it just about worked out almost. What I want to go through today is first let's talk a little bit about what EOF is.

Like why might we use it? And then let's do a little bit of practical here are the lines of code to do some basic database operations. Then let's look at how it works in a desktop environment. And then finally let's just get a big picture of what all the pieces are, why they exist, so that we don't feel like we've been kind of Shanghai'd into watching some demos without really getting an idea of what's going on. So that means an overview of the purpose. And benefits of EOF. That means an intro to basic database operations. Working with persistent objects or enterprise objects.

A demo of desktop EOF applications. And a conceptual model of what's going on in EOF. So let's start. Well actually, let's one more note the technology framework. This is an introduction primarily to two frameworks called EO Access and EO Control. These are the frameworks in the Enterprise Objects Framework or EOF that deals with database access. The nice thing about that layer, that database layer of EOF, is that it allows us, using the same database layer, to build HTML and XML based WebObjects applications, Java client applications, or Cocoa EOF applications.

It's based on this natural mapping between objects and relational databases. It abstracts those database operations and it preserves the object-oriented nature of those things that you get. When you get something into EOF that used to be in the database, you can treat it like an object.

It's sophisticated, it's mature, and it's an object-oriented architecture. Now, we talk about the Enterprise Objects Framework. What is an Enterprise Object anyway? The idea here is it implements an interface. It's a java.lang.object that implements a particular interface called the EO Enterprise Object Interface, which enables it to operate with the framework and gives it built-in persistence.

So this mapping is very sweet between the database and objects. We got entities, so we can map a table in the database, a type of thing to a class. We can map an attribute, so some instance variable or property in the object, we can map that very nicely to a column in the table. But it extends even further Although I can't because of the direction. To relationships. We know in an object model it's a very common thing to just have an item that refers to some other object using composition. And it's just a reference in memory, a unique pointer.

In a database, the same thing is handled via a join, just these matching primary key to foreign key combinations. Well, again, the Enterprise Objects Framework is able to make that matching. Now, how many folks have been in at least one WebObjects-related session this week? You can tell me en masse on the count of three, most likely, What tool we use to do a mapping between a database and an object model. So on the count of three we're going to give it a try and then if you don't get it I'll give you a hint. So on the count of three let's give it a try. One, two, three.

Okay, we got the right answer. I don't know if it was from the folks who just come to any EOF session that exists, but we're going to try to get it louder because it's after lunch, it's mid-afternoon, it's kind of like almost mid-week, and I think, you know, we just need to shout out at me on the stage. So let's try this again. One, two, three.

And for those of you who didn't get that, it is EOModeler, which defines this mapping between rows in the database and objects in the model. The point of EOF in a very abstract sense is to get rows, turn them into EOs, and then get them back again. And finally, what we'll be doing for the rest of the day, or the rest of this session, is talking a bit about this process and how it works.

I won't be labeled the model file. Now, besides this mapping, what are some of the other advantages or benefits of using EOF? One of the largest is this idea of having multiple views into the same data. So this idea that we can have a HTML application that's running publicly that people are hitting, but on the back end we don't want to administer the database using an HTML front end possibly.

We might want to build a Cocoa application or a Java client application that's a more desktop interactive experience for interacting with that database. Or it's possible we might want to build an HTML front end that people can visit, but then also provide the same data as a web service via XML to a number of individuals. And we can use EOF, the same model file. . We can use the same business logic and build the view on top of that.

The nice thing about each of these is that they're all EOF-based applications. Now the logic's written in standard Java. It's not written in a particular vendor's database language, which may be procedural, which may lock you in because you don't want to move that logic from one database to another.

So it's in standard language. It distributes the processing as well by putting our business logic in these enterprise objects. We're not tying up the database doing a lot of business logic calculations. It's doing what databases were initially designed for, which is saving and retrieving large amounts of information very, very quickly.

Now, when I started using EOF, I didn't know anything about SQL whatsoever. The nice thing about EOF, if you are a programmer who's saying, well, I've got to do some database stuff, is that it dynamically generates the SQL for you. You define the model file, you programmatically ask it for things that you want in a very object-oriented nature, and all of that SQL gets dynamically generated for you.

To me, that's a big win. On the flip side, for the person who loves writing SQL, EOF also allows you full access to those database features. You can send any kind of raw SQL to the database using the frameworks. You can also execute any stored procedures you might have in there.

EOF also allows you to connect to multiple data sources. We'll talk a little bit about this a little later on. And one last thing that you get with EOF is a separate scratch pad for every user, a little thing called an editing context. The idea here is that when that row becomes an Enterprise Object, Every user has their own editing context, so they have their own little scratch version of that row in the database.

They can make changes to it, add things, delete things, and it's not bothering anybody else until that user saves the changes. So each of those editing contexts is like a little miniature alternate universe where the row comes in and is able to be played with a little bit before those changes hit the database.

Now you'll notice that my drawing is a little lopsided. That's to indicate the fact that typically when you have a desktop EOF application, you're often using one editing context per user. And so that application may have one editing context. When you're using a networked tag-based XML or HTML application, every session has a default editing context. So every user logging in will typically have their own little editing space.

All right, let's mosey on. Let's talk about the basic EOF operations. Fetching, inserting, updating, deleting, saving and reverting. Essentially each of these can be done, especially when you're just starting out in EOF, with a line of code. And we're going to walk through those lines of code. First we're going to talk a little more about this guy, the editing context. The editing context is the key class when you start using EOF programmatically.

It's the go-to guy. If you want some objects out of the database, you ask the editing context. If you want to add some things, delete things, you talk to the editing context. You want to save the changes, you want to throw away the changes. You want to undo the changes, you talk to the editing context. So, who do you talk to? Oh, that's pathetic. All right. Let's try it a little louder. Who do you talk to? Okay, that's still pathetic. Who do you talk to? All right.

Good gracious. So how do we get one of these things? Well, the first thing that we do is if we're writing a WebObjects kind of tag-based application, we just ask the session for its default editing context and it gives us one. Not a lot of work to be done there. If we're doing a desktop app, the editing context lives as an object in your nib file so we can get access to it. And any time programmatically you may feel like creating an editing context, you can just create a new one very easily with a no-argument constructor.

Now, a note with multi-threaded applications, when doing any kind of concurrent programming, there are always shared resources that need to be locked and unlocked, the editing context being one of those. The default editing context is automatically locked and unlocked for you. If you make your own or if you're using a nib-based editing context, you'll want to, and you're multi-threaded in that nib-based app, you'll want to lock the editing context before you use it and unlock it afterwards.

So how do we get stuff out of the database? As you go through, read the WebObjects documentation, go down to the lab, read articles on Stepwise, talk to your WebObjects-using friends, there are many different ways you can fetch. We're going to talk about one here, but as you kind of get into various ways, the basics are pretty much the same here. You create this thing called a fetch specification, which is an object-oriented definition of what you want from the database. Then you've got to get hold of an editing context.

Then you tell the editing context, "Hey, I want you to fetch this," and you hand it the fetch spec. Then you get back an array of objects. We're going to do it the most codeless way, or one of the most codeless ways, that still requires a line of code.

We're going to, in the model file, create a graphical fetch specification. We'll see this in the demo, but the idea here is I can define what I want, what sorting I want it to come back as, as well as any criteria in terms of what specifically I want from the database.

Once I have that, I can use a line of code that will, in essence, pull that fetch specification out of the model file. It will also take an NSDictionary of bindings, or key value pairs, and kind of merge it with that fetch specification so we can fill in some variables in there to capture anything the user has typed in. You know, search for a house with two bedrooms and three bathrooms.

Take that FET specification and ask the editing context, "Hey, give me back those results." All of this is done in one lengthily named method, Objects with FET specification and bindings. It's a utility method of a very handy class called EOUtilities, which provides a lot of convenience one-liners for common EOF operations.

In this case, we get a hold of our default editing context and then we ask EO Utilities to give us back that objects with fetch specification and bindings. We need to tell it the editing context, what kind of thing or what entity of thing we're looking for, the name of the fetch spec, and that dictionary of bindings.

Now to create and insert a new object, it's a very simple method, one liner EO utility. Create and insert instance. In this case, this will do two things for you. It will make, in this case, a new employee enterprise object and it will tell the editing context, insert this into the database. Deleting is even easier. You just tell the editing context, get rid of this sucker.

Editing, we don't even write any explicit code. The editing context is smart enough that it knows everything that's been fetched into it, and it knows everything you've inserted into it. And so as you make changes to those Enterprise Objects, it's automatically watching or observing those changes, so it knows what objects have been edited. And so to make changes, all you do is treat that Enterprise Object as an object. You use accessor methods, or you may use key value coding, as has been mentioned a number of times.

Once you've inserted and deleted and made a bunch of changes, you basically have two choices. You can either tell that editing context, hey, I want those changes to actually be reflected in the database. Let's save changes. Or you can tell the editing context, you know, this was a bad idea. I'm going to chuck those changes.

So the line to do that, editing context save changes. Editing context revert. We'll get rid of all pending changes and we'll leave the database untouched. Now to take us through a couple of these points in a WebObjects application, I'd like to introduce Genevieve, who is going to walk us through that.

My mouth is dry because I'm nervous. So let's take a look at some of the things that James has been telling us about. And to do that we're going to use a little WebObjects HTML application that looks at a listing, looks at a database of real estate listings and let us choose the ones that we want to display based on some input that we give it in the browser.

We can enter the number of bedrooms. And we can further restrict the search by entering a minimum number of bathrooms, perhaps. It's a very simple application that talks to the database. What does it take to actually code something like this? We can take a look at it in Project Builder.

Since, as James told us, the EO model is the central piece that kind of holds everything together, it ties together the application on one side and the relational database on the other side, so let's start by taking a look at the EO model. That's one of our project builder resources.

This is a stripped down version of the real estate model that you'll see in a lot of the WebObjects demos this week. I made it a little smaller so it's not quite so overwhelming to look at. And as you've probably heard by now if you've been at any of the earlier sessions, this is the mapping between the relational database and the objects in the application. These are our entities in the application. Here's the corresponding database tables. And here we can see the class in the application that these correspond to.

All of our entities are going to be classes that are subclasses of, or implementations of, EO Enterprise Object Interface. Have you ever noticed how redundant that is? EO Enterprise Object. EO is Enterprise Object. The Enterprise Object, Enterprise Object Interface. Anyway, we have a default implementation of that called EO Generic Record, which is sufficient for a lot of things that you want to pull from the database. If your class happens to need some business logic, you would make a custom subclass of that. We can take a look at our listing entity, get kind of a closer look. This is one of the main entities in this model, as you might expect.

Here are all the attributes of the entity. And attributes correspond to the column in the database. Here we can see the Java type and the database type of all these attributes. And in the lower part of the window here, we can see any relationships that this entity might have. In this case, it has two one relationships to the address entity and agent entity. And we'll hear more about relationships later in the presentation. Let's see. So that's our EO model.

And let's see if we have... any code anywhere. Well, we have one WoE component in here. So let's take a look at that. We'll look at it in WebObjects Builder, which you saw in the tools demo, which is the tool that we use to graphically build up an HTML interface, which is actually a lot more fun than writing HTML by hand.

And you can see here we have a couple of text input fields. That was our bedrooms and bathrooms field. We have a submit button that pushes values from the application or from the interface into the application logic. And we have a lot of text input fields. That was our bedrooms and bathrooms field.

We have a submit button that pushes values from the application or from the interface into the application logic. And we have a submit button that pushes values from the application or from the interface into the application logic. And we have a submit button that pushes values from the application or from the interface into the application logic.

Here's a table that's going to display all of our search results. And if we look at this table, we can see we have some dynamically calculated strings in here. We call these things WoE strings. And they're bound to something called listing. That sounds a little familiar. Let's take a look at what that is. And that's our old pal, the listing entity that we were just looking at in EOModeler. You can see all of its attributes here. And you can see here this particular string is bound to the listing number attribute of the listing entity.

This is bound to bedrooms. This is bound to bathrooms. So you can start to see how all this stuff ties together. But what about our text input fields? They're bound to something called fetch spec bindings. Well, what's a fetch spec? Well, if you were here last year and you saw James' intro to EOF demo or presentation, then you know that a fetch spec lets you stipulate the objects you want to fetch and manipulate.

Okay, where am I? I'm lost. I think you're fetch-specking. Thank you. I got all excited here. So we've seen the interface, and we've seen the EL model. Surely there has to be some code in here somewhere. Well, what's this choose listings thing? That sounds like something that we might want to do. This is an action, which means that it's bound to a method somewhere in our application, somewhere in the component.

And we can check, we can select view source down here, and that will put us back in the source code. Make this a little nicer to look at. And there, we can see that we've got a That's all of our database code. That's all the code that we had to write in order to get an application that knows how to find the database, connect to it, and fetch things from it based on some specifications that we've given it in the UI. James wasn't kidding about those two lines of code that we needed to do this.

You can see here that in objects with fetch specifications and bindings, we're taking the default editing context, which we've pulled from the session, and into it we're going to fetch the listing entity using the search listings fetch specification and pushing values from our fetch spec bindings that we saw in the HTML interface into that.

One of the nice things about EOF is that we give you API that allows you to discover EO models at runtime. You can discover the entities that they contain and those entities' attributes, relationships, and other things that they don't have. You can also use that to store procedures, primary keys, fetch specifications, and pass those objects into methods like objects with fetch specification and bindings. That gives us a great deal of flexibility and gives you a great deal of power with really a minimum of code.

So I think that shows us the basic code that we wanted to have. And back to you, James. Well, you know Genevieve, I was thinking, wouldn't it be nice if people could also search for a range of prices when they're looking up a property? Could you just whip that up for me? James? Are you giving me a last minute application spec change? Not only am I giving you a last minute application spec change, but I'm doing so in an obviously stage inscripted manner. James! We're in front of a large, sophisticated audience! Just do it like we practiced! Okay. Well, I guess that means that we better add some fields to the UI. So, what did you want? A range of prices? Yeah. Oops. Cannot type.

Okay, we'll put a text field in here and we'll put another text field in here. And let's see, what do we do? We'll bind these text fields to our fetchback bindings. and I'm going to bind the value to FetchPickBinding's min price. And we'll give that a nice number format so it doesn't look hideous on screen. We'll select our second text field and bind it to a max price.

As she's doing that, what she's binding it up to is a mutable dictionary, which is just a hash table. It's just a mutable place where we can put key value pairs. And because of key value coding, and because a dictionary's whole job in life is to store keys and values, she's able to hook those text fields up so that they are pushing keys directly into that dictionary without ever having to change her code. That little dictionary is serving as an infinitely expandable place where you can stick as many keys and values as you want.

And we're taking advantage of that right here. And so now we need to hook up, we need to add another column to our results table, our display table, and we're going to hook that up to the asking price in our and I'm going to go ahead and start the session.

Okay, that takes care of the interface. We're going to have to change our fetch specification. I forgot to show you this earlier. Our listing entity has a fetch specification associated with it called Search Listings. And you can build up fetch specifications in the code, but you can also build them up graphically in EO Modeler. So we'll click on this and it shows us the graphical fetch spec builder. You saw a slide of this earlier. And right now we're currently qualifying our select statement on the number of bedrooms and the number of bathrooms.

But we need to add to it. So we're gonna add asking price, Greater than or equal to that variable min price. In our fetch spec bindings and we need a max price less than or equal to our max price. Save that. And we will recompile to pick up the changes to the EO model.

Notice that we didn't have to write any additional EOF code. We didn't have to change any EOF code. We didn't have to write any more SQL. And here we have our application. We've got our additional input fields. We've got our additional display field. and I will be your host for this session.

You don't need to sit and figure out, well, the primary key of this maps to the foreign key of that, because that's something that you determine or you set up in the model file, and EOF does it all for you. The other thing we don't need to do with a relationship is if I have an employee that I've fetched in and I want to get to what department they're in, I don't have to write more fetching code.

I just ask the employee, hey, give me your department, and that department object, if it isn't in the application yet, EOF is going to hit the database, grab the correct row, and instantiate a department object for me. The fact that it might not be there when I ask, but it's definitely going to be there immediately thereafter, that is called faulting in an object in EOF.

This means that let's say I have a project, has one employee working on it, keep things simple, who has an email address and that email address is [email protected], which I don't even think is a legal domain name. But boy does it fit on the slide. So we have this example. And if you're writing a bunch of SQL, right, you may need to go and write some SQL statements and get the right things and make sure that the foreign keys and the other keys match up. Or I might use a key path in WebObjects.

I prefer using a key path in WebObjects because even though you can mistype a key path in WebObjects, there's a heck of a lot less to troubleshoot than all that SQL. The thing to take away here is use those EOs like objects. Think of them as objects, not as rows in a database.

All right, we've seen a WebObjects application vending HTML. We could similarly do one in a very similar manner that spits out XML. Now we're going to talk about desktop applications. One thing that's nice about the web as a developer is that it's very regimented what happens, right? A request comes in, you do something, and you send out a response.

And WebObjects is very nicely designed that it automatically, when that request comes in, it'll pull the values out of that request, it'll pull values out of objects and shove them into HTML or XML and spit it out. So this request-response cycle is very nicely tuned. However, on the desktop, life's more complicated.

If you've written... How many folks have written a Cocoa application in here? A couple folks. How many folks have written a swing application in here? A few more folks. I know I've found in the applications that I've written that I spend a whole heck of a lot of code saying, "All right, I got this thing, this object that represents something in the user interface, and I have this text field, and I have to make sure that what the value for the guy's first name is has to match what's in the text field, and if they change it here, I have to update it here, and then heaven forbid you actually have another text field somewhere in a table that also has the first name because now you have to keep everything in sync." And you write a lot of code just doing that synchronization.

EOF has a framework called EO Interface. And EO Interface uses an object called a display group, which displays a group of objects. Go figure. That manages all of that synchronization and interaction with a real desktop application for you. And rather than talk more about it, it's definitely something that's much easier to see. I'm going to turn things back over to Genevieve.

So the first application that we looked at was obviously a simple HTML application. It's the sort of thing that a prospective home buyer might use to look at real estate listings from a computer in their home or in their office. They really only need to fetch the data and look at it, and you really don't want them to modify it.

But what about the real estate agent who has to administer the database? They're going to need to add listings, delete listings, make changes to listings. And so this is where the richer functionality that you get on a desktop application can really be appreciated. So what we have here is a Cocoa EOF application, listings by agent. In the top table we see our agents, and as we click on them, we can see the listings in the bottom table change so that only the listings for that particular agent are being shown.

And we can open a listing, opens the listing for that agent, pulls the information to give us the photo of the agent -- this is Todd Fernandez, our QA manager -- and we can see that the agent is actually manager. And we can open multiple listings.

So let's give this a listing number that's going to be a little bit easy to spot. And we'll call this a condo and we'll give it a Silicon Valley price.

And four bedrooms, one bathroom. You're laughing, it's true.

That, by the way, is wired up directly to the editing context. I didn't have to write any code to be able to do that. The editing context knows how to manage all these changes for you. And this place is located here in San Jose.

The changes that I've been making so far are all being made in memory. What we have here is our friend the editing context that James told us about earlier, managing all of these changes for us, tracking the additions, the deletions, the undo, the redo, all the changes of mind, and isolating those changes from the database so that you're not pushing changes back and forth to the database unnecessarily. Once we've figured out that we've got all the changes that we want made correctly, then we'll push those down to the database by doing a save.

This operation here was also wired up directly to the editing context for this particular window so there was no need to write any kind of code for that. So did that really get saved to the database? We should check on that. I may just be kidding you all. So what we'll do is we will run our little customer application again.

What did that have? Three bedrooms and a price somewhere between 400 and... And here's that listing ID. So you see it really did change. It really did write to the database. Let me just get rid of this real quickly. It can't be that easy, right? How does all the synchronization take place? Well, it's the EO Interface framework that's doing this for you. The way that you work with EO Interface when you're doing development is through the tool called Interface Builder.

You may have seen a little bit of Interface Builder demoing going on this week already. I think there's a whole session on it. Is it there? Is there anybody know? There is. There's an IB session somewhere. It's very interesting to watch. So here's the main interface file for this listings by agent application.

And one of the really cool things about Interface Builder is that while you're building up the interface, you can actually see live whether it works or not. There's something called test mode. And we'll invoke the test mode for this. And we can see that this is actually -- no.

This is actually pulling the data from the database while we're working on it. That can really help shrink down the debug cycle for building an interface quite a bit. So we'll go back into the editing mode for IBM. So that James doesn't have a chance to change the spec on me, I'm going to add a text field to it myself.

Let's add a field that shows the first name of the agent so that we can be real chummy with the agent on the phone. So we pull a text field down onto our window. And we're going to wire this up to the first name of the agent. So we'll set the value to the agent first name, connect, and let's make sure that works.

You can see that we're pulling the agent's first name. We were able to do this all without writing any additional database code, without even getting out of our interface building tool. I wonder what would happen if we change something, actually change the data in here. Would that work? Let's give Andreas a nickname that he can use when he's talking to maitre d's or something in a restaurant. Yep, looks like it works. So the interface builder, the interface is really live while you're working on it and as I said it really cuts the debug cycle down quite a bit. And that's IP and EO interface. Thank you.

So, I don't know about you, but to me that saved me tons of time. Even, I just finished deploying a WebObjects application and I wrote a little Cocoa EOF application just so I could change things in the database very easily. And about 90% of the time I just ran it in Interface Builder as a development tool for accessing things into the database. So, even just for that reason, it's a very, very handy technology. So, how much of it's really codeless might be the question that comes to mind. Is it all codeless? Well, certainly when we hit the save button, we tell the editing context through target action to save.

You would probably want to put some error handling code around that in case somebody tripped on the database in the server closet and, you know, it's offline so the user doesn't get some bizarre error message. But all of that dynamic updating of picking a new person and having the new list of items show up, that's all completely codeless. The having text fields and other text fields update automatically, that is all completely codeless. So, I find it a great time saver.

Excellent. So we've seen a lot of kind of magic, right? One line of code here, no lines of code here, and all this magic kind of happens. What I wanted to do to finish up is talk a little bit about the framework itself. What are the pieces of the framework so that as you start learning about EOF, start reading the documentation, you'll run into a number of concepts, a number of classes, and you might wonder where do these all fit together. So I want to kind of talk us through The EOF Stack. Basically, how does a row become an EO, who's involved, and what do they do? So that when you start playing with EOF, start reading about it, you know.

So, So let me back up for a sec. EO access and EO control, those are used in every single EOF application, whether it's XML, HTML, Cocoa, JAVA as an application. EO interface is used only in the desktop applications. So EO access has two layers. The adapter layer is where the database connection occurs. It has the database connection. It's the thing talking to the database. It doesn't know anything about full-blown enterprise objects. It's dealing in raw SQL generation down to the database. It's dealing in raw rows coming back from the server.

Then it hands those raw rows up to the database layer, which does two very important things. The first important thing that it does is it turns that raw row into that living, breathing enterprise object that we can do nice stuff like relationships and the like with. It also takes a snapshot of the values that came in and keeps them for later use. It does some caching.

So that later trips to the database layer which may be avoided to avoid load on your database and also increase performance. That's important to note because by default when you fetch things, it's going to take the cached values first. So that might be one of the first times you run into a snapshot as a new EOF developer. I think there will be more on that in the advanced EOF session. So those are the two things. Adapter layer, raw rows, direct connection to database. player, turn those rows into EOs, and keep a snapshot.

All of this is configured in the EO model file. When you start using the Enterprise Objects Framework, Basically, you make this model file. You do this mapping and it tells these two parts of the EO access framework how to deal with the database and the incoming data. Now, we can go in there and minutely tweak just about every parameter you can imagine at both of these layers. However, that's probably not the best thing to do in your first time using EOF just because, you know, it's good to start with the basics.

Now, I mentioned earlier you can hit multiple data sources. You might have two different news feeds coming in from two different databases. You want to have news stories that are being presented from two different databases. Well, we make an EO model. That EO model, when that application launches, creates a database layer and an adapter layer that's going to deal with the particular database.

I want multiple data sources. I add another model file. When I launch this application, a second set of that database layer and adapter layer is going to show up that's going to be hitting another data source. In my code, I don't necessarily know or care which data source this is from. I ask for a customer, it gets it from one database. I ask for a news story, it comes from another database. I don't care.

Now, as you're doing some reading, you're going to come across something called a model group. Since we can have multiple model files, we need some object that holds them all together. It's called the EO model group. So when you come across it, don't freak. It's really its job in life.

At this point, we're able to access and turn rows into EOs and back again, multiple data sources that pretty much evens out EO access. So we'll move into control. The EO Control Framework is where our editing context lives. It's where we programmatically control and coordinate what's going on in EOF. Now, we've got multiple databases potentially happening, although I think most EOF users are hitting one database.

So you'll run into this guy called the EO Object Store Coordinator. The Object Store Coordinator's only purpose in life, or main purpose in life, is when somebody asks for the customer object, it's going to figure out which stack it should send that request to. So it's literally coordinating between the fact that we may have multiple data sources. Now, we got an old friend sitting at the top of this stack, the editing context.

As I mentioned before, the editing context is your go-to guy, but when you ask the editing context for some objects, it asks the object store coordinator for objects, it asks the database layer, the appropriate database layer for objects, and so on all the way down to the database. This is designed so that you don't

All right. That is essentially EOF in a nutshell. So the review.

First thing I'd like to say for the review is EOF, as we saw in the demo, I was able to, Genevieve was able to have two applications, one a desktop app, one a WebObjects HTML app, both using the exact same model file, potentially the exact same business logic with the same validation code, reused across multiple views of it.

To get started, there's not a whole lot of code to get going. As long as you remember you're talking to that editing context, it's pretty much the place to go to programmatically deal with it. And EO interface is very, very groovy when it comes to desktop applications. So, how many folks were in the intro to EOF session last year? Just clap your hands. Don't raise your hands. Clap.

There we go. There's a little song or something that I did and folks seemed to groove on it a little bit. So I thought this year I would do another song. It's part of the review, however.

This year, because things kind of went well last year, I thought I'd open up a little bit and show folks a little more of my sensitive side. And so with that, I suppose I will begin. Are you ready? Here we go.

and James Dempsey, Genevieve Purugganan and James Dempsey, Genevieve Purugganan and

and the EOF team will be joined by the EOF team's team of engineers, engineers and engineers.

and James Dempsey, Genevieve Purugganan.

At the WebObjects Cocoa Boff tonight, they've asked me to play. So you're all just going to have to come back. No. I will do another one because I can't resist that applause. Well a fetch specification specifies those objects you want to fetch as its name implies. With a fetch spec baby you can stipulate those objects you want to fetch and manipulate.

and those criteria of what you desire you're gonna wrap that all up into a qualifier and don't forget about those sort orderings determines the order of objects the fetch spec will bring

You make a change, the editing context knows. One more verse.

The EO database, it maintains a snapshot of the initial values of each row you've got. You can refresh refetched objects if you want to replace cached values with fresh data from the database. EOs, EOs, EOs This was a little song about EOF, I hope you get the gist. Still a framework that helps your objects persist.

I'll be here all the week. All right, so actually stop by the Cocoa EOF BOF, or the Cocoa WebObjects BOF. I will be hanging out there and playing a tune. I might have a third new tune. And come back to the feedback form. They might let me sing the relationship song again correctly. Stop by the WebObjects lab.

Want to learn more about EOModeler? Go to the Advanced Data Modeling session. More about faulting and enhanced performance and optimizing EOF, the Advanced EOF session, and optimizing WebObjects applications in general, the Optimization session on Friday. Tony and Bob are the folks to contact. [email protected] for... Take the WebObjects training if you're just getting started with WebObjects. For more info, the documentation, how to access the documentation.