Good morning, ladies and gentlemen. Bob said it really well at this early morning. Everybody's taking really useful polls, so I will have to do the same. Who would not be up at this very hour if it wasn't for this presentation? Thank you. I hope you have muffins, orange juice, and all the other goodies that they're handing out for free, so at least it's free food. I'm Stan Jiurman, and I will be joined in a minute by Tom Naughton, who will be giving the demos for this presentation.

What's in this beautiful talk? Because it's so early, we tried to put many demos in there so that you don't quite fall asleep. We'll be discussing the new features in WebObjects 5 and the WebObjects tool integration. We've had presentations on WebObjects Builder before. We had other sessions talking about EOModeler, so we'll not address those in too much of a depth.

We will be talking about the project builder assistants. At this point, you're probably realizing this session should have been earlier. And I don't mean like at 7 o'clock. I mean Tuesday, because you've seen all those assistants since, but we will talk more about them. We'll be discussing the project structure, which has changed quite dramatically since WebObjects 4.5, or even the prior versions. We'll be talking about rapid turnaround mode.

That's the nifty thing that you don't have to compile a product, and it still works. We'll explain to you how it works, or why it works, and why it sometimes doesn't work. We'll be discussing the CVS integration on examples of WebObjects. We'll be talking about the installation of a built product. And we'll be discussing, or just briefly touching, custom palettes in WebObjects Builder.

Project builder assistants. Now you've all seen them. You've seen probably all of them. And you've seen probably only one kind, the project assistants. The project assistants are those that help you set up a new project. File assistants are assistants that help you with an existing project to add more and more stuff to them. As I said, project assistants help with new project creation. They build a fully functional, compilable application skeletons for you from scratch. And they add resources based on what frameworks you choose, what model files you choose, et cetera.

What's new in web objects 5? For those of you who have been using web objects for a while, now you can add multiple EO model files to a project right away, which is really helpful because then the formal wizards, now assistants, go with you through the whole process of reverse engineering.

And you can get consistency errors if you have only one model in the project. You can also add frameworks, which again allows you to structure your product nicely and have EO models in there. And of course, the new features of EO, EOF Cocoa applications and all the new Java stuff.

The file assistants, once you have a functional product, project, excuse me, then those assistants are used to add new things to your project. Java classes, nice templates with names and everything filled in, web components, they get already a little bit trickier, and Java client MIPS. That's the trickiest part. So that's done all for you, and Tom now will come on stage and will show you something about the assistants. Okay, so as Stan mentioned, you've probably all seen the assistants by now, but let's just consider this a comprehensive review.

So this is, of course, the assistant panel in Project Builder. The WebObjects assistants are all at the bottom. I'd just like to go through and explain what each of these is in case we haven't covered them all consistently. The first is the Cocoa EOF application. This is the replacement for using EOF in Cocoa applications.

It basically just copies the standard Java Cocoa project template, adds our frameworks, and guides you through creating a nib, much like a direct Java client, as you've seen. The next two, Java client, direct to Java client, and direct to web, basically just ask you to choose a model. Direct to web asks you to choose an appearance for the application.

Then it just builds and runs the application, and you customize all the features at runtime. Display group application I'm going to use in a minute. You've seen it many times. It creates a component with a preconfigured display group, which is a kind of a Swiss army knife controller object that manages a set of EOs for display. The next two are basically just template copying assistants.

They just copy the standard basic WebObjects application and WebObjects framework projects, and just customize them with the name that you add. So I'm going to go through and do the display group application, because I basically need an application to do the rest of the demos with. So we give it a name.

And this panel is actually one of the new features in WebObjects 5. Previous versions of the wizard would just let you choose one model, and that made it difficult if you had frameworks containing models, or if you had multiple models with cross-model relationships. So this actually makes it a lot easier to do things that you couldn't do before. I'm going to add a business logic framework.

And you can see in the next panel that that framework contains two models. I could also add additional models. And as long as they don't have conflicting entity names, I could use that entire model group for the rest of the wizard. Next we choose the main entity for the main component. I'm always going to go with movie.

There are various options for the layout that you want. For example, you can just have a big list of all the attributes that you choose, or you can have a list of EOs represented by the attribute that you choose, and then clicking on it will display more detail below that you can edit and use to create new EOs. I'm just going to go with the list of EOs and what I just explained.

Anyway, okay, so we need some attributes, and I'm just going to show off that you can select multiple attributes and add them all at once. I think I want to do that. And then I need to choose an attribute to use for the hyperlink in the list of the EOs. And I just click on Finish. Okay, so basically you've seen this type of project a number of times before. It's created this component with a pre-configured display group.

Since this is the assistant demo, I'd also like to show you some of the file assistants, which I don't think people have been showing in other demos. So again, the WebObjects assistants are down at the bottom of the screen. You'll notice that there's a Java class assistant here and another one up here under Cocoa.

And the basic difference is the template has different import statements. So if you want to import the Cocoa frameworks, you would choose this one. If you want to import the WebObjects frameworks, you would use this one. We're just going to create a new component. Oh, and actually this reminds me. One important thing when you use the Project Builder assistance is you have to choose the group that you want to add the component to, or it'll just add it wherever the selection is.

So we're going to just create a new plain old vanilla component. We get a list of the targets. Many of the assistants don't give you a list of targets. They just know which target things go in and choose it for you. But since this is a built-in project builder template copying wizard, we have to choose the target. We're going to cover targets a little bit later. But the important thing here is that you pretty much never want to add things to the main target.

And you want to add all of your components to the application server target. So I'll go ahead and do that. And we have this configured to open the Java file. You'll see that it's added that with the other components. So the other way to create new components is to use the builder.

And when you save the component, if you save it in the project directory, which it'll try to do by default, It'll ask if you want to add the component to the project. Say yes, it asks if you want to create the Java file. You pretty much always do. And that'll also just stick the new component into the project. So you can either use WAB or use one of the wizards.

I'm just going to build this so that we can do the next demo. But there's really no need to run it. You've seen it many times. So, Stan? All right. Now just sit here. Stay with us. All right. Don't run away. So back to the slides, if we can go. Yes. Tom pointed out initially in the assistants the Cocoa EOF application. I'll repeat after me. That's in Java.

Let's go into the next topic, the project structure. We saw Tom talk about targets, buckets, and we will also touch a little bit of mystery files, which was selected as the last file on the previous demo screen. Now, what is a target? Target is something new for at least the legacy WebObjects developers. It's a notion that comes over from old Mac OS.

It allows you for a file to be part of multiple different You can have a file being-- OK, it's complicated, you see? I mean, I work with it, and I don't know how to explain it. A file can be part of multiple targets, and a target describes where that file, when it's once built or copied in the finished product, where it will be.

So in a typical deployment scenario for WebObjects, we have an application server. Then somewhere we have a web server. Sometimes it's the same machine, but typically it's not. There's a firewall. They forgot the fire. The servers connect through the firewall to all the clients. So we see that in the typical scenario we have the app server and the web server apart, and usually it's maybe even more computers.

The web server target, which is part of any WebObjects project, you put static stuff there, stuff that just doesn't change. Things that the web server has to fetch from disk, and that's it. Static images, static HTML, client-side Java classes because they just get downloaded to the client over the network. Java client Nib files, same thing. And anything that gets access through normal URLs. Now here, because this is so late in the week, you already know what normal URLs are. It's this non-so-fancy or not-so-ugly looking thing.

Then, to complement that, we have the application server target. This one is used for all the dynamic content, server-side Java classes, web components, that would be what Tom was creating with Objects Builder, EO models. These are also dynamic. They're considered dynamic, and also, they're used by the application and by the web server.

And images generated on the fly. An example of an image generated on the fly is, you have already, hopefully, visited the Apple Eye tools with the eye cards and sent nice, cute little postcards to your mom and dad. This is an example of a picture generated on the fly.

Warning. If you don't know what you're doing, don't touch them. Don't mess with them. Don't rename them. The targets, they are-- They depend on their names and don't modify them. Tom will show later when he's giving the demo about targets what you really shouldn't touch. There's a lot of settings. And if you really don't know what you're doing, just please stay away.

Buckets? What buckets? In previous versions of WebObjects, we had this old project builder, now known as Project Builder Woe, except on Windows, where it's now known as the Project Builder.

Ah, those buckets. "Mystery files." Some of you may be wondering, "What are some of those files that are there?" Let's delete them. They just take space and nobody really uses them. It doesn't complain when they're gone.

Two mystery files. The woohoo file. Woohoo. Display Group Definitions. You've probably heard what a display group is. It does a lot of nifty stuff for you, connects things for display, etc. That is defined in the Woo file. You delete that file, oops, not good. Component encoding, even if you don't use display groups, many, especially advanced users, I guess, are not using the display group so much.

But you might be interested in your data coming into the browser with the proper encoding. You're talking to a Japanese client, it comes in Latin characters, not so good. So this is all stored in the component encoding section of the Woo file. The second mystery file, we got new icons, by the way, is the "A" file. This API file is in XML format, following the new great standards that we are following.

It's used during development only. It tells WebObjects Builder what are legal and what are illegal bindings. So it won't allow you to make a connection that requires an array to something that's a flat thing, etc. And if you delete that, oh well, it will live. It's used during development only, and in your build project, you don't have to have it there. Now, as I promised in another demo, Tom will talk about targets.

Okay, so first I wanted to open up some of these groups so that you can see the default project organization. And again, these groups are basically just a figment of project builders' imagination. It doesn't correspond to the layout on disk. It's just a convenient mechanism for you to organize your project.

One catch, though, is that our wizards, our assistants, have preferred groups that they like to put things in. So that, to make it easy, when you create a new component, you know, "Gee, where did it put it in my project?" You know, it put it in Web Components. Let's see, so we have classes go up here.

We have the group with the Web Components. Each component is in its own group. If you don't like that, you can just completely rearrange that. You can put them all in one group or each file in another group if you want. Resources, let's see. Whoops. That's annoying. - Annoying.

Basically, you would put your application resources, the ones that go on the application server side, generally go in there. The web server resources are GIFs and things, as Stan mentioned, that need to be copied to the web server. Interfaces is the location where it would put nib files for Java Client or Cocoa EOF Client.

Frameworks bucket, of course, contains frameworks. One interesting bucket is the built product bucket. It's actually a convenient way for you to go and look at the structure of the bundle that was built for your application. For example, if you have a burning desire to see the Windows launch script, you can just drill right down into it without having to use the finder or terminal. Don't show it to people yet. That's at the very end, just before they walk out. Don't show it yet.

Yeah, let's just start showing that. This is where it appears in the project, but we're not going to discuss the project structure until later. Okay. As was mentioned by Stan. Let's see. I also wanted to show you the targets. There are two different ways of looking at targets.

To me, the most convenient one is in this view. There's a pop-up that shows all the targets. When you choose a target, it puts a little donut next to the file that is in that target. If you want to add a file to a target, you just turn on the donut.

To remove it, you turn it off. You can see here that all the classes, all the components, all the frameworks, and even the web server resources will be in the application server target. Then looking at the web server, you'll see that it's basically just the web server resources, the GIFs, and some frameworks.

So basically, these GIFs will be copied both to your web server and to the application server. You probably won't always need to have the GIFs in the application server side, but if you dynamically create images, it's convenient to have a copy of them there so that you can access them. That's sort of up to you. The frameworks are included in both targets. You can use the targets so that your Java classes can have access to any of these frameworks. I think that basically covers targets and project structure.

Oh yeah, I'm still here. I was just looking. Come on, it's too early. Oh wait, no, I'm sorry. There's another way to... He is also one of those people who should have raised the hand of not even being up at this time. I looked at my script and noticed that there's another way to look at targets. You can click on the Targets tab, and it lists the three targets. And what's important to note here is that the application and web server target are both sub-targets of the main project target.

And so the whole reason the main target exists is just to build the other two targets. You never put anything in there. It's just sort of a convenience so that you wouldn't have to build the two targets independently. Now, show also why people shouldn't touch them. Show the scary stuff now.

The scary stuff, yes. So that they know the stop sign. Yes. When you click on these targets, you get another view of the target that shows you all the files that's in them. You could drag and drop files from the finder into these buckets as another way of adding files to targets.

And down here, there are-- There are scripts and various settings that you probably wouldn't want to mess with, such as... These are some build settings for the targets. If you really know what you're doing, you might want to mess with some of the flags sent to the Java compiler, but chances are you wouldn't want to mess with most of these things. So basically, targets are there for you to add and remove resources and files to, but unless you really know what you're doing, you should probably just leave them alone and not create your own targets and certainly not rename them.

I'm going to finish this time. Sounds lovely. And when we go back to the slides, I'll rewound a few. That's why I was not paying attention. For recap, two targets-- the web server target, static stuff. One of the examples Tom has mentioned that you can put a file into more than one bucket, excuse me, target.

Static image might be an example or an image in general for the static version that just gets downloaded to your client. And maybe your application will want to do something with it, be creative with it. Again, my favorite example, those iCards. When you first come to the selection of I want this picture, I want that picture, I want that picture, it's a static image. It's just showing them to you. It's not doing anything with them. However, later, when you actually start typing text and it shows you a preview of that slide, that card, it became a dynamic image. So it has to be on the application server as well.

There is no need to put a Neo model to both targets because WebServer won't know what to do with it. But some resources, also some Java classes that might be used to put them into both. A Java class might have some business logic that's used by the application server, but it's also used by the Java client, and everything for the Java client has to be in the WebServer resource. And again, as Tom said, you saw that really, really crafty page with 10,000 settings, which very few people understand. Don't mess with it.

And now beautiful animations. I mean, could not have done it any better. And let's go to the rapid turnaround mode. The rapid turnaround mode we all have seen, and we love it so much. How does it work? Why does it work? Why does it sometimes not work? First, what does it do for you? It improves the development time. You don't have to go through the whole build cycle. Usually, you change a resource, you change something fancy, you just press refresh on the page, it looks different.

So, that's nice. No need to perform a full split-install. Remember the beautiful firewall picture? App server, web server, two computers, nasty. You really don't want to do it each time when you build your project. This one allows you to not even rebuild the project, forget about the split-install. Split-install joys to be discussed later. Allows tweaking of HTML files and images. You don't even have to have a web server. Everything is done on disk.

I like traffic signs, not necessarily those, but Project Builder needs to be running while you are in rapid turnaround mode. So you can't, for instance, just have WebObjects Builder running, tweak some components, press refresh, and expect something to happen. That's not going to happen. That's because WebObjects Framework and the WebObjects Builder are talking in the background with Project Builder to find the resources.

There is this really fancy thing, thank you Tom, the abstraction layer that abstracts communication between all our tools, the WebObjects tools, and the proper OS X development tools. As I said, it used to be that through this whole bucket thing, everything had to live in one directory. And so we could find all the resources where we wanted them, because they were in this little directory. Now you can have resources spread out on the network, anywhere in the file system. So we have to find them.

Only Project Builder knows where all the resources are, because it's running. It knows it has the project loaded, so when we ask it, "Hey, where's the component blah?" It tells us, "Right here." And we can find it. So it's really important that you have this That you remember to have Project Builder running because otherwise rapid turnaround will not work. And back to our chief demo person. Okay, so now I'm going to run this application, which I see has built successfully. Actually, did I run it yet? Okay, when I build, you have to make sure you're on the main target. Otherwise, your execution button won't highlight.

Actually, as Stan said, there are two pieces to rapid turnaround. One is your WebObjects application talks to Project Builder. The other is WAB talks to Project Builder. That's actually two different code paths, and there are some subtle cases where they behave slightly differently. One example would be if you edit an EO model in EO Modeler and save it, WAB will notice the changes and they'll show up in your variables browser. But the running application won't refresh the EO model, so you have to relaunch.

But not rebuild. Yeah, you don't have to rebuild your application, but you do have to relaunch it. And sort of the way it works internally is the WebObjects framework basically treats Project Builder as your application bundle. It doesn't even look in the build bundle. It just talks to Project Builder whenever it's looking for a resource. So basically if you add a resource, it'll always find it without the need to rebuild. So, okay, we've run the application.

And we've got this component. - What? Let's see. And the way it's working is it's actually pointing to the very same file that you're editing in the builder. So if you change your component-- If I refresh in the browser, not home, refresh, it'll update right away. And also, if you drag in a GIF-- and I believe I have some graphics on this machine somewhere.

will drag in a moose to beautify our application. Let's see if I can have Project Builder showing the background so that you can watch it put the GIF where it goes. So, OK, finder. We asked for a high resolution but didn't get it. No. Let's see. This window's kind of in the way. There we go. Now we can see-- no, we still can't see the project. Here's the project, here are the resources, we're going to drag in the moose.

"It offers to add it to the application, and you can see it's stuffed in the bucket. It's updated in WAB. We now have...is that a moose? Yeah, there's a moose in there." "I know that guy." "It's behind the tree." "It's hiding. I mean, you know, moose are shy by nature." "We save the component. Switch back to Internet Explorer. Hit refresh."

Let's go back to the lovely slides. So much for rapid turnaround. CVS integration in Project Builder.

I don't know if you've been to the Project Builder sessions. We scheduled the WebObjects track so that you can always go to the Project Builder sessions. There was always nice gaps. They could have been used for lunch and other breaks, but Project Builder was the thought. This was discussed there. What is CVS? We'll show you in our session briefly how it really works well with WebObjects as well. What can it do for you on OS X and what is it? What is CVS? Concurrent versioning system.

It's open source, which is great these days. It's not owned by a single gigantic company who wants to own everything. It comes pre-installed with the developer version of OS X. So we kind of know it's there. We can rely on its presence and on its feature set. It's cross-platform, so even if you're developing on the platform that's owned by one big corporation, you still can use CVS, and we do support that.

It's command line only. Ouch. Don't say that in the Macintosh community. It's very powerful, but also very, very... CVS tends to get crafty. I mean, I read the main pages more often than I would like to, but we use it internally, so it's got to be good, and at least the integration is really good, because all the tools are built to work with CVS.

How does Project Builder help you with CVS? There is this SCM menu, which stands for Source Management Control. It's something Source Control. It shows you where you added and deleted files. That's one of the tricky things. You are on command line, you add a file, you edit to the make file, or what have you, and you build the project.

It's just great. You do a CVS commit. Next day you check it out, and it's not working because you forgot to add it. Project Builder does that for you. It supports the deletion of simple files, as well as wrappers. You know, file wrappers, those really nice things that are a .woe or .eomodeld. They show up like a little file, but if you don't know about it, you add it, and nothing got added because it's actually a directory. So it works recursively. way.

And it allows remote, it supports remote CVS servers with security. So that's an add-on bonus. You don't have to have your CVS repository somewhere on the file system on the network, excuse me, and have everybody see it or not. It supports authentication. Tom, you should have been in the first slide, like Naim. You're doing most of the work here. Show us. Okay, so Project Builder has all kinds of support for viewing differences in your CVS repository, but they haven't added something to allow you to check out a project, so you still have to do that on the command line.

So CVS checkout, CO for short. And we've created a CVS repository on this machine. So that's checked out the Think Movies project. We can open that with the command line too, since we're already here. Uh-oh. That terminal does strange things when you have a large font sometimes. OK, so now we're going to modify one of these components and show you the interactions with CVS. So we'll go ahead and open that in WAB. And let's say we wanted to add a key.

And actually, you have to save the file before it actually checks with CVS. And you can see it's put a little M over here to show us that we've modified that file. So as you go on working, you'll notice M's appearing next to files that you've modified. You can quickly look and see which ones have changed. Then after you've edited it for a while, you'd probably want to go and see how it compares to the file that you originally started with.

So you can go up here to the SCM menu and say, Compare with Base. And that opens both the original file and the modified file in File Merge. So that makes it very easy to go through and review your diffs, which is something that we do before we check in our code.

So Tom, I can do that in command line. My big problem with CVS is renaming files. How many of you have tried and failed to rename a file in CVS? Directories, all this good stuff, you see? But, Tom, do you have an answer for that? We sure do, Stan.

That's the right answer. Okay. Yeah, in general, to rename a file in CVS, you have to remove the file and then add it. And of course, you can't remove the file unless you delete it, so you have to... Delete it, rename it, add it, and remove it to just rename the file. In the right order, of course. In the right order, of course.

But in Project Builder, you can just do a Get Info on the file. And you'll notice that it has-- this is a list of all the CVS commit logs with useful information about all the changes that the engineers made on this project. And to change the name, you just type in a new name. warns me that I'm changing the name. And actually, over here, you'll notice that it's marked the old file for removal, and it's created a new file that it's marked for addition.

Which is a big improvement over what we did before, which would look something like this. Before we check in, we want to review our diffs. "This basically shows you stuff like this." "If I'm in the right direction. But anyway, that was the old way. Now there's the new way." "So when we're all done, we want to check in our project." "You can either select an individual file and go over to 'Commit Changes'" "or you can choose the root of the project and commit all the changes." What you can also do, actually, is you can select a subgroup. Subgroup, subgroup, and it will commit all the changes in that group.

When you're renaming a file, you have to select both files, or you just have to select the supergroup of that, because otherwise it will check in the new file, but it will not remove the old one, so your rename process will be, just as usual, incomplete. Okay, so you're prompted for your helpful and informative commit message. Tom is famous for his really descriptive comments in CVS. Yes, it's important.

All of the Ms, Rs, and As have gone away, and it seems to have left an M up here for an inexplicable reason. So you just put a comment in that file. Can I get at it in some way to see later what you actually did? Actually, I believe I demonstrated that earlier, Stan. You can bring up the information panel.

I mean, you have to check on him from time to time because you never know what he's doing. And in the information panel, it gives you a list of all the helpful and informative commit messages. Well, thank you. Now I know how to keep an eye on you. That's how that works. All right.

So far so good. Now let's get to the really nasty stuff. It's not that nasty, it's just demo is not so pretty. Installation of WebObjects applications. We will now discuss build styles, split installs, and somewhat the content of a finished build product project. Build Styles. We have touched the targets. That's only half of the whole issue in Project Builder. We also have different build styles.

Build styles define different compiler settings in general during different kinds of build. It's used by WebObjects to These describe different parts, where it should go, web server, app server, together with the targets. There's three build styles. There's the one for the development, that's the one that you're using when you're using the turnaround, when you're just debugging your app and still working on it. And there's the deployment one, that you would use to actually finally deploy the application. And there's the third, the web server, which is kind of confusing. It's used to build the product for the web server.

I didn't make this table, but it sure looks nice. Things to install. There is many different kinds of resources that are part of a project. There is the app server resources, components, EU models, et cetera. That's the left column. Then we have the three columns for the three different targets.

During develop-- build style, excuse me. During development, when we're using rapid turnaround, everything gets built into the builds directory. You're building, you're compiling. You can specify in project builder where all your build intermediate products will be placed, usually in a local directory so the file system isn't so busy. But when we actually go to develop and deploy-- good God. When we go to deploy an application, we want to have the finished product built somewhere else. In the application server installation directory, that's where the application eventually will live.

That's so good, so far so good, but the web server resources, they're on a different server. Remember that slide where the web server was kind of behind a firewall and the app server was behind a firewall and they were not really the same computer necessarily? If that's the case, you have to invoke the web server build style as well so that the web server resources actually get copied onto the web server itself. So that's the one big difference. During development, remember, use the development build style. Everything will be just ducky. When you're ready to deploy, you have to invoke both the deployment and the web server build style to get it done.

The second somewhat not quite optimal thing yet, in Project Builder, you cannot invoke the install step from the IDE. You have to do it in terminal. So you have to open terminal and type in pbxbuild install -buildstyle and then one of the two build styles, either deployment or web server, and you have to do both.

And then destrude="slash." Usually you don't want the files, the build target to live in temp, which is where the finished product will be placed, because you reboot the machine and you know where temp went. So you want to have it live in slash so that everything gets properly expanded and is really persistent.

However, you might want to omit the destrude="slash" in case that your actual server is not your development machine, which oftentimes is the case. So you can leave it there. Everything will be nicely installed in temp, and then you can use the tar program of your choice to just tar the whole thing up and move it to your, what do I know, Solari server.

Split installs, once again, require both the deployment and web server build style to be invoked so that the files get in the proper directories. If you aren't doing a split install, if you have one machine that does everything for you, you don't have to do that. The deployment is sufficient.

Okay, now we build it. Now, what's in there? WebObjects 5, as its predecessors, but WebObjects 5 more so than before, is cross-platform because it's Java, which brings some really nice problems with it. The launch scripts. You've been here all week now, and you see that red thing scroll by in Project Builder each time when somebody launches an application. It's no longer just a single word to launch an app. You actually need more to be done because you need to tell the Java VM things, etc.

So, in the OS X and UNIX, for the OS X and UNIX case, there is the launch scripts. They live in the main wrapper and then also in contents/macos app name. That's a little script. It's the same script for both UNIX and Mac OS X, probably because Mac OS X is UNIX. . for Windows deployment. There is the Windows deployment script, which also lives in the main wrapper, and it's called appname.cmd. And it also lives in the proper contents directory. Those two copies are identical, but they're used to be used on Windows.

Then there is the classpath file. That one is used for all the information for the Java VM, you know, where to find the other classes, where to find the frameworks. When you use Project Builder, this is all created for you automatically. You don't have to worry about anything. And those classpath files are automatically passed as arguments by the launch scripts.

But just in case you want to mess with it, that's where they are. They are in the content/ and individual directories, depending on platform. And here we see there is one for Mac OS, there is one for UNIX, and there is one for Windows, because your Solaris machine has most likely somewhat different Java VM or different libraries than your Mac OS X machine.

Then for Java Client, we've had many nice and powerful demos of the Java Client, direct-to-Java Client technologies. It's all really nice and good. When you don't know how to launch the application, it's a problem. Many people don't know there's actually a script to do that. It's in the main app wrapper in contents, and there is the app name.

And then there's some other stuff in the app wrapper, the .woa. There is all kinds of resources. Again, we have the application server resources, and we have the web server resources. So there's two directories to distinguish those. On an application server, when you have a split install where there's an app server and there's a web server, those directories will have very different contents. If it's one and the same machine, it's going to be one and the same.

Did you have enough of this? All right. The last part of today's presentation will be the custom WAP palettes. And the good news is-- this is the only slide for that topic. It's the good news for me, because then I can retire. What are WAP palettes? This is one of those other new features in WebObjects Builder for WebObjects 5.

You can customize palettes in WAP. It's very easy now. It's just drag and drop like it should be. And you can use it to store components, reusable components. So for instance, if you are a developer, a freelance person, and you want to reuse your components for many different clients, you just create a palette and drags-- drop stuff from it.

If you're a company who wants to share one of the same look and feel of components across many different products, you do the same. You create a new palette, and then you can use the same components over and over in all of your apps to assure the same look and feel.

So for the last time, Tom, show us. So here we are at the last demo.

That's the whole wizardry behind it. That's why it's now called assistants. Yes, that's why. Okay, so we're going to create a new palette. And actually, a lot of this code has been reworked for this release. You can drag and drop. And it actually saves a little image of the HTML that you've dragged. And you can resize that to your heart's content.

At this point, I think that the feature request would be to make it proportional resizing. It kind of looks... Proportional... Let's see, the shift key? No. Yes, that's... But then again, you should know what you dragged there in the first place, so... Let's see. Okay, so now I wanted to show you a custom element that we've added that we're going to drag into our application.

So we'll put it somewhere under the moose. Get rid of the moose. It's shedding. You don't like the moose? Yeah, well... Do you want to put it on the palette? No. We'll do that later. We could put the moose on the palette, should we choose. Okay, so we're dragging in a custom search panel, and it's going to require its own framework, which has some of the GIF resources that it requires.

So we drag that in, and we... Wire it up to the display group after moving everything out of the way. Okay, so let's see. So it's Play Group. We want to search on movie title, so we bind that to the search field. And when we click search, we want it to requalify the data source. Action. This is the riskiest part of all the demos. Relaunch the application.

I forgot one step, but that's okay because I can fix it using the power of rapid turnaround. I was supposed to paste all of this stuff into here. There we go. So we've added a search panel and an Aqua look and feel to our component, all by just dragging in a-- I don't know if you can call it.

concludes the palette demo. Doesn't it? Tom, you did really well in all four demos, even though you wouldn't be up even at this time. No. Well, this kind of brings us to an end. I think the whole presentation is like five minutes too short, because I guess I forgot half of the stuff.

To summarize, in short, Project Builder is the core of WebObjects 5 development. Pretty much everything revolves around it. It's in constant communication with all of other WebObjects-specific tools. You have to use different build targets for different parts of your project, for different files. As I said, images are the most likely candidate to be one or the other, sometimes even both. Otherwise, it's more clear-cut.

Components are always app server. Static stuff is pretty much always web server. And different build styles to finally deploy your project. It's in the last part when you're really done with it, when you want to go to final testing, you have to invoke those build styles on the command line because currently there is no support for that from the IDE. And also you have to explicitly name both build styles "deployment" and "web server." We are aware that that probably could be optimized in the next release. At this point, I would like to invite you to the WebObjects lab that closes in a few hours.

And of course, do vote for WebObjects as the coolest web server, because it is. App server, excuse me. And the roadmap is kind of short, since there's not that much time left in this week. We have WebObjects security. Then we have optimizing WebObjects applications. That's a pretty interesting talk as well. And I think you will want to voice feedback in the feedback session. Who to contact? My boss, Tony. She's at [email protected]. So is Bob Frazier, who is our marketing person.