Good afternoon, everybody. Welcome back to Direct to Web. I'd like to introduce our next presenter, Miguel Sanchez. Good afternoon everyone. Can you hear me okay? Thank you for coming to hear our session on Direct to Web. I know you're probably sick of this polls at the beginning of the sessions, but I really need to get a read of how many of you are WebObjects developers here in the audience? Now, how many of you have used Direct to Web? Okay, so there's a good number of people there that are using Direct to Web. We'll say something like 5% or so.

So you probably feel a little lonely being the only users of Direct to Web, right? But, you know... By now we've all been indoctrinated about the relevance of BMW and our use, so let's see if we can bend some statistics here. So we all know that BMW has 3% of the market, but... For anybody that's been out here in California for more than a week realizes that locally, it looks more like this. Right? So it's, when you're doing this statistics thing, it's very important to have a good grip of your universe that you're getting your sample from. You can't just make up numbers, right? So we take this thing very seriously in WebObjects.

So over the lunch break, I stood over in the corner and I tried to count cars, and I didn't really find any data that substantiates this, but I'm just guessing that about 6% of the remaining people use 76 for Pintos, right? And you can't compare apples and oranges, but out of those people that use for Pintos, about 90% prefer Pinto beans in their burritos when they go have Mexican food, right? So what does this have to do with Direct to Web? Not really.

Not nothing. Not much. Okay? Direct to Web is not a technology you can explain with pie charts. So you'll have to sit through my presentation of one hour, and hopefully you'll get a little more excited. This, just as a point of reference, this is... This is classified as an advanced WebObjects session, so I'm assuming some WebObjects knowledge here.

This is sort of like, if you're already a WebObjects user, how can you take real advantage of Direct to Web? So, you've probably seen in the past, it's been demoed in other sessions, and we've shown you how Direct to Web jumpstarts your application. In this session, I'm going to focus more on how much you can customize your application once you've started.

What will we learn? I'm going to talk about the architecture of Direct to Web, so you become more familiar with what's going on behind the scenes. One of the most important things in the architecture of Direct to Web is the rule system, so I'm going to spend some time explaining to you what the rule system does. And of course, the recurring theme of the talk is how you can customize Direct to Web applications at all kinds of levels.

Brief overview of what Direct to Web is. Direct to Web is infrastructure for making your development of WebObjects applications easier, much easier. How do we achieve this? We achieve this by giving you a lot of pre-built functionality. We give you a head start, so you don't have to start from zero, from basically doing nothing other than giving us your database model. We give you a full running application.

Direct to Web is not really an application. Don't expect to find a directtoweb.app anywhere in your system. Rather, it's a set of frameworks and tools. Although I will be referring to Direct to Web applications, I mean your applications that use Direct to Web. And Direct to Web introduces something new to WebObjects, which is rule-based programming, to say it one way. I'll talk about that. What is a Direct to Web application? Most importantly, it's a normal WebObjects application with an HTML frontend and that uses EOF in the back.

Like I said before, you probably started with a lot of the pre-built components we give you. And you customize the application we give you either from zero, you actually have a running database application without doing anything, to quite extensively, as I'm going to show you. And you know WebObjects gives you a lot of great runtime flexibility. Direct to Web adds to that. It gives you yet another level in which you can change your application.

So now we're going to go to a brief demo to show, just to show Direct to Web to those that have never seen a Direct to Web application. Can we get the demo machine up on screen? Can we get the demo machine up on screen? Thank you. So the starting point for a Direct to Web application is always a database model. That we ask from you, in addition to the price of Web objects. So the example we're going to be using throughout our application is a simple bug tracking tool. You're all developers. You probably all have a need for something like this within your projects.

We have a very small, simple database that has two main tables. The bugs, which problems you have on your software. The users. Users can either have created the bugs, or be the engineers assigned to fix the bugs. And you have lookup tables like the state of the bug and which project it belongs to. So that's what we start out with.

Once you have the project and you create a Direct to Web project in Project Builder, it uses it. Oh, let me stop here for a moment. I've noticed that a lot of WebObjects developers out there have been paying very, very close attention to our demos and whether we click something or not. Let me come clean on it before. To save some time, we pre-compile some of the applications and we've set some defaults. We're not showing every single step here.

Don't spend too much time trying to figure out why we skipped it. We're just trying to save some time here. This is a project that was created using Direct to Web. All you get is a basic template for a WebObjects application. It has an application, class, a session, and very basic components. It knows about the model. All you gave us was the model. Let's look at the project in the browser.

Remember, you haven't done anything other than prepared your database and given us your model. What do you get for free? You get a full-fledged database application with a fake login page. That's just a starting point for your app. It doesn't have any login logic. We're just going to log in right now.

But the application automatically knows about every entity in your model, about all the attributes in your model, and creates the most generic database access application for it. So if we look at the pop-up on the left, you'll see that this application already knows about bugs and projects and states and users. And it gives you the basic pages you would need in any database application to query on them, to list the results, to edit data. So for example, let's go to the search page for the bug.

Direct to Web gives us this page. It knows about all the fields in the bug table in our database. Let's query on it. We won't specify any search criteria for the demo here. We have a list page here. We get all the results from the database. We can go down to a particular page. Click on the first one, please. We can look at the edit page to analyze the attributes of the bug.

So I'm not going to go into much detail here. The point is, you get this for free. So any WebObjects developers out there should at least use Direct to Web as your database administration tool. You get this application for free. Why not use it? Now, of course, we can't guess everything you're going to want in your application.

So you're going to want to customize certain things. For that, we have an applet written in Java running alongside your application. Ernest is going to maximize now, which it hung, actually. We have to restart the app. I promised myself that every time this thing crashed, I was going to give out a T-shirt. I hope it doesn't crash more than twice.

Did you relaunch the applet or the app? OK. So by now, you've probably all heard that if you've been coming to our talks, how we're using-- we're not using the final bits of the Java, of the MRJ drop that's going to be released tomorrow. So the things didn't come together at the same time. So we relaunch-- that's also why we're launching it from the command line, because we didn't have embedded Java running in the browser.

So anyway, we have the applet running alongside our application, which allows certain levels of basic customization. For example, if we go back to the Edit page, you'll see that the title is at the bottom of the page. Let's say we want to rearrange them. So we want to rearrange-- think of the applet sort of as an inspector into your application, and you rearrange the title to be the first thing. And then you do your project, and then you put the state of the bug as your second thing.

And here's where the power comes in. You save, and without restarting your application, you refresh, and you get the change. Okay? You can do other kinds of things. See the project line and the state line? Those are relationships. We want to use other kinds of components to display them.

We want to use a little browser to display the available projects that the bug can be assigned to, and a little list of radio buttons to display the list of states that the bug can be assigned to. Miguel Sanchez, Patrice Gautier So you have those kinds of components available to you with Direct to Web. Again, he's doing those changes. He saves. We do a refresh.

and we see things like that. So I'm not going to spend a lot of time, actually any more time than this, explaining all the little things you can configure with Direct to Web. The point is you get an application for free, you gave us your model, and you can configure it at least at, this is the first level you can configure it at. Now let's go to the project.

Just to briefly show the project, the point here is all of what you just saw on the screen has, for now, no code in your project. We're not a code generation wizard here. We didn't just dump out all these pages for you. All of this is being generated dynamically behind the scenes by the Direct to Web infrastructure. So there's no code in your project yet for any of this.

Now could we go back to the slides, please? Can we go back to the slides? Oh, thank you. So, let's look at the architecture of the apps in a little more detail. Like I said, these are basic WebObjects applications. These are normal WebObjects applications using HTML with the app server in the back.

If we look inside, you probably have your code interacting with the EOF framework and the WebObjects framework. You would use EOF to access your database, having given us the definition of your database through an EO model. And you probably defined a bunch of wall components that give the look of your pages. So, these are the applications you should all be familiar with being WebObjects developers.

Direct to Web, abbreviated here as D2W, is just another framework you include in your project, or another framework already included in your project when you create a Direct to Web project. Like you saw, this framework must have a whole bunch of pre-built components to display lists and edits and queries of the entities you have in your database.

Now, these components are built using normal WebObjects component. There isn't too much trickery here. But, they have to be configured at runtime by something which we call the rule system. The rule system uses information from your EO model to find out about your entities, obviously. We don't know what they are until you give us one.

And also, from another file we introduce, which has the extension D2W model file. For now, I'll call it a rule file. Think of it as a text file with a bunch of rules. So, the rule system uses the EO model, the rule file, and then the components to display and configure the pages at runtime. Now, let's talk about the rule system in more detail.

The rule system consists of a set of rules and classes to derive values from those rules. It answers questions at runtime we might want to know as developers. We might want to know, well, what background color should I be using to display this string? How should I display the property name in case I'm localizing my application? Which component should I use now? So we use the rule system to get an answer to all these things.

How do we interact with the rule system? The first thing the rule system needs to know is where our application currently is. What is it doing? We have to tell it this. We have to tell it which task we're trying to perform, which entity we're dealing with, and more specifically, at the entity level, which property or attribute we're handling. So that's what the rule system asks from us. Tell us where you are.

Once you've, I'm sorry, I forgot something in this slide. We tell the rule system this something using an instance of a class which we call the D2W context. For now, think of it as nothing more than a dictionary of key value pairs where you tell it how, where your application is.

Once you've initialized one of these contexts and you've told the rule system, this is where I am, you can now ask it to derive more values. You can now say, okay, so what is the background color I should be using at this point in time? What is the display name for property? Notice that I've shortened the full English questions into variable names here.

The context uses the rules, a process which we call firing, to get information back to us. Let's give an example. Here we have a very simple rule set with three rules. What kind of information is specified in this rule? In the first rule, we say if the task is edit and the entity that we're handling is a bug and somebody asks us what the page name should be, the result should be my edit.

The second rule says if the property is name and the entity is user and somebody wants to know what the localized name is, assuming we're localizing to Spanish, we return nombre. The third one says if we're listing users and somebody wants to know what table color we should be using, we use red. Okay, this is a very simple rule system, a very simple rule set, but it just hopefully you'll get to see how the rules look.

How would this be used by a context? Let's say we initialize a context with the following two values. We say the entity is user and the property is name, and we want to know what the localized name is. So we initialize a context and we ask the context, now derive this value for me. The context goes off and says, and finds a rule that resolves something about the localized name.

Then it checks on its left-hand side and says, does the context I was given bind in with the conditions that this rule specifies? And it will find it, and it will return us localized name. So from a developer's point of view, anywhere in our code where we see D2W context dot localized name, that will be resolved at runtime to nombre, assuming we have initialized the context to these values. Now this is a very simple example, but the rule system is recursive.

So the end question you might be asking might require several other intermediate steps for the rule system to get yet more values to the context. So it will ask more questions and initialize itself with yet more values, and then in the end, it will give you the answer you want. So it's recursive.

Now that I've talked a little bit about the rule system, let me show you, like, pull the curtain on Direct to Web and show you what the essence of this. How do all the pages that we provide for you really work? Like I said, we use standard WebObjects components to build our pages. The only difference is that these components use the rule system to configure themselves at runtime.

This is a normal Web object component that doesn't use Direct to Web, that you should all be familiar with. You have an HTML part and a WAD definition. Let's say that you're generating some sort of edit page. So this is your solution. So you even hard code something like name colon, and the only runtime information you want is the actual value of that name. So you introduce a Web objects tag, and then you resolve that tag using a woo string messaging the current object's name attribute or runtime. This is normal WebObjects programming.

The pages we provide for you look very similar. We have HTML and we have a WAD definition, but our pages have to be more general than yours. Because, let me go back one page, yours says name colon there because you know it's your solution. We don't know really which attribute we're displaying until runtime, so that has to be another dynamic thing that we resolve. And in our bindings file, notice the use of D2W context dot display name for property. So we tie into the rule system to find out, okay, what is the name of the property I should be displaying now? And we do that.

So components like that is what the Direct to Web framework provides you. Those are called Direct to Web templates. And as you saw in the first demo, we give you some basic things. We give you pages to do queries. We give you pages to edit and to do listing. These templates automatically configure themselves to the database model you're using in your particular situation. And we use the rule system to get information at runtime. Of course, what you're all here for is, these can be customized.

How do you customize them? You can customize them at the very basic level like we showed you in the first demo by using the Web Assistant applet running alongside your applet. You also have full access to the HTML. So that's a very high level. You can really just redraw the HTML as you see fit.

You also have low level access into certain components we plug into the page. So you might like our HTML, but you just want to display your strings a certain way. So you can do that. You can plug in your own components. So I'm going to show you these two things in the next demo.

Do we have the demo machine please? Miguel Sanchez, Patrice Gautier So when we last left our application in the prior demo, we had this generic database access application that had list pages and query pages. So here's a list page, right? Now let's say that we're just picky developers and we don't want that garbage can on the right to show up there and the edit icon on the left to show up.

So you just don't want that. But then you bring up the web assistant and you realize that I didn't think far enough and I didn't really offer you a way of getting rid of those things using the web assistant. No problem. You still have access to that page. Using the web assistant, you can tell it, please give me the HTML to this page.

Copy the HTML of this page into my project. We did this operation before the demo. Can you bring up the project? Once the HTML is copied into your project, You see, can you point to the list? Yeah, there it is. So we copied the actual HTML that Direct to Web uses to generate that page is now copied into your project. We can open that HTML in Web Objects Builder.

And you have full access to it to do edits. Now there's something special about this HTML. Remember, this is the HTML that comes from Direct to Web. It's HTML that should be able to adapt to all kinds of models. So you won't find any references to your particular project in this HTML. There'll be a bunch of repetitions and conditionals and no reference to your specific model because all of that is resolved until runtime.

So if we look at the actual raw HTML and the bindings, let's look at the bindings there. And let's say, for example, the attributes order there. If you look at the line that resolved the display key, you will see a reference to the D2W context. So this is the HTML Direct to Web uses to draw your page at runtime.

So it's a very generic form of HTML. You will see why that's important in a minute. For now, can we go back to the page briefly, Ernest, to show what we wanted to do in Internet Explorer? Remember, we wanted to get rid of the trash can and the edit icon. So first, let's show that we're actually editing that page. Ernest is going to type a little message saying, this is my HTML.

We make the font a little bigger so that you can all see. We save and then we-- I precompiled the app before this part of the demo, so we were able to refresh the page. And just so you know, we are accessing this version of the HTML. So now we go back and do the actual changes we wanted to do. We wanted to get rid of the trash can, so we look for the trash can and we just get rid of it. We don't want it in our application. And we want to change the edit icon from being an image to a hyperlink with text.

So this is not a session in graphic design, so I'm not going to impress you with any fancy HTML editing. I just want to show you as developers that you have access to that HTML. And you refresh, and those are the changes, right? So you might say, well, so what? That's what WebObjects does. Yes, it's what WebObjects does, but can you bring up the Web Assistant? Remember that this is still a Direct to Web page.

So on one hand, you have access to the HTML, and you do your layout as you please. But on the other hand, look at the title property over... Can you make the browser... Don't refresh yet. Yeah. See the title being there on the right? Let's say that we want to move the title over to the left and remove the creation date row, column, I'm sorry. So we can still use the Web Assistant for that. We do save, and then we hit refresh.

So you don't lose the ability to the dynamic aspects of Direct to Web by editing the HTML. Those that have used Direct to Web in the past and are familiar with freezing pages, this is not freezing pages, this is generating templates. In prior versions of Direct to Web, you would freeze your page and you have full access to the Java and the HTML, but then you would lose this. So that's the high level. You're changing the HTML. Now let's go a little low level.

Do you see where it says description text and resolution? Those strings are kind of long. Let's say that you as developers have written a little component that shortens strings, that only displays the first 20 characters of your string. It could be anything else, but for demo purposes, you have a little component that shortens strings. We have such a thing in our project. Can you bring up the project, please? Show the component. Short string.

So just a normal WebObjects component that takes an object and a key binding and if it receives a string value that is greater than 20 characters, it just truncates it. Nothing special here. What's special is that this could be any one of your components. Now go back to the page and the browser.

Now, look at this. We don't stop the app. We're still running. We go over into the Web Assistant and we say, for the description, we want to use a custom component whose name is short string. So we type in short string there, and we're going to do the same thing for the resolution text. So without restarting our application, Direct to Web is going to know that in that page, it should plug in our component.

So he's doing it for the second one. And remember that our component had an object and a key binding. So that's how we instantiate your component, and we give you the object we want you to display, and it's up to you. So now, remember, no restarting the app, just refreshing your browser. There's our component.

Okay? Very simple, I mean, non-flashy stuff in terms of the HTML we're showing you, but I hope that as developers you're seeing the hooks of where you can plug in your own code and your own HTML. Now, can you bring up the rule editor for the model? Bring up the project first and show the resources bucket.

I'm showing you all this without generating much code, right? So where's all this information about what I should be displaying being stored? As we do all these configurations, we're creating rules specific to our application. Those rules are being stored in a file called the user.d2wmodel file. To look at the file, to look at that file, you can use a tool called the rule editor.

Can you bring up rule editor, please? So all those configurations we're doing using the Web Assistant are stored as rules in this file, which we use rule editor to edit. So that's where the magic is going, because I haven't been showing you code. I've shown you HTML, but not code. But you're noticing that I'm changing stuff, so where is that information going? Here. That's where it is. So that's the end of our second demo. Can we go back to the slides, please? Oh, they're there. Sorry. This monitor still shows the other one.

So I've given you an overview of the architecture of Direct to Web and how the rule system works. Now let's focus a little more on you as developers. Where-- let's review some of the stuff I show you on the screen. And where, as developers, if you're working on a Direct to Web application, where do you think about plugging in your own HTML or your own code? Well, first of all, don't forget that a lot of the things in Direct to Web are now driven by rules.

So you're all used to writing Java and changing component definitions in Web Objects Builder. Now create another space in your brain to think about rules. You know, maybe I could do some, maybe I don't need to write Java. Maybe I don't need to change HTML here. Maybe I could change this with rules. So start thinking in terms of, can I just, is it, maybe it's simple enough for me to add a certain rule and my application could be reconfigured. So don't limit yourself to Java.

A little bit unrelated to rules, but another point where you can plug in your own code is custom components. Custom components is what I used on the second demo to shorten the string. So you probably have your own components to display integers or whatever you're displaying your own way. You use a custom component for that. I'll give a little more detail.

You also have Java API to invoke Direct to Web pages. You might have a WebObjects application that does not use Direct to Web, or at least in some parts it doesn't use Direct to Web, and then the user clicks somewhere and they want to jump into a dynamic Direct to Web page. There's Java API to do that.

We also have named configurations. You might want to reuse a certain page, such as query, in a slightly different style without really rewriting your whole page. You can define two versions of the page and use it slightly differently. I'm going to go into detail into each one of these. And you also have Java API to plug into the rule system.

Rules. Like I said, all of the configuration information we're doing with rules is stored in two files. The configuration you're doing with the Web Assistant, which is the web applet running alongside your application, is stored in the file called user.d2wmodel. So anytime you save your changes in the Web Assistant, they go there. You probably don't want to put your own rules there because the Web Assistant is going to override them.

Unless you're not using the Web Assistant and then you're never saving out to that file again. But if you're using the Web Assistant, you probably want to put your rules into the second file, which is called d2w.d2wmodelfile. You just add a text file to your project and you start adding rules there. That's the second file.

Also remember that your entry point to rules is this thing we call the D2W context. So we use key value coding and you do somewhere in your code D2W context dot and then the thing you want to resolve to and it will be resolved to you by the rule system.

Now let's look at custom components. For custom components to work, you need to implement two bindings, or you need to be aware that Direct to Web is going to give you two bindings. Remember, custom components are that thing that we're shortening the string. So we're going to give you the object that we're working with and the key that we're currently displaying.

So having that information, you do whatever you want. You display that value as you want, using the HTML and the logic you want. So you probably will end up using key value coding somewhere in your component in this manner. You've seen our key value coding utilities in another session. So somewhere in your custom component, you're probably going to have a call, a line that does this. It says, okay, get me the actual value from the object that you passed me. And then you have the value and then you do whatever you want with it.

And as you saw, once you have your custom component, you can plug it into your application, either using the Web Assistant or writing your own couple of rules to plug it in. You only need to do two rules. One saying, for this property, please use the custom component, and the custom component name you should use is this.

Direct to Web API, Java API to plug into Direct to Web pages. You can instantiate and configure Direct to Web pages from your code using Java. Now, you don't use the normal WebObjects mechanism to call up a page, to get to a page that uses Direct to Web. Instead, your entry point is the main class of Direct to Web, D2W, and a static method on it called factory. So that's sort of where you, instead of messaging wo application dot application, your entry point for these kinds of pages is D2W dot factory.

Now that class implements methods that return all the pages, all the kinds of pages that Direct to Web provides for you. So, there are going to be methods in that class that return the edit page for a certain entity, the list page for a certain entity, the query page for a certain entity.

Once you get back that page, the object you got back compiles to an interface that we define so that you can configure it. So within the Direct to Web framework, there are certain interface definitions such as edit page interface, list page interface, and query page interface, just to name some, which you use to message this page which you just got back to configure it. Let me give you a more concrete example.

Let's say that you have a WebObjects application where you're doing your normal stuff and you want to implement a method that returns a Direct to Web list page. You already know the data source where the data is coming from. You just want to show that data up on the screen using a Direct to Web list page. So your method would be called something like Return a List Page method.

You know that what you're returning is going to implement the list page interface, because you're going to be using Direct to Web to get to this page. You use the factory to ask for the list page for the entity. I don't know what entity. Notice that E, the entity, is one of the attributes you pass to this method. That's up to you, right? So at this point you say, D2WFactory. give me the list page for this entity. And we ask for a session to do certain initializations.

So we give you the list page, but that's just the list page without knowing where it's getting its data from or where you want us to go after you're done with it. So you use the methods implemented in the list page interface to kind of initialize this page. So you set the data source. I'm not showing where the data source comes from here. That's your responsibility.

The point is that you tell us. And you also tell us what the next page you want to be after you press return. the list page. So this is how you would call a list page using the Direct to Web API or any other Direct to Web page. Named configurations.

Let's say that in the application we have, remember that it's a bug tracking system. We have ways of querying on bugs and on users, etc. Let's say that for the query page, we have two levels of access for our users. We have simple users that only see a limited number of fields they can query on. And we have advanced users that see a much bigger set of fields to query on.

But we want to use the same page. So we define what we call this a named configuration, and we give it whatever name we want. In this case, we're going to call it our simple query named configuration and our advanced query named configuration. Once you have these two configurations, and I'm going to demo this, I'm just showing you the slide.

You call up the named configuration using the method page for configuration named, which behaves similarly to the other methods I have shown you. The last thing I want to talk about is how to integrate your own code into the rule system. Up to now, the rules we've shown you are these kinds of very simple rules that have a condition on the left and I'm sorry I skipped one.

This is, this is, the slide is wrong. Instead of localized property name, it should have been a constant value. That was the first part of the animation. So up to now we had rules that had constant names that they, the things they resolved to were constant, specified as strings. Remember where it said bug title and things like that.

But wouldn't it be nice if when you're resolving the value of this rule, you're actually calling one of your methods? For example, localized property value. Let's say that's your method. You want to define in code how you're going to resolve this rule. You can. You can implement that method in a subclass of default assignment, which is also one of the classes provided in Direct to Web.

Here's an example of how you would implement that. You have a subclass here called MyAssignment, which is a subclass of default assignment. It implements The method, you can name it however you want. In this case, it's called localized property name. Within the method, because you have a subclass of default assignment, you have access to the context. Remember, the context is your entry point to the rule system.

So once you're in the context, you can ask it, hey, what's the property I'm working on right now? What's the session, by the way? What is the session I'm dealing with? And then you do whatever you want with it. Right? I'm not showing you how you're localizing here. It's just the point is that's where you do it. That's the entry point for you to execute your own code. You do whatever you want.

And then you return a value to us. Let me show you that in the application. Do we have the demo machine, please? So this is our application. Let's review where we are now. Ernest just logged into our application, and you'll notice that the first page that came up was something which we call the query all page. This is the page from which you can query on any entity in your database. We don't like that.

That's what I give you by default. You don't like it. We're going to change that. What we want to happen when a user logs in is that instead of seeing the query all page, they jump right into the bug query page. We want to pull them straight into the page where they query on a certain bug because they're looking for bugs.

But not only that, we want to have that page be different depending on the kind of user that logged in. If a normal user logged in, we only want them to query on two or three attributes. If an advanced user logged in, an engineer fixing the bug, we want them to be able to find bugs and more attributes. How do we do that? We use a named configuration. How do we define the named configuration? With rules. Let's bring up the rule editor.

So here we have the three rules that define our simple query named configuration. Remember, the name is arbitrary. You can pick whatever you want. When you define a named configuration, the rule system needs to know, okay, which task and which entity am I dealing with when you ask for this configuration? So that's what the two bottom rules are for. It says, if the named configuration is simple query, the entity is bug, that's what we're doing, and what we're doing with the bug is querying on it. So those are the two things we do.

The interesting rule is the first one. Can you click on that first one? The first rule says, if we're in the simple query named configuration, and somebody asks us what the display property keys are, this is just an internal Direct to Web key, if somebody asks us which properties of this entity should I display in this case, we say, oh, for simple query, we only want title, description, project, and creation date. For advanced query, let's go now to the rules that define the advanced query.

We're using rule editor. We have more rules defined in this file, but we're filtering to show you only the ones that are relevant to the demo. So for the advanced query, again, we say, the advanced query is something that deals with bugs, and we query on bugs. And when you ask us what properties you want to display, we have a much bigger set of-- a full set of all the properties.

So that's how we define the configuration, with three rules. We're not writing code. We will write a couple lines of code right now, but we're not rewriting your page. So how do we plug in these rules into your page? Do you remember that when I gave the first demo, I said that the login page didn't do anything? It was just no logic. You just click on the login button.

We're going to hook into that page so that when the user clicks on the login button, By default, we take you to the Query All page. We don't want you-- we don't want to take you to the Query All page. We want to check which user logged in.

If a normal user logged in, for demo purposes, normal users are going to have the login username just user, and advanced users are going to have the login username admin. So can you go scroll down to the method? So default page is the method that is executed when you log into the application. We have some very simple logic here.

Can you highlight the if statement? We initialize with the session where you-- with the kind of user that we're using. And we just do a very simple check. You know, if the person that's logged in is called user, let's call up the simple query name configuration. If the person that logged in is named admin, let's call up the advanced query.

Query name page. If the person that logged in is none of those, let's bring up the default page that should show up in any direct web application. We run the application. We log out. Log in as nobody right now. So we log in as nobody. There's the query all page. We log out. We log in as user. There's our simple query page. We log out. We log in as admin. There's our advanced query page.

Again, there's very little code to do all this. You're defining a lot of this in rules, which are stored in a text file. And the code you saw there was really just to plug in the page that we wanted to see right after we logged in, and to call up the named configuration. Again, where is this query page? You haven't even seen it. It's out in the Direct to Web framework, and it's working for you.

The last thing I want to show you in the demo is, can you... Let's show the query page again in the browser. So here's the query page. Notice how the names of the properties on the left are in English. It says title, description, project, state, creator, creation date, assignee, and resolution. Okay? But not everybody speaks English in this world. We want to localize our application. We want to use the rule system to change those titles without writing a lot of code.

Now, the Direct to Web, when it's displaying this page, it's resolving a binding called display name for property. As long as we can hook into that binding and plug in our own code that localizes the name we want to display, we're okay, which is what we're going to do now.

In the rule, we had disabled that rule by the way, so you wouldn't see it in the first part of the demo. Now we enabled the rule. All the rule says is the following. It says, look at the lower left hand side, that's sort of the condition part of the rule.

It says, if my task is query and the entity I am dealing with is bug, And the key I'm trying to resolve is display name for property. That's one of the keys that Direct to Web uses. I want to plug in my own method called localized property name. That method is implemented in the custom class called localized string assignment. That's my own class. Let's look at that class. That class is in our project.

So now let's see how it looks in our-- oh, the other thing I want to say about this method is for demo purposes, if the basic user logs in, the one that has the username user, that person speaks English. So we won't localize their strings. If the advanced user logs in, the admin user, that person speaks Spanish. So we will localize their strings. So let's look at the application. So we log out. Let's log in as user.

We are executing or localizing code, but we're deciding that this person speaks English. So we say, remember, we're using the name configuration. We see title, description, project. We log out. We log in as admin. And there we have our page with the names of the properties in Spanish. Okay? So, quick review of, can you log out Ernest? Quick review of what we accomplished with these three demos. First, you gave us a model.

We gave you a full-fledged running database application. There it is. You logged in. You have all these pages you don't have to write for edits, for lists, for queries. Those are there for you. Can you go to the list page? You weren't happy with the pages we gave you from the HTML point of view? You changed it.

You weren't happy with the pages we gave you at the property level? You plugged in your own component. Can you log out? Can you log in as user? You wanted to reuse one page in two different configurations? You defined the named configuration and you have a simple and an advanced query configuration.

Can you log out? You wanted to localize your application and take advantage of the rules of the rule system? You define your own little, you have your localized code somewhere, you define one rule to resolve the property names in this page, and you have a localized page. Okay? That's the end of our Direct to Web demo.

Now that was a very simple, I mean, non-flashy demo. I didn't want to distract from the essence of where the hooks were for you as developers. So at this time, I'd like to bring up on stage Patrice Gautier to show you... How he has used Direct to Web to solve a real world problem in a deployed and currently running application. Thanks Miguel. Good afternoon.

So I just want to spend a few minutes and share with you the absolutely tremendous success we're having with Direct to Web. First thing I'd like to explain is what we do in one slide. We're in the business of providing business to business infrastructure for real estate for large companies. So we have customers like Bank of America, Prudential, IBM, and so on. And we provide them with a mean of basically finding landlords, engaging them, negotiating, closing lease and contracts online.

The process is long and complex, typically three to six months. And it's made complex because there's a lot of actors touching this process. You have the real estate department of these companies. You have brokers, agents, service providers, lawyers, architects, and so on. They all do something at some point in the process.

So when we model this, we end up with a pretty large set of EOs, something like 300. So as a developer, when you start to deal with that volume of data, you should be very scared, because that means a lot of code for you to write and maintain.

We have three production applications and they have 700 unique pages in them. We also have internal applications. So what we decided to do, seeing this volume, is we decided to base almost all of our pages on Direct to Web. Something like 95% at the moment is using the very same pages or extended version of these that Miguel showed you.

We have about 2200 rules, but only 18 templates. A lot of our pages come from these templates, about 95%. And what that means is we spend our time mostly doing two things: writing business logic, writing little custom components like the component that was shortening the string that Miguel showed you, and doing rules, only three per page. And basically the upshot of all this is that we're able to achieve a tremendous volume of functionality with very few people and a lot less time than our competitors.

So I have a few screenshots to show you. I hope that they're big enough for you to see. This is an example of List Page. This is a Direct to Web List Page. You can see that it looks nothing like what Miguel had. It has custom navigation. Everything you see on this page pretty much is driven by rules, from the state of the navigation, the strings you see on the screen, all the names, even the number of items shown per page, and so on.

Here's a more interesting page. We've added the wizard creation page, which is a stepped wizard. And we've added a few features to the standard Direct to Web inspect or edit page. You can notice, if you can see them, that some of the fields have stars on their left, which means that they're mandatory.

One really interesting characteristic of Direct to Web pages is that they know what property of the model they're displaying. And so they have access to a lot of information that is not typically accessible to a Direct to Web page. They know, for example, if a property is mandatory because the model contains that information. So it's just a matter of automatically displaying a star whenever that is the case. And that is done automatically. You don't have anything to do.

Another thing you can notice is that some of these fields have units on their right. That is worth spending a minute explaining how that works because it goes at the very heart of the role power. What happened is when we had this app at the beginning, it didn't have any of these units and everybody started coming back to us and said, "Well, we don't know what parking space is expressed as because sometimes it's a ratio, sometimes it's a number spot that you really have to have units." So we started thinking about how can we integrate this with the Direct to Web page? And the answer turns out to be really simple. We've done three things.

The first thing we did is add an entry in the user info dictionary of whatever property we're talking about. For example, parking spaces, we would say spaces in the user info dictionary in the model. Then we add one component that is able to look up that property and display it on the right of the text field.

And then we add exactly one rule that says, "If on the property you're displaying, you find a unit in the user info dictionary, then use my unit component." And with that one rule, units show up throughout the app, throughout 700 pages. So you can imagine if you start expanding on that, the amount of time you're able to save.

Other things of interest on this page, notice that we've also completely changed the way validation works. All the errors are collected at the top and displayed in an English format. Here is an edit tab page. Again, we've changed the way it works. We've added sections. I don't know if you can see them, but there's three tabs and two sections in that tab.

Here's a tab and spec page much the same as the other. What I want to show you on this page is how the help system works. Again, Direct Web doesn't come with a ton of help. And you can see here we have two kinds of help. We have the little eye buttons that are next to each field. And that works the same way as the unit. Basically, what we did is create a help database and let our tech writer access that database through, of course, a Direct Web application.

So he or she accesses that database and creates a help entry for the size range of a project, for example, described by this. That bit of text is stored in a database. When the app runs, again, because it knows what property it's displaying, it's able to look up that bit of text and display it behind the eye button. If you press the eye button, a little JavaScript window will pop up with the help. And because it knows that it's attached to that property, wherever that property shows up in the app, the help will be there. You don't have to do anything.

And similarly, the help that you see on top of the window comes from the database. And our tech writers actually have the ability to edit the help on the Direct to Web app and to see the result of your edit live on the app. I don't know how many of you have to deal with web design teams or tech writer teams, but typically that is not what happens. You have to ask them for help files, integrate them in the app, and then have them later look at the result. Here they can do it live. That's a very big advantage.

And here's a slightly more complex page. This is a tab page, and it has two pick lists in them. This is the page that we use to engage or reject responses. Just to see that you can actually nest Direct to Web pages within Direct to Web pages, you have three in this page.

So I hope by those few examples, I've shown you two things. A, Direct to Web is not a toy. It can scale to very large amounts of data. If you use it properly, it will be a tremendous tool to save time and effort. To give you a point of reference, the seven apps that I mentioned at the beginning were developed by about four to six people over one year. Our competitors doing the same type of functionality have teams between 30 and 80 people.

And one last thing I want to mention, if you missed the Stepwise announcement on Tuesday, we are open sourcing four of the base frameworks that are used in those apps. You can find them on our website. I've posted the URL on Omni and Stepwise. Thank you. Back to Miguel. Oops. Thanks, Patrice. Thank you.

So in summary, Direct to Web integrates into the Web Objects Development Model. This isn't any new strange technology that you have to have a huge learning curve for. You already know a lot of what you have to know by being Web Objects Developers. We give you a head start with a lot of pre-built functionality. We give you an application for free.

The default layout and behavior can be customized. That was the main point of the session. You have a lot of places where you can plug in your HTML and your code as developers. Rules introduce a new level of customization for your Direct to Web applications. So think Java, but also think a higher MEDA level there in the way you develop your applications. And of course, Direct to Web rules.

So there's our lab hours. I believe tomorrow is the last day, only half day, up to 3:30. Interesting sessions coming up in this room, an advanced talk on EOF. After that, in the same room, the session on advanced Java client, which uses the same rule engine of Direct to Web, but provides a Java front end to your applications, and the feedback forum tomorrow. Contact information.