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 Direct2Web and Direct2JavaClient. So I hope that most of you just joined the last session that we gave about Direct2Web. And it's my pleasure now to talk about Direct2JavaClient.

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

Okay, I first would like to talk about the typical application architecture of WebObjects applications. And usually, in a usual scenario, there are three tiers. One is the database. Then the second tier is the WebObjects application. It's safe. It's the application web server. And the third tier is the client, which usually is a web browser. So the applications are started when the user types in a URL, right, which sends an HTTP request to the WebOptics application. And then the task of the WebOptics application is to create the HTML page that is supposed to be displayed in the browser. And in order for the application server to generate this HTML page, they usually have to retrieve some data from the database. So we would send some SQL to the database, which results in a fetch.

And the database gives us the data back in a format that we call raw rows. So it's just the raw data. So it's just tables and columns. And then WebObjects will actually take this raw data and map it into business objects. So we use a file that we call the EO model. And we talked-- it was probably mentioned a couple of times already in the previous sessions about WebObjects. The EO model describes the mapping between this raw data and the business objects that you have. And the nice part about WebObjects is that you can determine what kind of classes are used to represent your data. And so what that means is that you can embed your business logic directly into the object that represents the data. So if you want to write validation code, you would do it inside these objects. And anyway, the WebObjects application would then create the HTML page based on the business objects that it fetched, and then create the HTML, send it to the browser, and it would be displayed. Now, that is the usual scenario in which WebObjects is used. And WebObjects is doing a great job kinds of applications. But there's a problem with it. And the problem is the browser. HTML-based applications are not very user-friendly applications.

And the more complex your data gets, the browser gets-- to represent this application in a browser, it gets more and more complicated. You will end up doing a lot of navigation. The data is highly structured. And you can only do one task at a time. So the browser is just not a very good tool to run complex business applications. So we have a second technology in WebObjects which is called Java Client. And in the Java Client scenario, you pretty much kick out the web browser and replace it, replace the client with a full Java application that is based on Swing, so the JFC widget classes. So that allows you to run applications with multiple windows, motor dialogs, menus, everything that you expect from a user-friendly application.

So the typical data flow is pretty similar. Java client applications also use HTTP as a transport layer for connecting to the server. So when the application starts up, we send an HTTP request to the application server, which probably results in a fetch from the database. Then on the server side, we met the raw data from the database again into business objects. And then something different happens. We don't generate HTML, but we actually sent these objects as a copy to the client side. So the missing piece of information here is that we actually replicated a lot of the functionality that we have on the server side to deal with business logic for the client side. So you can deal with business objects on the client side in the same way as you deal with them on the server side. And since the client side is purely written in Java, it's platform independent, so you can run it on Windows, you can run it on Mac OS 9, you can run it on Mac OS X.

Now, to develop a Java client application in the traditional way, you will find, you will probably pretty much write three kind of logical pieces for your application. First of all, you have to create a database, and you have to generate an EModel that describes this database. And you probably also want to write some business logic for it. So this is kind of one unit. Then as a second step, and I'm probably not going to, I will not be able to show you that today, but the second piece of your application is the user interface.

And 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. So these interface files are the second unit of your application, and the second part of your application. And then 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 or so. And then a third part of the application is what I call application logic, and that is all the code that you need to connect the various user interface components of your application. So, right, that if you press a button in one window, that another window opens, right? So all this code that connects the various pieces in your application, and that's what I call application logic. Now, there's a problem with that, and this problem is that these pieces depend on each other. 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, right? Then you have to change multiple interface files just if you change your database.

And 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. So the maintenance cost that you have for these kinds of applications is pretty high. Another downside of this is that unless you do relatively simple API testing of your business logic, testing is pretty complicated. You need all these three pieces. So 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. And obviously, that's pretty bad for prototyping, because you will waste a lot of time. So 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 complicated to create an application. I mean, there are lots of steps involved just to bootstrap this development process. And we wanted to do something for you that makes it much easier to develop these applications. And so what we came up with is Direct-to-Java Client. And 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. So 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 application logic. You can really fully concentrate on the business logic, and then when the business logic is kind of finalized, then you can go ahead and invest time into the user interface. So the kind of stages you go through if you use direct-to-Java client is that, like in the traditional development, you would have to create a database and a model and some business logic around it.

And then you take that and stuff it into this dynamic application engine. And what you get is a default application, very similar than what is done in Directive App. So this default application might actually 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.

And for that, we provide you with a tool which is called the Assistant, similar to Direct to Web. And with this Assistant, you can do these relatively simple customizations. And so you end up with a custom application. And our recommendation is that you kind of stay on this level as long as possible, and first invest the time to implement your business logic. And then when you show it to your customer again and again, and he's 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. So how do we generate this user interface? And 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. And 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. And it's also kind of the center point of contact if 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 when the user presses the close button. So we have tab view controllers, all this stuff. Another level of type of controllers are controllers that we call entity level controllers. So these entity level controllers work with your business objects on the level of the object itself. define how you can query for objects, how you can edit them, or how you display them in the table, in the list. Then 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 events that are triggered in the user interface, so for example, a button click or so, they also know how to generate the user interface. The text field controller knows how to create a text field. The window controller knows how to create a window. And then they also know how to lay out the views that are generated in a reasonable way. And the most important information for them to do the layout is actually that the controllers are organized in a hierarchy. So the easiest way for me to explain it is probably by taking a look at an example.

So 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. And so the root controller for a window like this would be a window controller. And then inside this window, we have a toolbar controller. So the toolbar controller is a subcontroller of the window controller. And then inside there, we have a text field and a tab view. And as we can see in the tab view, we have two more views.

One is for the roles. One is for the plot summary. So in the role view, we have a table view with two columns. And in the plot summary, we have-- well, 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. So the hierarchy of controllers pretty much also reflects the view hierarchy that we generate for the user interface.

Now, so 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? And the answer is they come from the server. The reason for that is most of all, well, I would say security and second of all, performance. So the server, or as I said before, the user interface is generated based on the EO model, right? And so to generate the user interface and this 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. You will probably see that. We have a window controller, a toolbar controller. So this is the hierarchy of controllers described in XML.

So, like in Directive 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 the primary objects in your database.

Typical examples are a customer, 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's attached to it. That is kind of secondary information. This is what we call the other stuff. And then it also turns out that most databases have actually 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. Or 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. And the reason why we distinguish between them is that it allows us, or it actually makes sense to create two different kinds of user interfaces for these main enumeration entities. And so for main entities, we create a query window that allows to search for objects. And then from this query window, you can open other detail windows, right? And if you need to select one, we have a modal dialog for you. And for enumeration entities, we can make that much simpler because usually there are only a few objects in the entity, right? There are only 52 states. So for enumeration 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.

So I'd like to also give you an example about that and have something that looks similar to an entity relationship diagram here. And so this is pretty much a subset of the standard movie rental example, a little bit modified to make the example a little clearer. So we have a-- pretty much 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. And so then the default would start analyzing this database scheme, let's say they start 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. Then in this case, they become the two major groups. One is the group around the talent entity. Talent is what the default identify as the main entity, and talent photo and movie role depend on it. The second group is around the movie.

So the plot summary and the voting are attached to the movie. And the movie role actually belongs to both kinds of groups. So 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, we also want to see what kind of roles this talent play.

And then the third group is actually 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. So it could be a drama or a comedy. So 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, you create your interface files in 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 root system will take a look at the EO model, and they create this XML description of the windows that are supposed to be shown on the client side. 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. And so the clients have to 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 objects and information about the object, you also have to exchange information about the user interface. the service responsible for generating the user interface on the client side. OK, so I'd like to show you how that looks.

Okay, so what I have here is a Mac OS X server machine with WebOptics 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.

And actually, I just copied that into my file system now in another place, and then opened the pbproject. And according to the theory that I explained before, the only thing I need to do is I need to add a database model, an EO model to it. And so I do that now, and I have a model prepared. So I'll show you this model.

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

Takes a moment. That was it. Then-- oops. And then I'm going to start the application. And 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, which is a very similar one.

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

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 it saved, 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 rules. And if I want to take a look at the rules, 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. Whew. OK. So-- Now that you've seen what kind of application you generate, you probably would like to know how to customize it. And 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. And it allows me to-- here it displays me, for example, the choice of main entities and integration 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. And so let me just apply that and restart to clean up. So now as you can see, the order here in the user interface changed, right? So we have movies, studio, talent now. And then if I want to change the attributes that I used to search for movies-- Actually, let me just show you that. The assistant tries to follow the user.

It will actually try to find out what kind of window the user is currently working in, what kind of component. If I want to customize the movie query windows, I can just remove a few. Then studio is actually nice information and the release date. If this goes to the studio, the budget, I never know that anyway, so I don't need that as a query property. Yeah, the last name should be first. Now if you wonder that some of these attributes don't show up in the query user interface like the photo one, then that is just because data type is not very good to query with. You cannot really describe a photo, an image data in a text field. And for customer, that might make a little more sense here. So let me reorder that. And then city, I never know that. Credit card is really boring, but maybe the zip code and we can remember. So now I'll just say apply. And let me show you.

how the new query window looks. Actually, we can hold them side by side now. So as you can see, I changed the attributes that are used to query for movies, and for studios, for talent. Right? And for customer. So 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. I want to show you a little bit more.

Let's take a look at the movie window. And 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. So I would like to see another widget for that. 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 EO model. So in the case of the assistant, it actually is okay that we send the information of the EO model to the client side, right, because we're still in the developer models, right? This is not the deployment mode. So it's no problem sending this information to the client at this time. And so I now selected the kind of widget I want to work on. And 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. And 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. So now I have a completely different widget. So these are just a few examples of 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. OK. So actually, can we go back to the slides now, please?

okay so i'd like to talk a little more about customization and um... do you have In a real-world development scenario, there are different things you need to change. And for different needs, we have different techniques to customize. And they actually get more and more complex. So the first technique to customize is the assistant. I already showed that to you. And 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 in into the client side. And then kind of 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.

So I want to talk about all of these a little more. The assistant I already showed you. So I guess most of you have seen the direct-to-web presentation just as the previous session, and so I'm going to make this pretty short. But a rule is pretty much just a question and an answer. So a typical question could be, how many columns should be used to display 10 text fields? And 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. But actually, you can choose what kind of widgets you want to use, and you can even plug in your own ones. So 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 over the columns, things like that. And 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. So if you have two different users on two different clients, you can create two different user interfaces for them. And it's also very useful for localization. You can choose different kinds of labels, for example, depending on the language of the user who's currently logged in.

But rules, you know, rules pretty much change one aspect of the dynamic generation at a time. And to achieve more complex changes, you might have to write a bunch of rules to get there. And so that might get, you know, pretty complicated. And so to make your life easier, we even allow you to completely bypass the rule system and to take the XML, which is the result that the rule system is supposed to use, right, and freeze this XML into a static file that you can then edit by hand. So if it's complicated for you to change the layout by writing rules, you can just take the XML that is generated by the default rules and freeze it into a file and then just tell the server side to use this file instead of doing the dynamic rule evaluation.

So again, this is useful to customize your layout, to integrate your own custom controller classes, and it's also useful if you need to specify parameters that are not supported by the assistant. The Assistant just displays the most common attributes of controllers that people want to customize. But there are actually some that are not supported by the Assistant. So if you want to add and change these parameters, you might have to freeze the XML and end it by hand.

So in general, I think rules and freezing XML is pretty much on the same level. Just freezing XML, or you will freeze the XML when it gets pretty complicated, when you have to change a lot of rules. Then freezing XML might become actually much simpler. And the other advantage of freezing XML is that you can actually see the entries are directly. Rules are pretty abstract, so it's kind of hard to understand. But if you see the XML in front of you, you can validate very, very what's really going on.

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.

You were right, clients like 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 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.

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. Like on Mac OS X, I have an icon on my desktop, which is the generic client. And 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 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. I don't get a query window. I get a login window. So I'm forced to enter a name and a password.

And then afterwards, if we go over into the traditional one, which is the query window. So this is a fairly easy database. It just has persons and some addresses around it. So the application looks pretty similar. Let me search for some data here. Let me open one of these windows.

The next thing you might notice is that here, in this user interface, I actually have my layout a little 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 or column layout. It actually has-- 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? 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, it's 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.

I was back already. So let me just show you a few things. So this is-- the XML for the login window. So in this case, I used a frozen XML. So it just has a modal dialog controller and action buttons which are for the cancel and the OK button. And then here you can see that I use my own controller classes. So 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 the objects builder.

So I can use Web Objects Builder to evaluate the HTML. 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, right? But with the DictoJava client, you already get an application, right, without knowing a lot about it. You just need a database and your model, and that's it for now. And then, you know, once you have your application, you can dig into all the pieces that need heavy customization.

But it's a different way of learning web objects. So if you're new to web objects, 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 that 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, So you don't waste time with anything else.

And then before I go into the summary, I'd like to comment on a statement that I heard from a couple of people. And the statement is, direct to Java client, and the same is true for direct to web, it's just this super duper wizard. And it makes a hell of a demo, but in my real world scenario, I can't really use that. And so 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. I think my take on this is that people who make this statement have a fundamental misunderstanding about Direct-to-Web and Direct-to-Java Client. And this fundamental misunderstanding is that Direct-to-Web and Direct-to-Java Client live in their own world, right? And that you cannot get out of that world. And 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 Web Objects Builder to create your components and Interface Builder to create your interface files. So the two worlds can be mixed very easily. And then if you look at it like that, then the direct-to-web, 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.

And you can use both Directive Web and Directive 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. But if you want to do some auto processing or billing or everything that runs in the back office area, Directive Java Client can help you with that.

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

Okay, two more sessions that might be interesting for you. UF synchronization and caching and advanced UF. So you will probably not hear anything about DirectWeb and DirectToJava client in these sessions, but they're about writing business logic, right? So how to do validation and how to write business logic in a good, efficient way. So these two might be interesting for you. For more information, I guess it's a usual stuff, you can go to our website. We have a lab downstairs. You all got an evaluation CD, so just try it out. And so now I'd like a few of my colleagues to come up and be available for question and answers.