So hi and welcome to session 606, Direct to Java Client. My name is Andreas Wendker. I'm still the manager of the WebObjects rapid development team. And before I dive into Direct to Java Client, I'd like to quickly summarize what Java Client is. So who is seeing session number 609 this morning? Okay, thank you. So, most of the content of the session will be based on the session 609, but if you missed it, I don't think there was too much information that you will get lost this time.

So Java Client is a technology for creating three-tier desktop applications. The client process displays the user interface and interacts with the user. The server is a WebObjects application server and it accesses the database and the database, the third tier, stores the data. The important pieces of information are that the client never accesses the database directly.

It always goes through the server. So the server has full control over the access that the client has to the database. And the other interesting information is that Java Client uses HTTP as the standard communication protocol between client and server. So you get the connectivity of an HTML-based application, but you get a much richer user interface.

Java Client uses the Java Foundation classes, or Swing, as the widget layer. So it's basically platform independent. It just requires JDK 1.3. Java Client is localizable. I actually forgot to talk about this this morning. But if you do localization, you do it the same way as with Cocoa.

So you have multiple versions of your files, like multiple interface files, and you just give them special extensions like mine is German or mine is English, and then it loads the localized versions at runtime. And Java Client is really designed for the intranet. It's not the technology you should use on high-traffic internet sites because it takes a long time to start applets when they have to download classes. Or at least you have to install a client start program, and then having an installation process always means that you can't use it in the internet.

So Direct to Java Client makes developing Java Client applications really easy. It's actually so easy that we, web object engineers, often compare it to instant coffee, for which you just have to add some water, as you know. Now, in our world, we don't create instant coffee. We create instant applications. And instead of water, you just have to add a EU model.

But I promise you, you can create Java Client applications much faster than you can drink your coffee. So Direct to Java Client is an infrastructure that is designed to help you to develop Java Client applications. It does so by providing you a lot of predefined application functionality you can make use of.

And it also does so by relieving you from the burden to create user interfaces by hand in Interface Build. Instead, it generates user interfaces dynamically based on information it finds in your EU models. That saves you a lot of time and also money, and we think it's ideal for prototyping purposes.

But we know that the default application that you can generate by just analyzing the EU model will probably not be the application you want to deploy to your users. In fact, we think we know that we will hardly ever need the application in a way that you can just ship it to your user.

So that's why we designed Direct to Java Client to be very extensible. It's very easy for you to plug in your own customizations. And we offer you a lot of techniques you can use to customize the default application. And in this session I want to show you those techniques. So we have a lot of topics I want to cover. First of all I want to show you how to create Direct to Java Client applications. I want to walk you through the default applications so that you know what the predefined functionality is that we provide.

I want to introduce you to the architecture that is used for Direct to Java Client applications. I want to talk about controllers and the rule system. You will find out what that is. And I want to focus a lot on customizations. So how can you customize the default application.

And in the end I want to give you a few good reasons why you should really use Direct to Java Client. I really want to burn that in your brain. So first of all I'd like to ask Ron Luu-Saang to come up on stage. and give you a demo of how to create a direct to Java Client application. So we could switch to the demo machine.

Thank you. I get so many demos here, I have to use a script now. So this time we want to use a little more complex new models. This morning we used a relatively simple education model. It just grouped around a person. This time we use our movies and rentals models that come with WebObjects 5. So there are two models that work together.

It has a movies database and there's some kind of a rental store information based on top of that. So those are the two models. And Ron's just going to Project Builder, creates a new project. Choose the right project type. It's a Direct to Java Client application. Give it a name.

And this time, we had two frameworks, the one that we used this morning, Java Client Class Loader, which makes our demos very easy, and the Java Client Business Logic framework, which contains our two models, the movies and the rentals model. You will actually find that in all the exams with Objects 5. So those are the two models. The assistant displays the ones that it found in the frameworks. And that's it. Just save, build, and launch the project now.

The interesting piece about this project is that there are no client-side components. There's no interface file defined. There are no classes for the client-side because everything is generated dynamically on the fly. So in the meantime, the project was compiled and starting right now. And this is our Java Client launcher that connects to the server.

So this is the UI that you get just without doing any programming. This is the default application. So we see a subset of the entities displayed here. Those are the most important entities of the model-- studio, talent, movies. And for every entity, we have a query interface where we can enter qualifiers. So just searching for some studios right now.

And then he's switching back to movies, and we can search there as well. Now he's searching for all movies with the title M. We can also append queries. So we just appended to the previous search result all the movies that start with an S. And now we're going to take some details of this movie.

So we see the information about the movie itself at the top of the window. There's the studio. And then in the tab view, we have a display of all the various relationships. And if you want, you can get more information about the talents there just by pressing the Open button. So just leave it like that.

And maybe you can close that window again. And then as last step, let's select the studio. So if you want to assign a new studio to this movie, press on the Select button. We get a mode of dialogue where we can search for studios. And then just select any. It's that easy. So thank you, Ron. If you could switch back to the slides.

So as you can see, it's fairly easy to create relatively complex applications. It just took a few seconds to run through the assistant, and it already generated us a fairly user-friendly application that you can use to edit and display all the data in your database. Let's take a look at the architecture of the application. This is the diagram from this morning. So this is a normal Java Client architecture.

If you've missed the session this morning, don't worry. The only thing that is important to take away from here is that in Direct to Java Client, we add components to both the client and the server side. On the client side, we add this layer called EU generation. And EU generation is responsible to initialize the dynamic user interface generation and just make sure that the application still does something sensible even if you don't give it any user interface.

And on the server side, the layer has a component that analyzes the EU model and that basically tells the client how the UI should look. And this server side component of EU generation is based on the same technology that we use for Direct to Web. I will talk a little bit about the rule system in this session. If you want to get more information about it, please come to session number 612. That's tomorrow, Direct to Web. And my colleague, Miguel, will talk about the rule system much more then.

So let's take a look at the client. In Direct to Java Client, on the client side, everything is done with controllers. You can consider controllers to be the glue between the user interface and the structure of EUF objects that is necessary to display and edit your data. That sounds a little bit like the EU associations that we got to know this morning, but controllers are actually much more. They don't only register for some events and send some strings back and forth.

They actually know how to create and lay out a user interface that is appropriate to edit your data. And they also know how to create the EUF objects that are necessary, so editing contexts, display groups, associations. Controllers know how to create all that. And on top of that, they usually implement a fairly complex piece of application logic.

So as I said, basically the whole application in Direct to Java Client is implemented in terms of controllers. And you can probably imagine that for a complete application, you need various types of controllers to take care of different tasks. So that all the controllers can still work together nicely, Direct to Java Client defines one class called EUController, and everything else is a subclass of this one class. So, the application is usually distinguished into four categories.

Every application needs some kind of an instance that takes care of starting the application and manages global parameters in the application, like user defaults, document management, stuff like that. That's usually called an application object, and so Direct to Java Client has an EUApplication object, which happens to be a controller.

They are also just purely UI-related tasks, just switching some views in the tab view, just managing windows, stuff like that. And those kind of controllers we call just user interface controllers. And then the most complex controllers are what we call the entity-level controllers. Those are the ones that really define the flow of your application. They handle business logic on the level of the business objects.

So they know how to query for objects, they know how to display lists, they know how to create forms to edit the objects. And the fourth level are the property-level controllers, which take care of your business logic on the level of a single property. So they create text fields, combo boxes, simple pick lists, and those are the property-level controllers.

Now controllers are organized in a hierarchy. And that is important because when the user interface is generated, it basically reflects the hierarchy or the views that are generated for the user interface reflect the hierarchy of the controllers. So when a controller creates a view for the user interface, that view is placed inside the view of its supercontroller.

The best way to understand that, I think, is to just look at it as an example. So at the right side of the slide, we have a fairly simple window that has a toolbar at the top, a single text field, and then a tab view with a table, and a plot summary, which is probably something like a text area.

So the controller hierarchy necessary to generate this window would look like the one that I have on the slide. So there would be a window controller at the top. There would be a toolbar controller displaying all the actions that can be performed inside this window. You find a text field controller and a tab view controller. And since we have two tabs in the tab view, there are probably two subcontrollers, a table view controller and a text area controller. And since we have two columns, we also have two column controllers.

Actually, let me go back. So what we know so far is that the client is implemented in the form of controllers. But where do these controllers come from? How do we tell the client what kind of controllers to generate? Let's first take a look at how we tell the client. Well, Direct to Java Client uses an XML format.

And controllers, the hierarchies of controllers, are just described in XML. And we define the typical text for every controller type that we have. We have a tag. So for the controller hierarchy of the slide before, you can see there's a window controller, there's a toolbar controller, text for controllers. And then they specify some labels and have additional attributes. So this is the way we tell the client. But where do we generate this XML? But I already told you that the most important resource for information to generate the user interface is your EU model.

But the EU model is not something you want to send to your client. First of all, it opens all kinds of security holes if you do that. And second of all, it's just a lot of data that you need to send. So a much better place for that is the server side. And this is where this rule system comes into the game.

The rule system is the mechanism that generates the information how the client should look like and behave. And I will talk about a few details on the following slides, but there are a few things I would like you to know and keep in mind before I even go into the details. First of all, most rules are defined in a fairly abstract way. If you write rules, they are usually independent of the concrete EU model that you have.

They are not related to an entity with a given name. They are usually related, or they are very often related, to just entities with certain criteria. So what that means is that rules are fairly abstract and can be applied to multiple applications, to multiple models. So the rule system is a very convenient place for you to define your own look and feel.

So by changing the rule system and defining a set of rules that you can apply to your whole application suite, you can define your own corporate look and feel. all your client applications that you create. Also very important is that the rule system is a very convenient place for localization. I'll talk about that a little more, but keep this in mind. And again, it's based on the same technology that Direct to Web is using.

You can consider the rule system to basically be a question-answer mechanism. Questions you can ask the rule system are, what kind of windows are available in my client application? Other questions are, what kind of background color should I use for my text fields? Or should I actually use a text field for this kind of property, or should I use an image view? Those are the questions you can ask.

Basically, everything that is defined or everything that appears on the client side is the answer, is the response to the question that you sent to the rule system. And the answers to these questions are given in the form of what we call rules. Direct to Java Client defines a set of default rules that come with the framework, the Direct to Java Client frameworks. And it's very easy for you to define your own custom rules.

Now in Direct to Java Client, the client only asks fairly high-level questions. If you could go and ask the server all the detailed questions-- what kind of color should I use, what kind of widget-- but that would be a lot of communication. We don't want to do that.

So the client only asks the-- basically, when it starts up, requests a certain set of status information, what kind of windows are available. And then from there on, it will only ask for detailed descriptions of complete windows so that we avoid too many round trips between client and server.

The client will also not ask for all the controller hierarchies at startup time. That would take a long, long time. So it only asks for the detailed window descriptions when the window actually appears on the screen, so when the user activates the window. So the client asks high-level questions and only one window at a time. And when it does ask for a window, it provides a certain amount of input to the rule system.

The first one is the question. So what kind of window are we actually interested in? Is it a normal window? Is it a modal dialog? Is it actually just a primitive controller, which are just a little piece of the UI that's independent of a window? Those are the questions.

Also, what kind of task is the user performing right now? What kind of window do we have to create? Is it a query window? Is it a list window? Is it a form? The window is related to one complete entity. It will also pass that entity to the rule system.

And then there are two more things it passes. It passes some platform information and some language information. The default rule system does not make use of the platform and the language. But it passes it anyway just so that you can make use of it if you want to do platform or language specific customizations.

Let's take a look at all the objects that work together to make this happen. When the client starts up, in Direct to Java Client we use a special application class. It's a subclass of this U application that we use in the normal Java Client. It's called UDynamicApplication and it's responsible for initializing the dynamic UI generation. And its most important task is to create the so-called UControllerFactory.

The controller factory is the object that requests all the information from the rule system and instantiates controllers. So when we start up, we will make some rule system requests to the server and find out what kind of windows are available, what kind of action should I provide to the user. And the rule system on the server side will then take a look at two types of files. First of all, the EU model. This is the most important resource for the rule system. And then the so-called D2W model.

D2W models are the files that store the rules. And you can basically consider it to be the UI model. You have the EU model, which describes your data. It's the data model. You have the D2W model that describes your UI. So the rule system will analyze all these files and come up with an answer to the question and send this back as XML.

Then the controller factory uses this XML description, which is kind of a template for controllers, to create the concrete controller hierarchies. And those know how to create the user interface and the EUF objects that are necessary to edit your data. And then when the user works in the UI, he or she might trigger some action that actually requires to open other types of windows.

So there's a controller that registers for some events, and when it has to open other windows, this event will be basically forwarded to the controller factory, and then the controller factory will make another round trip to the server, request new XML, create new controllers, which create new windows.

One of the strongest features of the XML generation is that it's based on the WebObjects component model. So we generate XML, we use VoxML nodes, which is just a Vox component. We use dynamic elements like VoxRepetitions or VoxConditionals. And we use so-called D2W components, which are special components that connect to the rule system.

D2W components use a so-called D2W context. And the D2W context is an object in the rule system that stores all the input parameters that came from the client. It's also the object that basically manages the rules. And it's the entry point for you to fire rules, to ask for the answers. We call that firing rules. So that's actually a very, very strong feature because you can use the complete dynamic elements engine to generate XML. Instead of generating dynamic HTML, you now generate dynamic XML.

Direct to Java Client provides you two tools you can use to change rules. The first one is the Assistant. We've already seen that this morning. Actually, no, we didn't. But I think we saw it yesterday in one session. The Assistant is a tool that runs inside your client application and that you can use for the basic customization tasks. And if it gets more complicated, you have to use a full development tool running on the desktop. It's called the Rule Editor.

And you have to use the Rule Editor for all the advanced customization tasks. For example, if you want to change the startup sequence completely, if you want to introduce login panels before the query window appears, stuff like that, then you would have to go into the Rule Editor. And I'd like to ask Ron to come up again. And we would like to demonstrate the assistant and the rule editor to you. So if you could switch to the demo machine.

We are connected to the same server that we generated, to the same application that we generated in the first demo. And if you're in development mode, in the Tools menu, you'll find an additional menu item called the Assistant. So this is the Assistant. It has a-- there's a tab view for different kind of information. It displays the--

This is the XML we used for the query window. It's easy for you to inspect and see that the rules that you wrote actually do the right thing.

So what did we want to do? I think we wanted to go and change a few of the properties. So we'll start with the entities. We first of all move the user entity from the main entities. The main entities are the ones that appear in the query window. So we don't want the user there. We want to reorder it a little bit so that studio appears first, and then movie first, and then studio and talent.

And then we just press on the restart-- save the changes, and we press on the restart button. And as you can see, now our application has already changed a little bit. The user disappeared. We only have these six entities left in the query window. Now let's modify how we can search for movies.

So instead of searching for the title and the plot summary, the voting. Let's search for the title, the category, the rating of the movie, maybe the studio, and the revenue. And before we apply these changes directly to the UI, let's go and look at the studio query form. So it's the name of the budget. That sounds like just fine. So let's go on and go to the talent.

So as you can see, the Assistant follows you in the UI and updates to the place where you currently are. So if you just want to search for last name and first name there, the reason why there's no control for the folder is that Direct to Java Client found out that the folder is an NSData object. It's an image, and there's not really something you can enter in the UI, so it didn't even generate a text for it. So let's just reorder that, that the last name appears first, and then save and restart the application.

So now as you can see, we have different set of query properties for the movie. Click on Talent also. Okay, see last name is first now, then first name. And now I think it's the... Last step, we wanted to go into the rule editor. And actually, yeah, can you open that window? Sorry.

So as you can see, if you look at the plot summary, it just uses a single text field there. Let's say we want to customize that. So instead of using a text field, you use a larger text area with the scroll bar. You could do so in the Assistant by going to the widget pane and adjusting the parameters. But we want to demonstrate how to use the rule editor, so we'll do it by hand in the window.

So why don't you quit the client application. Then in Project Builder, there's this userd2wmodel file. So we open that in rule editor. So these are the rules that the assistant already generated for us. We're going to add a few to them. So that's going to be a little bit of typing for-- So as a starting point, I think it's easier for you if you just, yeah, run for the first one. So rules uses a so-called user qualifier that basically determines whether this rule applies to the current environment. And we just duplicated one of the rules that was there already and just modified it just because it's a little easier.

So as you can see, we basically wrote a qualifier that describes the plot summary that applies to an entity with the name plot summary for a form. And we're looking for a widget controller right now. So we want to give the answer to this question. What kind of widget controller should we use for the plot summary? And our answer is simply an EU text area control. Just delete those three and duplicate the first one again. So just duplicate that one. We want to modify a couple of parameters for this single digit. We already said it's a new text area controller. We also want to give it a minimum height.

We want it to be vertically resizable. And we don't want it to use a label component because this text area is the only widget in this tab view anyway. So we don't need a special label for that. So just save that. And then we are recompiling our application. We are starting it again.

OK, Ron's just searching for another movie again. Opening that one. And as you can see now, instead of using a single text field, we have a text area that has a minimum size, fully resizable. OK, thank you, Ron. So as you saw, the rule editor is a little more complicated to use.

That's why we have the Assistant. The Assistant will help you with the first tasks of customization. You can select the entities you want to see in the query window. You can actually switch the widgets. The same task that we just performed in the rule editor you could do in the Assistant. It's much easier there. But if you have very advanced tasks of customization, you can go to the rule editor.

And now I'd like to talk a little bit about localization. Because the localization scheme that Cocoa and Java Client by default use is that you have multiple versions of your interface files, one for the English one, one with German labels. But that's pretty inconvenient and very hard to maintain because if you want to make one change, you have to change multiple Nib files.

And direct to Java Client, everything is generated dynamically anyway, so also all the labels appearing in the UI are generated dynamically. So how can you use the rule system to perform localization? And the first thing you need to know is that by default, Java Client leads the generation of the labels, Direct to Java Client leads the generation of the labels just to the client. The client just performs some kind of beautification with entity names, attribute names, relationship names. That's how the labels appear. If you want to change that, you can actually use the rule system and force the labels to be part of the XML.

So, as I already said before, the client will pass some language and platform information to the rule system. The only thing you have to do is you have to write a few rules to return a localized label. And where you get this label from is up to you.

One suggestion could be you could go into your EO model, use the user dictionaries, and then add a localized version of every attribute and property name or entity name to the user dictionaries in your EO model. And then your rule system could actually access the user dictionary in your EO models. You could write one single rule to determine the label, but it's probably more convenient for you if you write multiple ones, one to beautify or to look for entity labels, one to look for property or attribute and relationship labels.

But the advantage of this solution is that you do it in one place. You don't have to maintain multiple files at the same time. You have probably one string table, or maybe it's part of the EU model in the user dictionaries, but just one single place where you have to maintain the localization information. You don't have to edit multiple Nib files. So the rule system is really much faster to do localization than if you do it by hand.

And I won't have time to show you an example of this, but if you go to session 612, Direct to Web, then actually Miguel has a concrete example running a localized application. Now I'd like to spend some time and try to explain to you why the default application looks like it does.

When Direct to Java Client starts, it analyzes the EU model. And the first step is to categorize the entities in the model. It distinguishes between three categories. The first one is the list of the main entities. Main entities represent the most important objects in your model. Those are the ones that appear in the query window. The second category are the enumeration entities. Enumeration entities are very similar to main entities in the sense that they represent a self-contained unit.

But they are very simple objects. They only have very few attributes. And they are usually used in pick lists. So if you want to have a list of states, a list of countries, a list of continents, maybe movie ratings, those kind of things are represented by what we call enumeration entities. And everything else is what we call dependent entities. Dependent entities represent detailed relationships of main entities.

Let's look at an example. So this is a model. We see a couple of entities here grouped around talents and movies and the relationships. Actually, Direct to Java Client uses the most important information inside the model it finds. It uses other relationships. And if it looks at this model here, it will probably find that there's a talent and a talent photo entity. And it will probably find that the talent photo is owned by the talent entity. It's dependent on the talent entity. A talent photo cannot exist without a talent.

So if we make the talent photo a dependent entity and the talent a main entity, the same is true for movie roles. Movie roles depend on talents. They cannot exist without a talent. So the first thing it finds is there's a main entity talent and two dependent entities, talent photo and movie role.

As the rule system looks further, if we find that there's also a movie entity and plot summary and voting also are dependent on movie. So there's another main entity, movie, and more dependent entities. And rating matches the description of an enumeration entity I gave you so far. The rating is used inside some pick lists. They're referenced by a movie.

And the rating matches the description of an enumeration entity I gave you so far. The rating is used inside some pick lists. They're referenced by a movie. And the rating matches the description of an enumeration entity I gave you so far. The rating is used inside some pick lists. They're referenced by a movie. and so this is an enumeration entity.

The second step for the rule system is to categorize properties. And again, we use four categories. First of all, we use a list of query attributes. So those are the-- or query properties. Those are the properties we use for searching for objects. There are list properties. Those are the ones that we use if we display tables of objects.

And there are form properties, which we use in all the input fields. These are the properties we generate input fields for if you want to edit an object. The fourth category is the identify category, and it's used whenever you reference an object. For example, in error messages, or if you just want to display quick information, just a little bit of information about a relationship, we use the identify attributes.

When it has this information, the rule system can determine what windows are available in the client application. It obviously would have a query window. If the model contains enumeration entities, it will also generate an enumeration window. For every main entity, the rule system will create a form window with the detailed user interfaces.

And also for the main entities, it will create modal dialogs that you can use to select objects when you want to assign values. So you could add modal dialogs that you can use for selecting the objects for the relationships. The model dialogue that we saw in the demo was that we selected a studio, for example. So both movie and studio are main entities, and we generated a model dialogue for the studios to search for.

So this is the information that the rule system has to determine when the application starts. And we then send this information to the client. And from there on, the client will make explicit round trips to get the detailed information about every single window. So that's the next step.

When the client asks for it, we will determine the concrete widget layout. And just an example, for form windows, the heuristics that we use are we use rows and columns for attributes. It depends on the number of attributes that you have, how many columns we choose. Or the mandatory to one relationships to main entities are displayed in boxes. So if you remember the movie window, it had a box for the studio. Or the other relationships, when the switch controller, which just use the Tab view.

And keep in mind, for all the enumeration entities, the rule system generates a simplified-- actually, sorry, I forgot about that. The reason why we distinguish between main entities and enumeration entities is that for enumeration entities, we can create much simpler user interfaces. We don't need modal dialogs and all this big user interface. We can just create a combo box or maybe a simple pick list. So the rule system will find that the reference and enumeration entity and then perform windows generate a simplified user interface, typically combo boxes or pick lists.

Now I'd like to spend a little more time on customization. There are three levels of customization. The first one we already got to know. The tools for it are the assistant and the rule editor. The first level of customization means you are working on the level of rules. That has the advantage, rules are fairly abstract. They can be applied to multiple models often. And they are very simple to maintain and to change.

The second level of customization is what we call freezing. Freezing means that you bypass the rule system and you hard code the XML that's supposed to be used by the client, or you hard code interface files, so the user interface layout, into a text file for XML or into a Nib file for the user interface files. Freezing means that you start to transition into traditional development, where you hard code UIs, or the behavior of the client.

The third level of customization is where you actually really back to traditional development. You actually write source code. The most common tasks are subclassing, using subclasses of our controller classes to change the default behavior. Or if you don't like the complete flow of the application, you can programmatically change the controller factory behavior, which can give you a very different flow to the application.

If you freeze XML, you bypass the rule system. You can decide whether to use just static XML, so we adjust the end result, or you can mix the XML with dynamic elements. So you can use repetitions, or conditionals, or D2W components to still generate parts of your user interface dynamically, and just use an XML template to round it.

You can decide to freeze complete windows or just little parts of it. It's up to you. And the more dynamic elements you use, the more your XML becomes a real template. We have some kind of an XML template that is responsible for this layout and form that I described to you. The attributes at the top, the columns, the relationships, domain entities, in boxes, the rest of the tab view.

You can change that completely by using a different kind of template. When you use frozen XML, you have to register it with the rule system. The way to do that is you just write a rule. It's detailing the rule system. Don't do the normal stuff. Just use this XML to find an answer.

If you freeze interface files, you bypass the rule system and even the generation of the UI on the client side. You basically tell the client exactly, this is the UI you should generate. That gives you full control over every single pixel in your UI. Again, you can choose to just freeze a little part of your window, or you can freeze the complete window.

If you only freeze parts of the window, then you can make use of so-called subcontroller areas. If you freeze parts of the window, that means that you will still have some subcontrollers that are dynamically generated. Some pieces of your window are still dynamic. And subcontroller areas are just empty views, empty boxes you can place in your interface file, and then the still dynamically generated controllers or the views of those controllers go into this place. So you can point the client directly to where to place the still dynamically generated UIs. I will show that to you in a minute.

Again, if you freeze interface files, like with Freezing XML, you have to register with the rule system, so you have to write rules. For interface files, you probably have to write two rules. First of all, you have to tell the rule system that there is an interface file. And second of all, you probably want to tell it to suppress the generation of additional subcontrollers. If you don't do that, the rule system will still generate all the normal subcontrollers and use the UI that comes from your interface file. So you need two rules.

When you actually write code, then you can do everything you want. If you don't like what we are doing in our applications, you can change it. There are so many things you can do that I can't even list them, but the most common tasks are you can subclass controller classes to support your own custom widgets.

If there's a widget that you wrote yourself and you want to have an association for it, you can write a controller for it. And that way you can easily get it into the dynamic UI generation. If you want a different layout mechanism, if you don't like rows and columns, you can write a controller that just lays out these widgets in a different way.

If you want, you can work with the qualifiers and fetch specifications that we generate. If you want to change the way we fetch objects from the server, you can do that in the controllers. If you want to add additional actions to a UI, if you have the default actions like save, revert, undo, redo, all this stuff, then subclass and controller classes is a convenient way for you to get that into your UI.

And I already mentioned that if you don't like the flow of the application at all, if you don't like query windows, you don't like form windows, you want to have one application that uses just one big window and is completely unusable, you can do that. And you do it with the controller factory. There are two ways you can do it.

You can either use your own implementation of the controller factory, so you can use a subclass, or as an alternative, we provide you with some delegate methods you can use, you can implement. It depends on your needs whether it's enough to use delegate or not. So actually, we have a demo for that. And although the slide says that Ron is going to give it, I'm going to give it myself because there's so much clicking that it would be hard to synchronize. So if you could switch to the demo machine.

I prepared a project that I want to use to show you some customization techniques. Let's start the server now. I use the typical Java Client launcher to connect to my server process. And what I did for this demo application, I first of all used the assistant to modify the main entities, the integration entities. I set some minimum sizes. That's why the query window already comes up with a nice size. I modified the query attributes of movies, studios, customers, et cetera. And I used some special customization techniques like freezing to modify the movie window.

So it's not pretty, but it's highly visible what I did. So this is a little different than the window you saw before. So first of all, we regrouped the widgets at the top. There's not a special box for studios, right? All the text fields are in one box now.

Also, we use multiple columns in the middle, but not for all the widgets. There's some additional You know, information for the user, what happens if he or she presses one of these buttons. Actually, there's a new text field that displays the number of roles. It's the same for the directors.

And for the plot summary, we changed the layout pretty dramatically. And also, please note there's a little button here, an additional action in the UI. If I press on that one, it's actually opening both talents. All the talents that are playing a role in this movie are opened automatically. So let me show you what I had to do to get this to work.

Project. First about the server, I didn't change anything. Well, actually, there's a two. But the standard classes like application, they didn't change. The session didn't change. There's still the main component. There's my items file. These are all the normal components of the WebObjects application. Then I grouped everything else that is specific to the customization in this additional group.

Let me show you the userd2w model file. So these are the rules that I wrote with the assistant. As you can see, I mostly changed property lists, what to use for querying. I set some minimum sizes for some windows. I determined whether I want to use label components or change the resizing behavior of some of the controllers. I changed the type of controllers, so in this case I used the checkbox controller instead of the normal text field. I used the text area controller. Those are all the things that I can just do with the Assistant.

Then I also used some frozen XML and some frozen interface files. And as I described before, I have to write some rules to register those frozen components with the rule system. This first rule here uses the key archive. So this one, this is the rule that I use to create and to register an interface file with the rule system. It's named plot summary form. It's an interface file for this piece of the UI. I'll show that to you in a second.

And then for the same context, I had to use this rule here. I mentioned before that I need two rules if I want to work with frozen interface files. It says generate subcontrollers false. So I suppress all the generation of subcontrollers because I have everything in my interface file.

And this one is the rule that I use to register frozen XML. MovieForms is the name of a component that contains my XML. This is the rule that registers it with the rule system. So let me show you the interface file first of all. And while interface build is launching, it should be fast enough.

So this is the interface file. As you can see, I was just interested in changing the layout for this piece of the UI. So all I have to do in my interface file is specify the widgets that I need in this particular view of the tab view. and you know you can choose which pieces you want to put in the interface file and which ones you want to put in XML.

The movie form here is a component This is the XML. I started with the XML from the Assistant. I went to the Assistant, went to this XML view, and selected what the rule system had already given me by default, and then copied this into this whole component and modified it by hand. So as you can see, I introduced this box controller, and then these are the two columns for the text field controllers that we saw.

And I also mixed that with other dynamic-- or with other components. So I have frozen XML or the static XML, and I can mix that with other web objects. So the other VOOC components. If we look at the VOT file, you can see that I'm using EU switch component, which is another subclass of D2W component.

And this is a way to plug into the rule system again. I created the template using some XML, but some of the UI is still generated by the rule system, which means that I can still access it and modify it with the assistive. Also, as you can see, to display the number of roles and directors, I used two components. It actually turns out that they are the same. So I created a reusable component called countDisplay.

It just has some other WebOptics components in there. It's a static label controller. It's a text field controller. And as you can see, I'm just using voxml nodes to specify the content of this. So there's a voxml node for a component controller which groups a label controller and a text field controller.

And the last thing I want to point out to you is to plug in my controller class. I just specified it here in the XML. I just gave it another class name. So I'm using a form controller. I'm using a special class name. This class is here, and as you can see, it's subclass is EO Form Controller. This is the code I had to write to open all the talents.

This method here registers an action, which basically is responsible for creating this button in the UI at the top right of the window. This is a method that determines whether this button should be enabled or not. And this is the concrete implementation of the action. So as you can see, I'm just getting the editing context, asking for the talents, getting the global IDs, and then I'm using the controller factory to open the form windows for these global IDs. So that's all I had to do to make this happen. OK, if you could switch back to the slides.

I still owe you a few reasons why you should use Direct to Java Client. And the most important one to me is that you end up with a much better development process. If you start, you know, projects with the traditional development, you first of all have to write some application logic, you have to create some user interface files, and you know what? They are all subject to change anyway, because the first time you show this to your customers, they will change their mind. It's always the same. So with Direct to Java Client, you can actually focus on the business logic first. You start with the database, your model, and maybe implement business code.

You just created a default application, and this default application is already able to execute your complete business logic. So you can go and show this to your customers. They can try out the business process with it. If you want to show them a little more how it will look like in the end, you can go and customize with the assistant or the rule editor. Or if it's not good enough, you can freeze some XML, but it's piece by piece. You only do what you need to do, and you still focus on your business logic.

It's really important. And then just in the end, when the customers say, okay, this is the business process I want. It's doing all the right things. I just want a polished UI. Then you go ahead and fine-tune your application. But the important message is really, with Direct to Java Client, you always have a working application that you can use to execute your complete business logic.

So the benefits are that, first of all, it's very fast and efficient to develop a Direct to Java Client because so many pieces are done for you automatically. It also allows you to react quickly to requirement and so database changes because a lot of the changes in your business model are picked up automatically by the rules.

You don't have to go and change interface files for that. It just happens automatically for you. Since you use a lot of predefined application functionality, your testing time should also be reduced. We already give you this functionality. You don't have to write it again. We did some testing with it.

Maintenance of Direct to Java Client applications is easier because it's mostly data driven. You don't have to write a lot of source code for it. And maintaining and editing data files, XML files, is much easier and much less error prone than writing source code. And again, you can focus on your business logic.

So before we go into questions and answers, I'd like to give you a few tips for using Direct to Java Client. The first one is try to use it for every project. Direct to Java Client is Java Client. It's not different. It's just a different way to start a project and to maintain a project. Prototyping is so much easier and with the customization techniques that we have, freezing XML and freezing interface files, you can smoothly transition into traditional development.

So the other piece is, the other tip is, try to define reusable components. You know, you're used to that with WebObjects anyway. Create frameworks, you know, that contain common rules. If you want to define your corporate look and feel, put it in a framework. If you develop things like login panels, reporting, put it in a framework. You can use frameworks and reusable code with Direct to Java Client as you can do with any other application. Also keep in mind that localization is so much easier with Direct to Java Client.

And it might actually make your deployment a little simpler. The reason for that is that if you want to upgrade your application, if you want to fix a bug, you can often do so on the server side, because the rule system lives on the server. So by upgrading your server system, you can fix bugs in your client side. And that might reduce the need to install upgrades on the client machines.

So Direct to Java Client makes your life really easy. You generate applications dynamically based on information you find in your model. There's a lot of predefined functionality. You have powerful customization techniques, and it's a smooth transition into traditional development. And it's designed for extendability. It's so easy for you to plug in your own controller classes, your own source code. So before we go into Q&A, I'd like to ask one of our long-term WebObjects developers, David from CodeFab, to come up on stage and share some of his experience as a Direct to Java Client with you.

So in the last year or so, we had the opportunity-- I'm Bill Bumgarner with CodeFab. We had the opportunity to do a number of projects that used either Direct to Java Client, Java Client, or Direct to Web. In this particular context, they're really all kind of the same thing because they all build on each other. And the key thing is that it's real.

I mean, this is real technology. This has led us to great success stories in the field, being able to deliver technologies to our clients that work, they work quickly, and to be able to deliver those things quickly. One of the other changes we made in the last year is we moved to an extreme programming process.

One of the fundamental tenants of that process is that you want to deliver early and you want to deliver iteratively and often. What that means is that when you're working with the client, you want to hand them an example of their data live, of their business live, as quickly as you can so that they can start to interact with it, so they can take ownership of it, and so that they can start providing you with feedback so you can customize this stuff quickly to meet their needs.

And what we found with these technologies, because they're so centric to not steering you in the direction of building monolithic pages or monolithic user interfaces that are very inflexible, they're much more about building little components and providing these rules that drive the components to work together to provide the ultimate solution, that in that context of iterative development, we were able to work with the clients to provide solutions for them very quickly that met their needs.

And as their business changed, as the project changed, we were able to change with it. One of the key things is that as software developers, we're experts in software development. When we're working with a client, and I mean in any market, not just consulting services, but shipping shrink wrap products, even like Andreas at Apple, ultimately his client is Apple.

When you're working in that kind of a context, you are the expert in the technology, your client is the expert in the business. You want to work with them to provide the best business solution. If you were the expert in the business and the expert in the technology, why are you working with the client in the first place? Just take over the world yourself. But that's not the case.

And these tools really provided us to deliver to the client these solutions very rapidly. To give a specific set of examples, we have a particular set of interfaces where the client came to us very late in the project cycle, said, you know, we really want to have custom date editors throughout the user interface.

So we sat down, built a little date editor widget, and then tested it out in one specific small context, one very tiny piece of user interface, turned around, went into the rule editor, and said to the rule editor, any entity that has a date attribute where the date attribute needs to be edited, use this widget. Suddenly our whole user interface is using this new widget set. I can't think of another technology where we could do that. So it's real. Use it. It's very cool.

Okay, the typical reminder, the WebObjects lab is open until 6:00 today. Please vote for WebObjects' best app server. The additional sessions I recommend for you to see are Direct to Web tomorrow. Also, there's an advanced Enterprise Objects framework and an advanced Java Client session tomorrow. All of them in this room and the typical contacts.