My name is Andreas Wendker. I'm one of the managers in the WebObjects engineering team, and I'm responsible for the rapid development technologies. Right now we have two technologies that fit into this category. It's Direct to Web and Direct to Java Client. So I hope that most of you just joined the last session that we gave about Direct to Web, and it's my pleasure now to talk about Direct to Java Client.

So Direct to Java Client is one of our newest technologies. We just shipped it a few months ago the first time in the release 4.5. And it has a very similar purpose as Direct to Web, but it's targeted at a different kind of applications. It's not used to create Internet applications or Web applications that run in a Web browser. It's used to create desktop applications that are useful in the intranet.

So what I'm going to show you is that Direct to Java Client is a very, very strong rapid development technology for desktop business applications. You will see that Direct to Java Client is nearly ideal for prototyping purposes. And Direct to Java Client is not just a cool wizard that makes a nice demo. It's actually very serious stuff that will be very helpful in your real-world applications.

So what I'd like to talk about is, I'd first like to give you a short technical introduction into Direct to Java Client, then give a demonstration about a typical development process, then talk about the very important topic of customization, give another demo about an application that uses various of our customization techniques, and then I'll give you a few good reasons why we think you should use Direct to Java Client and then have the summary and question and answers.

To develop a Java Client application in the traditional way, you will find you will probably pretty much write three logical pieces for your application. First of all, you have to create a database and you have to generate an EU model that describes this database. You probably also want to write some business logic for it. This is one unit.

Then as a second step, and I will not be able to show you that today, but the second piece of your application is the user interface. We provide you with a graphical user interface editor which is called Interface Builder, which you can use to generate windows and to drop text fields in it and labels and buttons and table views and all this stuff.

These interface files are the second part of your application. The second part of your application. You probably also have to write a little bit of logic around this user interface to, for example, react on double clicks and table views. Then a third part of your application is what I call application logic.

That is all the code that you need to connect the various user interface components of your application. If you press a button in one window, then another window opens. All this code that connects the various pieces in your application. That is what I call application logic. Now there is a problem with that. This problem is that these pieces depend on each other. You have to create a database.

If you change the database, if you change your model, then you will also have to go and change all your interface files. If you have a localized application with multiple interface files for the different languages, it even gets worse. Then you have to change multiple interface files just if you change your database.

The worst case is that you might even have to change your application logic because then you might even have to open different windows. It depends on how complex your change is. The maintenance cost that you have for these kinds of applications is pretty high. Another downside of this is that unless you do a lot of work, you will have to do a lot of work.

Unless you do relatively simple API testing of your business logic, testing is pretty complicated. You need all these three pieces. You have a long bootstrapping time. You first have to sit down and write code for all these three pieces to get something on the screen that you can test.

Obviously, that's pretty bad for prototyping because you will waste a lot of time. When we shipped the Java Client technology the first time in 4.0, which is one and a half years ago now, I think, we saw that it's actually pretty good. We saw that it's actually pretty complicated to create an application. There are lots of steps involved just to bootstrap this development process. We wanted to do something for you that makes it much easier to develop these applications.

What we came up with is Direct-to-Java Client. The idea behind Direct-to-Java Client is to generate the application logic and the user interface dynamically for you just based on the EU model like we do it in Direct-to-Web. The advantage is that you can sit down and develop, test, and polish your business logic without wasting any time on user interface development or writing your application logic. You can really fully concentrate on the business logic.

When the business logic is finalized, then you can go ahead and invest time into the user interface. The stages you go through if you use Direct-to-Java Client is that, like in the traditional development, you will have to create a database and a model and some business logic around it.

Then you take that and stuff it into this dynamic application engine. What you get is a default application, very similar to what is done in Direct to Web. This default application might already be good enough to show it to a customer. It can actually act as a first prototype already.

But you probably want to tune it a little bit and do some relatively simple customizations. For example, change our selection of properties that we use to query for data objects. Or you want to maybe just change the order of text fields in the user interface. Stuff like that. For that, we provide you with a tool which is called the Assistant, similar to Direct to Web. With this Assistant, you can do these relatively simple customizations. You will end up with a custom application.

Our recommendation is that you stay on this level as long as possible and first invest the time to implement your business logic. Then when you show it to your customer again and again, and he is finally content with the business logic happening in your application, then you can go ahead and polish it and make, for example, layout changes that are very specialized. I will show you a few examples of that.

How do we generate this user interface? The first thing you need to know for that is that we, on the client side, provide you with a bunch of objects that we call controllers. We have controllers for all kinds of tasks. One controller is the application object itself. The application object is the object that is responsible for bootstrapping your application. It's the object that has the main function that starts the application and that takes care of opening the first windows.

It's also the center point of contact. You're looking for other controllers and other windows in your application. Then we have purely user interface related controllers. For example, we have a window controller that knows how to react on changes in the window. The user presses the close button. We have tab view controllers, all this stuff.

Another type of controllers are controllers that we call entity level controllers. These entity level controllers work with your business objects on the level of the object itself. They define how you can query for objects, how you can edit them, or how you display them in a table, in a list. The fourth type of controller that we have is called property level controllers.

They also deal with your business object, but they do it just with one property at a time. For example, a text view controller that just displays one attribute, like the name of a customer, or action buttons, or things like that. Now, these controllers not only know how to react on changes, they know how to react on events that are triggered in the user interface, for example, a button click or so. They also know how to generate the user interface. The text view controller knows how to create a text view. The window controller knows how to create a window.

Then they also know how to lay out the views that are generated in a reasonable way. The most important information for them to do the layout is actually that the controllers are organized in a hierarchy. The easiest way for me to explain it is probably by taking a look at an example.

If you take a look at this window here, you see that there's a toolbar in there. It has a text field and a tab view, the two views in it. The root controller for a window like this would be a window controller. Then inside this window, we have a toolbar controller. The toolbar controller is a subcontroller of the window controller.

Then inside there, we have a text field and a tab view. As we can see in the tab view, we have two more views. One is for the roles, one is for the plot summary. In the role view, we have a table view with two columns. In the plot summary, we have--you can't see it, but it would be reasonable to assume that there's something like a text area that displays a larger text. The hierarchy of controllers pretty much also reflects the view hierarchy that we generate for the user interface.

We know what kind of objects we use on the client side to generate the user interface, but the question is still where do these objects come from? The answer is they come from the server. The reason for that is, most of all, I would say security and second of all, performance. The user interface is generated based on the EO model. To generate the user interface and the hierarchy of controllers, we have to take a look at the model. This is information that we for sure don't want to send to the client because it would be very unsecure.

In addition to that, most of the user interfaces are the same for all kinds of clients. If you generate the hierarchy of controllers on the server side, we can do it once and then reuse it for multiple clients. The format that we use to describe the hierarchy of controllers is XML. I gave you an example. It's actually pretty much the same example as this one here. We have a window controller, a toolbar controller. This is the hierarchy of controllers described in XML.

So, like in Direct to Web, on the server side, we use a rule system to generate this XML description of the user interface. For now it's good enough if you just keep in mind that the rule system is customizable, that you can plug in your own rules. So you can plug in your own rules, but actually we provide you with a huge set of default rules. And so these default rules analyze the EO model and then try to come up with a reasonable user interface for the data. And the first thing they need to do is they need to categorize the different entities that you have in your EO model.

And we pretty much have three, we distinguish between three kinds of entities. One we call the main entities, the other one we call enumeration entities, and for the third one we don't have a name, just everything else. So main entities represent the business objects that are kind of the primary objects in your database. Typical examples are a customer, an object that's an entity that represents a customer. That's a typical main entity.

But on the other side the address is attached to the customer. Or maybe the phone number is attached to the customer. That is kind of secondary information. This is what we call the other stuff. And then it also turns out that most databases have a lot of different types of information.

A huge number of entities that also match the definition of a main entity, but they are much simpler. They are usually just used for pick lists. Examples are the 52 states of America. Another example could be a category for a movie, whether it's a drama or whether it's a comedy. These kinds of pick lists are usually stored in very simple database tables.

The reason why we distinguish between them is that it actually makes sense to create two different kinds of user interfaces for these main enumeration entities. For main entities, we create a query window that allows to search for objects. From this query window, you can open other detail windows. If you need to select one, we have a modal dialog for you.

For enumeration entities, we can make that much simpler because usually there are only a few objects in the entity. There are only 52 states. So for N-Variation entities, we create a much simpler editor window and then we need to select a reference then. We just create a combo box or so to display them. We don't need a full window and a query interface for that.

I'd like to also give you an example about that and have something that looks similar to an entity-relationship diagram here. This is pretty much a subset of the standard movie rental example, a little bit modified to make the example a little clearer. We have a talent in there, we have a movie entity in there, the movie has a category, and then attached to the movie we have a plot summary and a voting. When the default rules start analyzing this database scheme, let's say they start with a talent photo, these default rules will find out that the talent photo actually depends on the talent.

There's no reason to have it, or there's no use for having a talent photo without the talent. The default rules analyze mostly the relationships between these entities. In this case, they become two major groups. One is the group around the talent entity. Talent is what the default rules identify as the main entity, and talent photo and movie role depend on it.

The second group is around the movie. The plot summary and the voting are attached to the movie, and the movie role actually belongs to both kinds of groups. When we edit the movie, we want to see the information about the movie roles, so what kind of roles are played in this movie. On the other side, if you take a look at the talent, you also want to see what kind of roles this talent plays.

The third group is this category which matches the definition of an enumeration entity. As you can see, it has a primary key and then there's just a name. It could be a drama or a comedy. The default would identify two main entities in this case and one enumeration entity.

So now we have pretty much all the pieces together to take a look at the complete Direct to Java Client architecture. It's still a three-tier architecture. We have a WebObjects application and we have a Java Client application. But both on the server and the client side, we have extensions. The extensions on the server side are the rule system and the extensions on the client side are all these EU controllers that I described before.

Now, there will be a difference when the application starts up because there is no user interface defined for the client side like in the traditional development where you create your interface files and interface builder. So the first thing that has to happen is that these extensions talk to each other and the client asks the server, "So what kind of user interface shall I display? What kind of windows shall I open when the application starts up?" So now the rule system will take a look at the EU model and will create this XML description of the windows that are supposed to be shared. So the client side will keep track of all these different windows, keep it in mind, and be able to use it. This XML description is pretty much a template for creating a hierarchy of controllers. So the client side will keep that in mind.

And then later when the user triggers searches on the database, you do another request to the server side which will probably result in fetches in the database. You get business objects, they're sent to the client, and then it's the usual stuff. So the difference between a normal or traditionally developed application and a Direct to Java Client application is that in addition to exchanging the data, you have to exchange information about the object. You also have to exchange information about the user interface. The server is responsible for generating the user interface on the client side. Okay, so I'd like to show you how that looks.

Okay, so what I have here is a Mac OS X server machine with WebObjects 4.5, and I'd like to show you how to create a Direct to Java Client application. And when you joined the Direct to Web session, you saw that we have a wizard in Project Builder, so you just create a new project.

And actually, we didn't have the time to finish that for Direct to Java Client, so the thing that we have is just a template that is placed inside our examples. So if you want to start developing a Direct to Java Client application, look inside our WebObjects Java Client examples, and there you will find a template that is called Direct to Java Client template. So for the purpose of the demo, I placed it on my desktop.

It's actually just a tiny little bit modified. I just modified our standard example, movies and renders, a tiny little bit. If you already know WebObjects, you'll probably recognize this here. It has about 20 entities. It's not super complex, but it's actually a decent amount of entities. Now, I'll just go ahead and compile this application.

takes a moment. That was it. Then, oops. Then I'm going to start the application. I configured my user defaults so that it actually uses a fixed URL, so it has a fixed port number, which you can see here. Now I'd like to switch to screen number three. So here I have a Mac OS X DP4 machine and like in the keynote we have this icon on the desktop here which is just the generic client pre-configured to connect to the URL that I hard-coded here on my server side. So I just double-click the client now.

And now what happens in the background is that the server takes a look at the EU model, analyzes it, makes assumptions about what kind of entities are the primary entities, and then will try to create this user interface that you probably already saw during the keynote. So, in this case, I decided that these six entities here, Customer, Movie, Studio, Talent, Unit, and Video, are the primary main entities of the application. And I can show you that, you know, for all these entities, it created a different kind of query user interface for them. So, for example, I can go ahead and search for movies and I guess, whatever.

Andreas Wenkker: And then there's the Star Wars movie. Now, the database that I'm using here actually does not have the information about the movies that we had in the keynote, so it's not going to have a trailer component, but I'll show you later how to plug in QuickTime. So this movie window now displays the detailed information about the movie.

So I have a few text fields that inform me about the movie itself, the title, the category. And then down here in the tab view, I pretty much take a look at all the relationships of this movie. So I have a plot summary, voting, the list of directors, the roles.

And if I want to take a look at the roles, or at the talent, I can just open it. So we don't have a photo for Harrison Ford. And he never directed any movie, but he played actually a bunch of roles. Let me show you another movie, which might be a little more interesting.

You've seen it before, huh? So this is our UF movie. And there are a few rules in there. One of my colleagues who will later come up for question and answers is my colleague Eric. And here we actually have a photo. Now that you've seen what kind of application you generate, you probably would like to know how to customize it. Like in Direct to Web, you have this Assistant tool. The Assistant is a pretty unconventional development tool because it's actually running inside your client application.

Andreas Wendker Here it displays me, for example, the choice of main entities and emulation entities that were made by the default rules. So I can change this order now and, for example, say that Studio should be more at the top and Talent as well. Andreas Wendker So let me just apply that and restart to clean up.

Andreas Wendker So now as you can see, the order here in the user interface changed. So we have Movie, Studio, Talent now. Andreas Wendker And then if I want to change the attributes that I used to search for movies,

Andreas Wenkker: And then Citi, and I never know that.

Credit card is really boring, but maybe the zip code and we can remember. So now just say apply, and let me show you. Andreas Wenkker: So, as you can see, I changed the attributes that are used to query for movies, and for studios, and for talent, and for the It's very simple to do these basic kinds of customizations, changing the order of widgets and the selection of properties that we made to search for them. Let's take a look at a movie window. The default widget that is used for character fields in the database is a normal text field. But actually for the summary, for plot summary, that can get pretty big. I would like to see another widget for that.

Andreas Wenkker: Let me explain to you in a moment what I'm doing here. This delay is now that this assistant actually derives a lot of information from the server side about the EU model. In the case of the assistant, it actually is okay that we send the information of the EU model to the client side because we're still in the developer models. This is not the deployment mode, so it's no problem sending this information to the client at this time.

Andreas Wenkker: I now selected the kind of widget I want to work on. As you can see, for the plot summary, we by default use a text field controller. I changed it now to be a text area. I can change the resizing. I want it to be resizable. I give it a minimum height. No, I don't want to show a label.

So let me apply that and then create a new window. This delay again is that now it kind of has to bootstrap this dynamic user interface generation again. I just changed the way the user interface is generated so it has reset all the caches, and that's why we see this delay. So now if you take a look at it, the movie changed, right? So now I have a completely different widget.

So these are just a few examples of, you know, kind of customizations that you can do. You can change the order of attributes. You can choose what kind of text fields or what kind of widgets in general are used. You can change format, pattern strings for numbers or so. There are a bunch of customizations that are supported in the Assistant.

Okay, so actually can we go back to the slides now please? Okay, so I'd like to talk a little more about customization and we have, In a real-world development scenario, there are different things you need to change. For different needs, we have different techniques to customize. They actually get more and more complex. The first technique to customize is the Assistant.

I already showed that to you. Then we allow you to write your own rules for the server-side rule system. We allow you to freeze XML. I'll explain in a moment what that means. We allow you to implement your own controller classes and to plug them into the client side. Then, the last step, we allow you to transition into the traditional development where you create your user interfaces by hand in this interface builder, user interface creation tool, and then just load them on the client side.

I want to talk about all of these a little more. The Assistant I already showed you. I guess most of you have seen the Direct to Web presentation, just the previous session. I'm going to make this pretty short. A rule is pretty much just a question and an answer. A typical question could be, "How many columns should be used to display ten text fields?" A typical answer could be two.

Another question is, "What kind of windows should be displayed when the application starts up?" The default answer for that is the query window. Other examples are, "What kind of widget, what kind of controller should I use to work on the character field?" The default answer is the text field. Actually, you can choose what kind of widgets you want to use. You can even plug in your own ones.

You can use rules to integrate your own controller classes. You can use rules to customize the layout, how many columns are supposed to be used over the layout in rows or that's in columns, things like that. Rules are very useful in multi-user environments because actually the rules allow you to create different user interfaces dependent on the user currently logged in. If you have two different users on two different clients, you can create two different user interfaces for them. It's also very useful for localization. You can choose different kinds of labels, for example, depending on the language of the user who is currently logged in.

So the next level of customization is pretty much to start writing a little bit of source code. So we allow you to write your own controller classes. You will usually use our classes as a base point and then subclass these classes. And for example, if you want to support new widgets that we don't support so far-- swing has a lot of widgets, and maybe you have your own ones that you want to support. So for all these kinds of support of new functionality, you will have to write some source code that's been used on the client side. So you will write client side controller classes.

And you can do a lot of stuff in controller classes. You can change completely how the application works, how controllers interact, what kind of reaction happens when you make a double click in a table viewer. So you could change all that in the controller classes. And so in general, it's good to add problem application specific functionality.

And then the last step of customization is-- and this is very important-- is to transition into the traditional development, where you start with the interface builder, create your files by hand, and then you have the maximum control over the layout. You can place your text fields on a pixel basis. You can have multiple interface files for different languages, all this stuff. And then it's actually fairly easy to plug in these traditionally developed components of your application into the dynamically generated part of the application.

So you do that, again, by writing a rule. You pretty much just tell the server side, instead of doing this dynamic creation of XML, sending that to the client, just use this interface file. And the class is coming with this interface file. So it's important to keep in mind that it's really easy to combine the two worlds of dynamic generation and traditional development.

Okay, so I'd like to give another demo and show you an application that makes use of a few of these customizations. I'd need screen number two again. Perfect. So this is an application that I already worked on. Let me just start that. Again, since my user defaults are configured correctly, it's using the same URL now. And number five now, please. Screen number five.

So this is Mac OS 9. Now I want to show you how the application looks on Mac OS 9. I have, like on Mac OS X, I have an icon on my desktop, which is the generic client. And this, in this case, it again connects to the same URL as before, but it actually uses a few client-side classes that are old for this application. So it's, this is not the complete generic client, it has a few classes added to it. So the first thing you will notice is that the application startup sequence changed completely, right? I don't get a query window, I get a login window.

So I'm forced to enter a name

The next thing you might notice is that here in this user interface, I actually have my layout customized. If you look at this lower section here with the addresses, you see that it's not just the standard one or two row column layout. It's beautified a little bit here in the middle with the street and it mixes rows and columns a little bit.

Another thing you might notice is that there's a new button in the Find window which allows you to create reports. So if I click on that I get this modal dialog where I can choose types of reports and then if I press OK I will actually get an HTML report and display it here on my client side. I can do that with another format as well.

So I can create different kinds of reports. Another thing you might notice is that in the menu here we have additional menu items to export and import the database. I'm not going to show you that because it would take too long. But you can also create reports based on the category.

So for example all the nice companies and persons actually are this. And then as the last thing that I want to show you there's a little info panel and this is what you've been waiting for, right? Audience member: Hi! Thank you. So, ah! There are things... Well, you've seen that before.

So there are a bunch of things happened here. I changed the startup sequence. I now have a login panel, and actually something that you didn't see right now because I just logged in once. But the application actually stores the user preferences, the window sizes that are just generated in the database now.

I then added additional actions in the query window. I have this report button, and then this complete new functionality to generate HTML, which is actually done on the server side and then sent to the client and just displayed there. I added additional menu items and complete new windows like the info panel. If you can go back to screen number two, please. I know that was not in the script.

So let me just show you a few things. So this is a The xml for the login window. In this case, I used frozen xml. It just has a modal dialog controller, an action button for the cancel and the ok button. Then here you can see that I used my own controller classes.

I have my own special controller classes that I use on the client side to do my login. Another thing that might be interesting to point out is that there's a subproject for reports. And in here, I have all these reports stored, so I can actually open one of them in WebObjects builder.

So I can use WebObjects Builder to evaluate the HTML, right? This is how I did the reports. And then there are a bunch of these components, of these four components that contain the layout of the reports. Well, I think that should be it for now. So yeah. Now I'd like the slides back, please.

So before I go into summary, I'd like to give you a few good reasons why we think you should use Direct-to-Java Client. And I think the most obvious reason is that your development gets much faster. I mean, we can save you a lot of time if you use Direct-to-Java Client. And that also means that it's much cheaper for you to do the development of your application. Another good reason for you might be that the learning curve to enter WebObjects development is flattened.

If you're new to WebObjects and you would have to do the traditional development process, you would have to know about all these pieces. You would have to know how to create interface files. You have to know how to create a model file. And you have to know how to write business logic, all this stuff. But with the Direct-to-Java Client, you already get an application without knowing a lot about it. You just need a database and your model, and that's it for now.

And then once you have your application, you can dig into all the pieces that need heavy customization. But it's a different way of learning WebObjects. So if you're new to WebObjects, this is a very interesting technology for you. Because your mileage will be much bigger in the beginning. Also, since the user interface is highly dynamic, at least unless you freeze it, your reaction time to requirement and database changes will go down a lot.

So if you modify your tables, if you add additional attributes in the tables, if you add additional relationships, the application will pick it up pretty much automatically for you. So your reaction time is much faster. I also claim that the testing time should be a little reduced. Because our controller classes are-- we invest a lot of time in testing our controller classes and our application logic. So you don't have to test that much. And I guess just in general, the message is that Direct-to-Java Client allows you to focus on your business logic.

You don't waste time in doing the same steps again and again. Drag a text field out of a palette into a window. Customize your layout so that it looks nice, all this stuff. This is done for you. So you can really focus on your business logic. And this is what you're paid for. Right? So you don't waste time. Right? time with anything else.

Before I go into the summary, I'd like to comment on a statement that I heard from a couple of people. The statement is, "Direct to Java Client," and the same is true for Direct to Web, "is just this super-duper wizard. It makes a hell of a demo, but in my real world scenario, I can't really use that." I wrote down a few comments on that, and most of them I already mentioned, so I'm not going to read them to you again.

My take on this is that people who make this statement have a fundamental misunderstanding about Direct to Web and Direct to Java Client. This fundamental misunderstanding is that Direct to Web and Direct to Java Client live in their own world, and that you cannot get out of that world. That is not true.

It's really easy, both for Direct to Web and Direct to Java Client, to transition into this traditional development where you use WebObjects to create your own components and Interface Builder to create your own components. The two worlds can be mixed very easily. If you look at it like that, then the Direct to Web and Direct to Java Client technologies help you a lot bootstrapping your development process. It's really getting much quicker for you, but if the dynamic generation is not good enough, then you just do it in the old way. There's no problem in mixing that.

You can use both Direct to Web and Direct to Java Client for all kinds of applications. Database administration might be very obvious. I gave you two examples here: a movies database and address management. If you want to do some auto-processing or billing or everything that runs in the back office area, Direct to Java Client can help you with that.

So, we still have some time. In summary, I showed you that Direct to Java Client enables very strong rapid development and is very useful for prototyping. You generate a lot of parts of the application dynamically and we have a lot of predefined functionality in the form of these controller classes. You have powerful ways of customization for different needs and the last step of customization is to transition to the usual development.

Two more sessions that might be interesting for you. UF synchronization, caching, and advanced UF. You will probably not hear anything about Direct to Web and Direct to Java Client in these sessions, but they are about writing business logic, so how to do validation and how to write business logic in a good, efficient way. These two might be interesting for you.

For more information, I guess it's the usual stuff, you can go to our website. We have a lab downstairs. You all got an evaluation CD, so just try it out. So now I'd like a few of my colleagues to come up and be available for question and answers.