Good afternoon. I'm Chris Pavicich. Welcome to session 607, WebObjects Tools. Just a quick question before we start. How many of you have ever used WebObjects before? How many of you? Okay. Wow. How many of you have used the product for more than five years and remember when it was implemented in Objective-C? Wow.

Okay. How many of you are completely new to the product? All right, good mix. Okay, today I'm going to be talking about our development tool chain. So let's get a roadmap of where we're going here. I'm going to start out giving you a brief overview of the WebObjects framework stack.

We're going to talk a little bit about how a WebObjects app does the work that it does. And then we're going to start talking about tools. We're going to be talking about data modeling, our rapid prototyping tools, using Xcode to write custom business logic. Customizing your UI using WebObjects Builder. And then we're going to do some QA.

So let's dive right in. WebObjects is a highly scalable, enterprise-level application server built around the model-view-controller paradigm. We've got three sort of framework layers. Our data access layer. Business Logic Layer is where you're going to write all of your application-specific business logic and presentation layer. There's a clean separation between each of these levels of the frameworks.

And we're going to talk about each of them in turn today and the tools you'll use with each level of the architecture. So the WebObjects Framework Stack at its very base It's built on the Java Foundation classes. If you're familiar with Cocoa Development, Java Foundation looks a lot like the regular Foundation classes. It's sort of a Java port. That's the base upon which everything else is built.

The next layer up is our Enterprise Objects Framework Stack. EOF is used for relational database to object graph mapping. It's built up of three actually different frameworks. EO Access is used to handle all of the The EO Control Layer is where we do all the object graph management once we've turned your database objects into Java business objects. And the EO Interface Layer is mainly used for Java Client. On top of that, we have our App Server layer and our rapid prototyping tools, direct-to-web, direct-to-web services, and direct-to-Java client are built on top of our App Server framework.

Okay, so let's talk about how a WebObjects app does what it does. The main, the heart of a WebObjects app is the request-response loop. So clearly a web app starts with the browser. Browser sends a request to the web server. The web server parses the request it gets, forwards on to the WoW adapter that plugs into your web server, and the adapter then forwards that request on to the appropriate app instance that you have running.

The app instance then parses the request it gets, sends it off to an appropriate request handler, and then each of the classes within your application pulls information from the request it gets. The application gets its chance at handling the request, as does the session, as do your nested WoE components. Once the action you're calling has finished its work, each of those in turn gets a chance to append to response. and your request goes back out or your response goes back out to the browser.

So I want to start off today talking about the different tools in each layer. The data access layer, the primary tool you're going to be working with is EOModeler. The business logic layer, the primary tool you'll be working with is Xcode and your Java classes. And on the presentation layer, if you're writing a web app, you'll be working with WebObjects Builder. If you're writing a web services application, you'll be working with our web services assistant. And if you're writing a three-tiered Java application, you'll be working with Interface Builder.

Okay, so I liken building a web app to building a sports car. You've got to start someplace, you've got to start with the nuts and bolts, that's your data. So... As I said earlier, EOModeler is the main tool you'll be working with on the data access layer. So what is EOModeler? EOModeler is the face of the EOF frameworks.

What does EOF do? In a nutshell, EOF does object graph management. It takes a relational data store, turns those rows in that database into Java business objects, and manages the object graph for you. So tables in your database map to entities in EOModeler. The columns in those tables map to attributes, and the joins between those tables map to relationships between the objects in your graph.

Use EO Modeler for building all of your data models. If you've got a large existing relational database installation that you want to expose to the web, you'll be using Modeler to reverse engineer your database, publish it to the web, turn it into a web service, turn it into a Java app. Chris Pavicich Use WebObjects Builder for modeling your entities. If you're starting from scratch and you're building a new database, you can use WebObjects Builder to model your entities, and then it'll do SQL generation for you, and you can create your database directly from Modeler.

Once you've got your entities modeled, EOModeler does source code generation. It's just a simple matter of opening your model, selecting an entity, and hitting "Create a Java Class for this entity." There's data browsing capability within EOModeler, so if you want to see that, hey, is my connection dictionary right? Am I talking to the database? Load up your model, pick an entity, hit browse, and it'll automatically fetch for you. New in this release of WebObjects today, new in 5.3, there's an Xcode plugin for doing EOModeling. Based on some of the core data modeling tools, I think you saw it in the presentation earlier if you were at the overview session. So that's new today.

So the great value we think that WebObjects brings to development is how quickly you can go from database to model to working prototype to refining that prototype to having a great world-class application. So we've built some prototyping tools on top of the WebObjects stack. The idea here is we want to get you going in sort of less than five minutes, writing no code, so that you start off, model your data, boom, here's something to show the boss, here's something to show the client, here's something to validate that my idea is a good one, and go from there.

tools are great for building proof of concepts. They make wonderful internal tools. If someone else manages the content in your database, here let me model the The database for you. Let me build a direct-to-web tool, and now let me hand it off to you, and you manage the database. Here's your tool. It just works. You just go. Makes a great database administration application. Chris Pavicich So there are three direct-to technologies.

Direct-to-web takes your model, turns it into a web app. Direct-to-web services takes your model, publishes it as SOAP APIs. And direct-to-Java client will take your model and turn it into a swing-based, double-clickable Java client application. So we can switch to the demo machine. I want to show you EOModeler this morning, reverse engineering, an existing data store. Just a show of hands, how many people managed to download the sample code and will be following along? Okay, a couple of you.

I'll try not to move too fast. So you open the trading card demo, open the EO Modeler, The first thing I'm going to do here is build an OpenBase database on this application. OpenBase ships with WebObjects. So I'm going to open the OpenBase manager. Let's come up. On the left-hand side, I'm going to select local. Under this action menu, I'm going to select new database. And we're building a trading cards app.

Did you all see the Meet the Engineering? Meet the Tiger Engineers, WWDC promo. Yeah, familiar with that? So we, our group, are really cottoned to that, so we've based our demos around it. So we're gonna call this database Trading Cards. Hit Create. And I'm going to hit Start Database at boot just in case my machine crashes while I'm running here. And I want to save changes.

Select the Trading Cards database I created. Hit Start. It's going to start up and... In the one pre-demo folder in the trading cards demo, there should be A file called Trading Cards_ASCII Backup. So what I've done is I've pre-built this database and then dumped it as ASCII. So under the Action menu, I am going to restore that database from ASCII. Yes, I want to restore it.

That's a surprise for Chris. This didn't have a password when I saved it.

I'm going to start up one of the other pre-existing databases on this box and demo using that. So I've started up the WoMovies database and I'm going to start up EOModeler. Okay, we're creating a new model, so UL modeler is running. Select new.

Now the EO Modeler is going to bring open a wizard and ask me some questions about what type of data source I'd like to talk to. EOF natively will plug into JDBC and JNDI data sources. So most relational databases have JDBC drivers. Most LDAP servers provide some sort of JNDI interface. You can actually write your own custom adapter if you're so inclined. We're going to go with JDBC.

Okay, back to the original demo. So I'm going to restore...

When I restored that from ASCII, you see a terminal window came open, some SQL ran, and some rows were loaded into that database. So have you all caught up? I'm sorry for the confusion this afternoon. So we're going to switch back to EOModeler. And in that folder that you found the ASCII backup, there's a set of instructions with screenshots walking you through this. I'm just going to grab the URL connection string for this database, copy it.

Now, the modeler is going to ask me what I want to do with this model. What am I interested in getting from the database and including in my model? I want to use EOF to assign primary keys, so I'm going to leave that selected. I'm interested to see if there are any joins set up in the database, so I'm going to leave asking about relationships selected. But I'm not interested in stored procedures or custom enterprise objects, so I'm going to uncheck the two of those and click Next.

So now what happened here is modeler connected to the database, got a list of all the tables associated with that connection dictionary, and it's populated this table view here. I'm interested in all of these tables, so I'm going to hit Select All, then select Next. Now the wizard's done. It's collected all the information it needs, and it's built a model for me.

So if you've never used EOModeler before, what you have on the left is a list of the model name and all of the entities associated with it. And by selecting an entity, what I see on the right here in the top of the split view is the web-based assistant.

He will be talking about the web-based So I need to set up two relationships here for my application to run. Each of my trading cards, every person that's represented by a trading card has several powers and we have a picture of them, we have an image. Under Properties, I'm going to add a relationship to trading cards. Select that. Open the inspector and we'll do the image first.

So I'm going to give the Relationship the name of image. It's 2-1, and we're connecting... The trading card entity to the image entity, and we're using Image ID is a foreign key, row ID is the primary key, and then I'm going to hit connect. So, give you a second.

Your screen looks like this. Now, on the trading card entity, we now have a new special kind of property called the relationship that will traverse those two tables. I'm going to select Trading Card again. Under Property, I'm going to add another relationship.

: Thank you, Chris.

Thanks, Chris. Okay, so I went to save my model there. I hit Command-S. And EOF and the EO Modeler went through a consistency check. So what it did was basically parse through all the model, looking for problems. We see here attribute row ID and entity image begins with a capital letter, which is not recommended.

It's not fatal, but the EOF stack is basically just telling us, hey, this might be a problem later. If it were fatal, it would stop us from saving the model and say, no, before you proceed, you have to fix this. These are just warnings, so I'm going to click through them. And we will call this training cards. And I'm going to save it as training cards. on my desktop, oops.

I'll replace the one I had there. And one of the features I mentioned earlier was data browsing. So I'm going to select the trading card entity. And this icon here in the top toolbar looks like a magnifying glass connected to a cylinder. It's the browse data.

So you can see, yeah, my connection dictionary does work. EOF is really fetching data from the database. We're good to go. So we're going to hide EO Modeler for a second. And back to the sample code.

I've pre-built most of these projects in the demo code folders today, so if you've gotten behind, to quickly catch you up, where we're at is to post-demo. So now that we've built our model, what I want to do is build an application prototype out of it. I want to see that... My proof of concept is sound, that my model is good. I want to see what it's going to look like on the web. I want to show my boss, maybe. So we're going to build a direct-to-web application. So I'm going to open the trading cards_d2w application and find the Xcode project.

I have an older version of Xcode here, so if any of you have the older version of Xcode installed today, and you're opening an existing project, it's going to ask you to upgrade a copy. You should hit upgrade, it's okay, and give your project a new name, hit save. I brought my project up. I'm going to build and run.

Building a direct-to-web application and you're starting from scratch. We couldn't for the sake of time today. Launch Xcode. Tell it you want to build a new project. There'll be a project assistant that comes up and will walk you through building a direct-to-web application. It'll ask you which frameworks you'd like to include, what models you'd like to include, and go from there. So our project is done building. It's now running. We build a login page by default. Whatever values you passed in here, if you needed a connection dictionary, username and password, and EOModeler, you'd provide them here. We don't, so I'm just going to hit login.

And the default page in DirectWeb is the Find page. See a list of all the entities that we had built in the model. I'm going to hit I'll leave the Find button next to Trading Card. And there we go. No code, very little effort. I've got a simple, pleasant-looking web app talking to my database. I can create new instances of any of my entities. I can search on any of them. So, as you can see, DirectWeb is a great, rapid application prototyping tool. If we could go back to the slides.

So what have we seen so far? We've seen taking EOModeler and reverse engineering an existing database. Then we took that model that we built and built a very quick direct-to-web app out of it. The next thing we're going to talk about is writing custom logic. EOF and the WebObjects frameworks do a lot of heavy lifting for you.

We've worked hard, so you don't have to. We've thought a lot of the issues through, so you don't have to. So what do you have to do? You have to bring your domain expertise to the problem. Most likely, the rows you have sitting raw in your database, translated into objects.

They might be of great value to someone that way, but they're probably of greater value once you add

We can build a workable application. You're going to build a great application. And part of that is building your logic. I call this fine-tuning a well-oiled machine. WebObjects works great out of the box. You just saw it. We built a model, boom. We built a direct-to-web app, boom. But it's not yours. You need to make it yours.

So we're now into talking about the controller layer of MVC. We're talking about business logic. So we're going to be spending quite a bit of time talking about custom-generated Java code from your model. And you're going to be modifying that Java code, and you're going to be doing it using Xcode.

Xcode is the preferred IDE for WebObjects development on Mac OS X. does all the typical wonderful IDE things, compiler, debugger, version control. We're supporting subversion, Perforce, CVS now. All the documentation you need while you're building your WebObjects app is accessible from within Xcode. And it comes with a bunch of project assistants to help you get started.

We don't want you simply sitting in front of the blank canvas that is an empty Xcode project and wondering what to do. So if you're creating a direct-to-web app, there's a direct-to-web project assistant. If you're creating a standalone web app, there's a template to get you started there.

So now I'm going to take the-- go back to the demo machine. I'm going to show you a quick demo we've come up with. I've taken that model that we created earlier created some Java classes for it and actually created a WebObjects project out of it. If you're following along on your laptops in the audience, we're on the 2_Xcode folder and within there you should find a folder called Trading Cards. If you want to open that up. And open up tradingcards.xcode. Again, this is an older version. This project was saved with an older version of Xcode, so it's going to ask me to upgrade a copy. I'm going to do that.

For those of you who aren't familiar with Xcode, I'll give you a really, really quick tour. I highly suggest if you haven't used Xcode, check out some of the other sessions today. It's really out of the question. Out of the scope of this talk for me to go into all of the ins and outs of Xcode, but all Wo projects are basically organized the same way within Xcode. Your classes are in the classes.

: Thank you, Chris. Thank you, Chris. I'm going to go ahead and get started. So, we've got the Web Components container, your WoE components, the building blocks of your UI are in the Web Components container. Any resources, images, the model that we added to this project, any properties associated with it are in there.

So as I said, I pre-built this demo from within. EOModeler, I generated this trading card class. I'm going to open the editor here. And this is the code that Eel Modeler generated for me. Every entity and I'm sorry, every relationship and attribute on this entity have accessors and mutators.

One thing my object model was missing, one thing this entity was missing was a full name field. There was fields for the engineer's first name and last name, but nothing for full name. So I've written That bit of custom logic here. So method returns a string, and all I'm doing is calling the surname and first name accessors, concatenating them, comma delimiting them, and returning them. So now I'm going to go actually use that in a working app. So I'm going to hit build and run.

So here are my trading cards. They're not pretty, but if you look, Using WebObjects Builder earlier, I managed to write a custom accessor, some custom logic on my trading card class and bind it to the UI, and it works. Obviously, this is a very trivial, very simple demonstration for the constraints of time today. There's a lot more that you can do. If we could go back to the slides.

Back to our sports car analogy from earlier. You assembled your nuts and bolts. You built your model. You generated some Java classes. You wrote a bunch of custom business logic. Things are looking good. runs like a dream. So far it doesn't look like much though. My direct web example was cool. And it looked okay, but it's nothing you'd sell to a customer. It lacks a certain... Customization. So it's all about the chrome and the racing stripes.

We're going to show you how to do that today using WebObjects Builder. So we're going to go ahead now and talk about the last part of our MVC paradigm and talk about the presentation layer, view layer. Today I'm going to talk about WebObjects Builder. WebObjects Builder is our visual content creation tool. Use it to build WoW components out of the base dynamic elements that ship with WebObjects. WebObjects Builder ships with a rich collection of reusable components.

You drag them together, plug them together.

So the point of WebObjects Builder is you've got this data, you've got this business logic, we need to tie it to the UI. We need to bring it all together. So that's what you spend most of your time doing in WoBuilder is saying.

Got this. How do I display it? One of the cool features of WebObjects Builder, pushing the idea of rapid application development is our rapid turnaround mode. Once you get your projects built, your custom classes written and all that, you want to sit down and tweak the UI. You want to make it great.

A rapid turnaround mode helps you with that. The idea is why should you have to Recompile your app every time you make a UI change. So open your app in Xcode, get it built and running, open the component you're working with in Xcode, Your project's running. Open it in your browser. Tweak your component as you see fit. Reload your page in Xcode, or reload your page in Safari. Repeat the cycle. No stopping your app, no rebuilding.

A bunch of new features today in the new release of WebObjects Builder. We're really trying to push our standards compliance forward. It's one thing we've gotten a lot of developer feedback from that, hey, you guys are supporting HTML 3 point something that's a thousand years old and we don't like that.

So today we're supporting HTML 4.0.1 transitional. We've improved the HTML generation in the frameworks for people who are doing work with XHTML. XHTML isn't supported in WebObjects Builder yet. I don't want to give that misimpression, but we're working towards it. And we improved our CSS support. The newest, biggest, greatest feature, I hope you guys love it today, is our WebKit-based preview mode. The preview mode in the previous WebObjects Builder was lacking.

is the founder of WebKit, and he's going to talk about some of the features that we've An extended version of WebKit that will support rendering all the WebObjects tags that you throw at it. And what we wanted to really give you out of the box was what you see is what you get in the preview mode. So hopefully it will look in preview mode as much as possible as it will look like in Safari as the same rendering engine is being used.

We haven't talked about what you build with WebObjects Builder yet much. We've talked about the parts of the data model. We've talked about Xcode tweaking your Java classes. We haven't talked about WoE components. WoE components are the building blocks of your UI when you're building a web application with WebObjects.

I'm sure you've all seen the store before. The store is a WebObjects application, and there are lots of Wo components on that page right there. So, all WoW components start out with an HTML template. They define the look of the template. Looks a lot like standard HTML, except for these WebObjects tags.

The other part of the component is the WAD file. The WAD file is the glue between your template and your app logic. It's how you say, I want this object represented in this way. And when we do the WebObjects Builder demo, you'll see how the WAD file comes into play. And the last part is the Java class that defines the logic of your component.

How does it respond to this action? How does it respond to that button being clicked, this link being clicked, etc., etc.? All that gets defined on a per-component base. Every component has its own Java class holding its implementation. So what are these going to look like in your project? You're going to see mycomponent.html, mycomponent.wad, and mycomponent.java.

The top two items, the HTML and the WAD file, get wrapped up into a .woe. It's a bundle. It's what WebObjects Builder opens. It's what you'll see in Xcode. Generally in Xcode it shows up with a disclosure triangle next to it so you can see all of the three individual components, but .woe. So now if we could go back to the demo machine.

So I'm going to launch the new WebObjects Builder. If any of you installed the new Xcode 2.1 DVD that came out today, and you installed the Xcode tools, there were some postings to the mailing list last night. The new WebObjects Builder appears to be broken. There was a defect we found that the old WebObjects Builder was not being uninstalled. So just to be sure you're running it from the correct place.

The new WebObjects Builder is installed in Developer, Applications, WebObjects, WebObjects Builder. It's safe to delete the old one. So I talked about the WebKit preview mode. I'd like to do a quick demo of that. Take the Apple homepage. The source. Copy all this. I'm going to paste it into the source view, and I'm going to switch to preview. Oh, look.

I don't see any... You notice it loaded the images? And I don't see any JavaScript on this page, but had it been there, it would be running right now. So the WebKit preview mode is really just about as close to Safari as you could possibly get. Okay, so... : So, for those of you that are new to WebObjects Builder, let's talk about what it is, how it works. You saw the preview mode, that's cool. In the layout mode, actually let me open a component.

For those of you that are following along, I'm going to open the three_wob trading cards demo, and I'm going to open the main.wo. So this is our layout mode. The idea is build your WoW components visually. Drag in either HTML elements, WebObjects elements, form elements, down into this layout mode. And let me open this project in Xcode so you see the full integration. Again, it's an older version of a project. It's going to ask you to upgrade a copy. That's perfectly safe. Just give it a new name.

I'm going to reopen that component. So the layout mode is really split into two separate views. The top, there's the content view. You're looking at A visual representation of your page, the elements on it. And at the bottom you see all the classes contained in your Xcode project. The application class, session class, and I generated Java classes for the three entities in my model, card, power, and

I'm going to blow some of this content away and we'll wire it back up.

So I want to display the name of each person, each card in this component. So I'm going to add two WoW strings. And I would like to display the cards. First name and we'll insert a space and their surname. And all I did here to connect that, I'll show you again, is click, drag, and as you get to the component you want to bind it to, it highlights. And just lift the mouse up.

You switch to the source view. Again, two split views. At the top you see the source, the raw HTML and CSS of this document. And at the bottom is the WAD file in its textual form. So the... We won't dive too deeply into how the WAD file works, but it's basically-- Element Name, Element Type, and then this is a string. String most commonly has its value attribute bound. This string will display the card's first name. So, it's great. We have it all wired up. Switch back to Xcode. build and run the app. Take a minute to compile. It's up and running.

There's our display group displaying each of our cards. Navigate through, change how many I'd like displayed. If you notice, look through the source code. I didn't write any code to fetch these objects from the database at all. Zero lines. The Display Group handled it all for me. EOF did all the heavy lifting. All I did was create a new project, bring a model into it. From that model, I generated some custom Java classes.

and then in WebObjects Builder, build a WoE component, tied the Data I wanted out of my entities from my model to my UI, and there we go. One of the things to notice here, if I could switch back to WebObjects Builder for a second, is

using CSS. There's the raw HTML. So we talked about the rapid turnaround mode earlier. I threw some CSS into this to make it look a little nicer, to make it look a bit more professional. So I'm going to go back.

We saw WebObjects Builder. It's not really hard to build great-looking components, to build great-looking apps. The separation between the : Thank you, Chris. I'm going to go ahead and get started. So, the WAD binding your actual classes to your UI and the presentation layer being stored in HTML is a good one because you can hand off those HTML files to someone who's is, frankly, probably better at UI design than you are, a graphic designer, someone who does that for a living. And as long as they don't strip the WebObjects tags out, : Let them do their thing. Hand the HTML back to you. You've got a top-notch looking site. So, what have we covered today? We talked about the WebObjects architecture.

We talked about developer workflow, using EOModeler to create new database schemas and new databases, reverse engineering existing data stores, rapid prototyping with our direct-to-star technologies, direct-to-web, direct-to-Java client, direct-to-web services. We talked about writing custom business logic in Xcode, working with the different WebObjects projects in Xcode, and we talked about WebObjects Builder and using that to write a top-notch web UI.

If you have any questions, need any documentation, More sample code, other resources, developer.apple.com/webobjects has just about everything you need. There are some related sessions I encourage all of you to check out, whether you're new to WebObjects or whether you're a long-time veteran. The next session in this very room at 5 is WebObjects and J2E deployment. I'm going to be talking about once you've built your app, how do you get it running in a production setting? That's session 610 today, this room at 5:00.

There's an Administering MySQL Databases session, session 648, Thursday at 9:00. Configuring and deploying Oracle on OS X Server. We just got certified with Oracle 10G and WebObjects, so Oracle's like one of the most popular relational database systems in the world. If you're using Oracle, check out the Configuring and Deploying on OS X Server session. That's Friday at 9.

This is probably going to be the most fascinating WebObjects session of the week, bar none. The performance optimization session, 6.37, Friday at 2 p.m. We invited a bunch of guys from the iTunes Music Store to come out and tell their horror stories. Chris Pavicich If you don't know, the iTunes Music Store is the largest installed WebObjects application in the world.

It's a beast, and these guys have seen everything. If you've done a deployment and had a problem, They probably have a story that can top you, and they're the right guys to ask the questions to. They're brilliant. It's a fascinating session. That's again Friday at 2, session 637.

And we're going to be around in the Enterprise IT Lab all week. We have dedicated time Wednesday at 9 a.m. If you have any questions about development, deployment, you're new to the tools, you're old to the tools, come and see us, come and hang out. Enterprise IT Lab, Wednesday at 9. and our Java and WebObjects Feedback Forum, session 641, Friday at 3:30 PM. Please come and let us know how we're doing. Let us know what you'd like to see, what you hate, what you love.

Who to contact for further information? Send email to [email protected]. We are listening. We love to hear what you have to say. If you find bugs, bugreport.apple.com. Please, please file radars. We love hearing your feedback. We want to fix it. We want to make it a great product. File bugs.