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 German, 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 assistance. 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 assistance 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 the 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 CBS 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 WebObjects 5, for those of you who have been using WebObjects 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. OK, so as Stan mentioned, you've probably all seen the Estesans 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 WOL component with a pre-configured display group, which is 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.

Let's see, 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, let's see, the list of EOs and what I just explained. Thank you.

Anyway, okay, so we need some attributes. And I'm just gonna 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. OK, so basically you've seen this type of project a number of times before. It's created this component with a preconfigured display group.

you've seen before. Let's see, but 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. Don't run away. So back to the slides if we can go. Yes. Tom pointed out initially in the assistance the Cocoa EOF application. All 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 even 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 ObjectsBuilder-- 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 We 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. That old project builder required you to place things into buckets. You had a cute little bucket for your Java files, another one for your resources, another one for the web components. Now you can put stuff wherever you want. It's really nice because it allows you to structure things just as Tom showed in the previous demo. A component, it had the class and the woe file and everything else together in a little group. You can also put stuff anywhere on the file system. The problem with that is when you move your file, you can put it in a completely unrelated directory and it will find it, it will build it just fine.

The problem with that is if you copy your project, you have to keep track yourself manually that that file is somewhere completely else. So it has pros and cons. Our assistance when you create something, when you create a new project, when you add files to an existing project, it will place it immediately in an appropriate bucket, in a components bucket and whatnot. Well, not bucket. Group. Ah, those buckets. Mystery files. Some of you may be wondered, 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, et cetera. 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 API 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 Web Objects 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, et cetera. 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.

OK, 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 Builder's 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-- Assistance. The assistants-- Very important. --have preferred groups that they like to put things in. So that to make it easy when you create a new component, "Gee, where did you put it in my project?" You know, I 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, you know, just completely rearrange that. You can put them all in one group or, you know, each file in another group if you want. Resources, let's see. Whoops. That's 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. And one interesting bucket is the built product bucket, And 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. I don't see any people yet. That's at the very end, you know, just before they walk out. Don't show it yet.

Yeah, let's just start showing that. You know, this is where it appears in the project, but we're not going to discuss the project structure until later, as was mentioned by Stan. Let's see, so 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, and 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. So 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 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, you 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.

application server, there is no need to put a Neo model to both targets because web server 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 web server resource. And, again, as Tom said, you saw that really, really crufty 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 WebObjectsBuilder running, tweak some components, press refresh and expect something to happen. That's not going to happen. That's because WebObjectsFramework and the WebObjectsBuilder 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 on 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 turnout will not work. And back to our chief demo person. 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. And 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. And 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 OK, we've run the application. And we've got this component.

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-- 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.

drag in a moose to beautify our application. Let's see if I can have Project Builder showing in 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. So 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, moose are shy by nature. We save the component. Switch back to Internet Explorer. Hit refresh.

The moose instantly appears. So... Thank you. So basically, for things like adding resources, as long as you don't change code, in theory, you shouldn't have to rebuild your application. And that's the rule you should go by when things don't seem to be working as you expect. You probably just need to relaunch. Chances are you don't have to rebuild unless you've added code. Now, Tom, you just added an image. Which target did it get added to? I see the moose in the outline view there. but you might want to touch on the target. So it should have added it to the web server resources, and you can see by the donut that it has, and that's something--Wab just chose to add it to the web server, and it goes by the name of the target. So it asked Project Builder, you know, "Give me the web server target," and if you don't have one named "web server," then it'll just add it to the project but won't add it to a target. So if you did change the target names, the tools wouldn't work as well, but it would still add things to the project. Right. So at this point you could also now choose manually to, if we stay with this, to add it also to the app server target. Sure, I could just switch over to... If you switch there, you see the donut isn't there, just click on it. If this were, say, your iCards page and you wanted to do both static display and also dynamic, it doesn't hurt, even if you don't need it that way, but, you know, if you're not sure where to go, just put it to both. It's going to waste a little bit of disk space, But you know, 100 gig drives today, what is it? Just peanuts. So this can be done. The price of convenience. That is usually like that. It's like electricity in California these days. Right. Anyway, so thanks, Tom. Yep.

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 CBS? 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 says Source Modification. It's something Source Control. It shows you... At this time of day, I don't know even my name. It shows you where you added and deleted files. That's one of the tricky things.

You know, you're on command line, You add a file there, you add it to the make file or what have you, and you build the project. It's just great. You do a CBS 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.wo or.eomodel. They show up like a little file, but if you don't know about it, you add it. nothing got added because it's actually directory. So it works recursively.

and 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 Naomi, 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.

Save the component. Go back to Project Builder. 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. Yeah.

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 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. 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. Yeah, 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 CBS. Yes, it's important.

And all of the M's, R's, and A's 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 all right. 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 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 pbx build install dash build style and then one of the two build styles, either deployment or web server. And you have to do both. And then DSTROOT equals 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 equals 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. Thank you.

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 be done because you need to tell the Java VM things, et cetera. 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 app name dot cmd. And it also lives in the proper contents directory. Those two copies are identical, but they are used to be used on Windows.

Then there is the class path 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 class path 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's one for Unix, and there's 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. little script that actually launches the Java client and everything is once again done for you.

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 be-- will have very different contents. If it's one and the same machine, it's going to be one and the same.

Do 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? WAP palettes, excuse me. 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, freelance person, and you want to reuse your components for many different clients, you just create a palette and 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. So the palettes have basically two broad uses. One is kind of as a scrapbook for frequently used bits of HTML that you don't want to type over and over. Another is as an extension mechanism for the builder. So you can't really add. If you write your own framework with your own elements, you can't add to the toolbar. You can't add them to this menu. But you can make a palette that has your custom elements, and that makes it an easy way for you to extend the builder. For example, we had an engineer put together a smile framework, which is synchronized multimedia instruction language, I believe. And it comes with a set of components that you can drag into your component. So it's just sort of he made the framework and wants to make it easy for people to use. So you make the palette, and then they can see it right there and just drag the elements in.

So it's very convenient. What's going to happen when you just drag an element like that in there, even though you don't know what it is? These, it just looks like a generic container. Oh, what's that? Oh, yeah, and it's going to want to add the corresponding framework for Smile. And I don't want to do that with this demo right now. Yeah, I was just curious. I'm not sure what that does exactly. But you see the coolest smart... They just look like generic containers that you could drag other elements into. And apparently when you use this, you would hide them inside of an embed tag, and then the QuickTime plugin will find the XML and execute the instructions, and you could do a very whizzy demo, which we're not going to do. But it was nice that it suggested that we add the framework, and it would have done it all for us on its own. Anything, any frameworks at least, that the elements you drag and require, I will go ahead and automatically add for you.

That's the whole wizardry behind it. That's why it's now called assistance. 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... Yeah. Let's see the shift key. Now... Yes, that's... But then again, you should know what you dragged there in the first place, so... Yeah.

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 pallet? No, we'll do that later.

We could put the moose on the pallet, 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. OK, 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... 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 WebObject 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. Thank you. 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 webobjects.apple.com. So is Bob Fraser, who is our marketing person. Thank you.