Enterprise IT • 55:59
With the powerful WebObjects model- and rule-based development tools, entire applications can be generated in minutes without writing any code. This session shows how to rapidly build web, web service, and Java desktop applications, and how to customize and extend these applications.
Speakers: Miguel Sanchez, Brent Shank
Unlisted on Apple Developer site
Transcript
This transcript was generated using Whisper, it has known transcription errors. We are working on an improved version.
My name is Miguel Sanchez. I'll be doing the first half of the presentation, and then we'll have our star documentation writer, Brent Shank, come up and do the second half. So, if you're in this presentation, I hope you're interested, one, in WebObjects, and two, that you want to learn how to quickly develop your applications. How quickly? Well, the most optimistic developers here in the crowd would probably want something like this.
You want a magic button that says, build my application, and then you press that magic button, and then you get your WebObjects application. And if you saw the demos, how many of you were here yesterday for the tech overview? So, you'll see some of the demos, well, a lot deeper in this session, but you'll see, you know that we get pretty close to this kind of rapid development.
So we're going to teach you several things. The main is how to get- how to build WebObjects applications within minutes or within seconds, if you have a very fast compile machine. But now, you guys- you're all developers, so I can't hide things from you. You know that it's not that easy. I mean, you're ultimately here to type code at some point. So the meat of the application is to teach you how to do the incremental customization of your WebObjects applications until you get your final deployment app.
And the underlying methodology we're trying to bring across during this session is, one, a way of developing your application that is more data-driven and rule-driven, and in which you can use your traditional WebObjects techniques, but you're writing less code, yet you're achieving a lot more. So that's what we want to get across to you guys.
You might have heard the term "direct to star." That's another way of referring to the WebObjects, the rapid development technologies. WebObjects has three main kinds of applications that you can develop. You have the traditional HTML WebObjects front-end application, a swing application, and web service applications. Each one of these stacks has its set of tools and frameworks, which we call "direct to something." We have the direct-to-web technologies, the direct-to-Java client, and the direct-to-web services. This presentation is about that whole last row, all the direct-to-star technologies.
So rapid development is not one particular application. There's no magic button like I showed you. There's a project builder system, but there's no rapid development application anywhere. Think of it as a set of tools and frameworks that help you build your applications faster. How do we achieve this? The main thing we give you is a lot of pre-built functionality and default application behavior. So there's a lot of stuff pre-built for you. We also execute the application in a slightly different way than your traditional WebObjects application.
We rely a lot more on your data and a description of your data that you give us to make decisions at runtime and help you write less code. And it's also a common process used across the three kinds of WebObjects applications like you saw on the last slide.
The very, very high level view of how you develop applications using rapid development is what we ask from you is a description of your data. We want you guys to tell us, "This is my data. These are the tables I'm working with." We're not psychic yet, but we're working on that one. And then we get a description of your data, you give it to us, and right away we give you a default application running within seconds if you have a G5.
But then you come in, right? I mean, you're developers. You're being paid to write the code, and you want to customize your application to fit your needs. So you're going to go through several steps of iterating until you get your final application. Okay? Now some- let me go back one.
Now some people- Don't think that the first application we give you is very important, because it comes up on the screen very quickly. The important thing to note about that application is that you have a running application from the very start of your project. And those of you that use some sort of agile process development or extreme programming, you guys know how important it is to have something in a running state to get the immediate feedback and your customers.
We give you a default application, and it's a very important default application. It might not look exactly like the application you ultimately want, but it's running. And as you customize, you customize and it's always running. And that is a very, very big benefit you guys get out of using the rapid development technologies.
So we said, what we want from you guys is a description of your data model. This is the common denominator in all of the rapid development technologies. We assume that the data you're handling can be represented in some sort of entity relationship mapping. And we also assume that what you want to do with your data are things like inserting, deleting, searching, listing, editing. So that's what we're good for. If you're doing some major statistical analysis or other kinds of stuff, we don't really help you that much.
How do you give us a description of your data? For this, you use something called an EO model, and those of you that are familiar with EOF, this is what EOF is. For example, you would have your data in a database. Here's a company database. But you know that one of the benefits of WebObjects is to keep you away from the database. I mean, you want to ultimately use your Java objects. So there has to be some sort of mapping definition between those two worlds.
And you're probably going to have more tables, and there's going to be more objects, and you have to tell us how they map. And there's- more importantly, there's going to be relationships between objects, which exist at the database level as foreign keys and source keys. But in your object graph, you just want to call a company method and then to get back an instance of the company class.
So the mapping stuff, that is your data definition. And that's what we need from you. And we provide tools to help you build this quickly. So if you give us an EO model, for those of you that are more familiar with EOF, if you give us an EO model, we can give you a lot of functionality. You need to give us an EO model.
Now let's jump right in and introduce the example we'll be using throughout the whole presentation. I know that Finding Nemo is a good movie, but I have preferences for another animated movie, the Star Wars series. And over the years, I've been collecting a bunch of Star Wars plastic.
Star Wars collection, little action figures, you've probably seen them in the stores. So, memorabilia like magazines and stuff. So this is my data set, right? We're going to build an application that allows me to manage my Star Wars collection database. Does anybody else collect Star Wars toys here? Okay. Well, there's two geeks in this room there.
So that's my data set. I have a database that represents my collection. So I have tables for an item. The item table represents- and each row in the item table is one of the toys I have. The items represent characters in the movie, so I have a character table with the normal character names that you are familiar with.
Characters are categorized. Are they humanoids? Are they droids? For my purposes, I also consider ships to be characters. They appeared in a particular movie, and they showed up at the stores in a particular toy line. The toy line refers just to the kind of packaging they came in, and how much they cost sometimes. So with that, I'm going to bring up Brent. So that's my data set.
Like I said, what we ask- so now I'm playing the role of the developer. I have to give WebObjects a description of my dataset. Let me just show you that I already have a pre-existing database. It's an open-based database. There's my data. So you would have some of your data. If you don't have data, you would probably have a database that you want to eventually use.
So you would have just your simple table definitions, even if there's no data in it. So you have your data. Then we use this tool called EOModeler. This is where we start seeing rapid development, right? It's called EOModeler, but parts of EOModeler are rapid development. What we do here is we say, give us a connection to your database.
And we ask an- we answer a set of default questions, and we click finish. And we create a default mapping for you. So you don't have to go in and create all of this- all of this EO model entities. We give you the default mapping that we think. We just go in, read your database schema, and create an EO model. So for our purposes, that's it. I mean, this is all what we- all we want to do.
And then, this is the entity relationship view of the model. So what do you- what the tool did was, for each table, we saw that you had- we created an entity. And for each column in that table, we created an attribute. So that's our mapping. Okay, we're going to save the model.
And then we go to Project Builder, and we create one of the project types. We're going to be using Direct-to-Web for this first demo. So one of the project types we have is a Direct-to-Web project type. Just call it anything. The main thing you have to keep in mind when you're creating a direct-to-web project type is, all we need to know is, what is your model? And that's the step where Brent said, this is my model, which we just saved. This is the part where we create the application for you in seconds. So we click Next, Finish.
And it's compiling. If we go through the project, we haven't generated any code for you other than the default stult files that are required in WebObjects applications. It's compiling in the background. Brent is changing the font so you guys can see the code. We're launching. And we have a running application. Okay? So this is- you saw this yesterday. We're going to log in.
We have a query page where we can search on all of the entities we have in our database. We're going to go to the first one, the characters. So we look. We get a list of all the characters in my database. If we want to edit a particular character, we click on the edit page. We go to the edit page. Let's go back to the home page. If we want to see all the pictures in my database, go to the photos.
So those are some of the pictures I have in my database of the toys I have. So that's rapid development. You have a fully running WebObjects application. So that's the part we give you at the start. Great. But that's not what I want it to look like. So let's start customizing it. Let's go back to home first. And let's do a very basic customization. We go to the item list page.
And edit, edit item first. Just click on any one of those items. So we have the edit page for the item for each one of the toys, and we give you all the default fields we figured out you had in your database. But you don't want to show all of them. You only want to show three. You only want to show the name of the item, the movie it came from, and the condition that the toy is in.
So what we do is we click- Brent just clicked on that button on the left that said customize. We bring up a little Java applet that allows you to hide and remove fields. So what he's going to do is he's going to say, I don't want to show all of those two, four, six, eight fields.
I only want to show seven fields. So he goes into the applet, and he gets rid of all of them other than the name of the item, the movie, and the condition that the toy is in. Now watch this. We haven't written any code, no recompiling, nothing. We click Update in the applet.
The request goes to the server, the page refreshes, and you see your change. So that's also something that we're going to be talking a lot more about in rapid development. You see your changes right away. This was a very basic customization, but there would be more complex customizations, and your application is always running.
Now let's just look at the project. For those of you that haven't seen, I'm sure that most of you have probably seen Direct-to-Web, but for those of you that haven't seen Direct-to-Web, I just want to point out that this is not blind code generation. We don't have any files in your project that generate those HTML pages for you. We're doing that all dynamically on the fly, behind the scenes. So this is not blind code generation. So that's the end of the first demo. Thanks, Brent. Back to slides, please.
So we just showed you what Direct2Web is. Direct2Web is a set of frameworks and tools that allow you to quickly create HTML WebObjects applications. That was the first column in that slide I showed you at the start. Okay? We do that by giving you a lot of pre-built page templates.
And we're driven by the description of your model, data-driven, and we're also driven by a bunch of rules which we have to make decisions at runtime, so we're rule-driven. But ultimately, you can customize your applications however you want. What kind of page templates do we give you? We have the Query All Page Template, which is automatically configured to show all of the tables you have in your model.
Once you click on a particular search, we have a list page template where we show you all the page results. It doesn't show you on this slide, but it's a multi-page search. So if you have a lot of results, you can paginate through them and see all of your results. We have an edit relationship page, where you want to associate one object with another. We have the edit page.
Some pages have more than one look to them. For example, here we have the simple edit page, where we just have the fields laid out. But we also have the tab edit page, where you can hide some fields in certain tabs. So that's at the page level. At the property level, you have all kinds of properties. You have dates, numbers, strings. So we have a lot of property level components.
For example, here I'm showing you five different kinds. We have a normal text field, a hyperlink, a little embedded browser, a collapsible component where it says four characters, a matrix of buttons. So we give you a lot of pages, and we give you a lot of property level components. And you can combine them and use them how you want. So that's how we achieve making things faster for you.
So we have these pages. Now you might be wondering, "Okay, you have these templates pre-built for us, but at what point do you decide what to show on them? How do you actually configure them on the fly?" For that, we use the rule system. Okay, we make decisions on the fly to show exactly the fields that are relevant to the database that you're handling. So think of the rule system as a basic expert system. It's a question and answer system.
You give it a state, you tell it, "This is where I am, this is what I'm doing, and I want to know certain things about the current state." Okay? To get to that, it searches a collection of rules. It's also a recursive system, so it might find several rules along the way before it ultimately gets the result you want. And I'm talking about it here in the direct-to-web session, but it's the same rule system that is used across all kinds of rapid development applications.
Rule system manages rules. What's a rule? A rule, in its simplest form, is something like this. We have a condition, which is pretty much the thing that has to be true for the rule to be valid. The condition is just a qualifier. It says here, well, this rule is valid when the task is list and the entity you're handling is moving. And then we have a right-hand side, which is the value of the rule, which is the thing you can derive, you can deduce, the knowledge you want to encapsulate.
Let's give you a more detailed example. How did we get to configure this page with the rule system? We have a template in the Direct Web Framework that lists all of the rows. How do we know that you want those two particular rows, that you want the long name of the movie and the short name of the movie? We first initialize the state that we're in.
For that, we use an instance of a class called D2WContext. Think of it as a dictionary for now. And 90% of the time, you don't even need to be handling a D2WContext directly. So this is just for-- so you understand the behind the scenes of what's happening in the rule system. We initialize a context. We say, the current task we're executing is listing, and the current entity we're dealing with is a movie.
And what we want to know is what fields we have to display in the columns. We feed that context into the rule system. The rule system searches through its rule database, firing other rules along the way. But it ultimately comes to something like this. And it says, if the task is list and the entity is movie, then the display fields are the long name and the short name of the movie. and he gives you back that result. And once we have that result, we can use that in our page templates to configure your page.
[Transcript missing]
A more direct way of accessing the rule system, or accessing the rule databases, by using an application called Rule Editor. Rules are- don't be overwhelmed by rules. Rules are property lists. You can open up a rule file and it's a text file. The Rule Editor is a nice way of displaying those rules as property lists.
If you open up a rule file, you get to see all of your rules at the top. You click on one, and then for a particular rule you select, you see the qualifier part of your rule, and then the value part of the rule, the value you can derive. So these are two ways of accessing the rule system.
The rule system is the main thing that you use to customize your app, even though you might use it indirectly. You also customize your app by changing your data model, because we're relying on the description of your data to see which things we describe, we put on the screen. So if you put more stuff in your model, we put more stuff in your page.
You can add custom rules to configure further. And this is where it starts getting interesting now. You can start, you can plug in your own custom widgets if you don't like the ones that we provide for you. And you can transition into more, into more traditional WebObjects techniques.
But there's a cost, right? Nothing comes for free, right? We can't give you all the magic and then have you all do all your magic and all that happen at the same time. So just be aware of this equation. We're doing all of these decisions for you at runtime.
We're trying to be smart about your model and your rule, and we have control of the page template. So the more you want for us to give you that control, the less we can do for you, okay? So the more dynamic your application is, the page templates live in our room. If you want more access to those templates, we can give it to you.
But at that point, you're writing your own code, you're writing your own HTML, and it's harder for us to make decisions at runtime. So the more you customize, the less dynamic, you lose some dynamic flexibility in your application. So the rule of thumb here is that your application is probably going to contain dozens and dozens of pages. So don't be eager to get access to the HTML and to the Java right away. Only customize.
Don't only write code in the parts that you really are hitting a wall with the stuff we give you. Leave the other stuff alone, and then little by little customize the pages. So you'll get a lot of benefit out of that. Now let me summarize the direct-to-web process. To get an initial application, you use your modeler.
You create your definition of your data, you get a model, you feed that model into Project Builder, and you get a default application within one minute. How do you start customizing it? You use the Direct-to-Web Assistant, which is the applet that runs alongside your app. Or you can write more rules in the rule editor, or you can refine your model and we take, we pick up those changes, or you can do some basic HTML changes. And then your app starts looking a little more like what you wanted. We're going to do this in a minute. And then you can do fairly advanced customization. You can write your own custom HTML WebObjects components to plug in our pages.
You can write more sophisticated rules. Or ultimately, you can get the full access to the page template that we're using to generate it. So we give you everything. There's your Java, there's your HTML, you deal with it now. Okay? So at that point, you get the application that you want. Let's demo this in our second demo. So I'm going to ask for Brent to help me out again.
You might quit the browser first, so we can restart from this one. So what we're going to do is we're going to start out with the application we just created, and we're going to get a little more sophisticated with our widgets. For that, some of the code we'll be using in the second demo was pre-built because that's my code, like it would be your code in your own custom application. And it lives in a framework. Right now it's a very simple framework, it's just for demo purposes. It contains things like an image which I'm going to include into my application, and a little custom component. So it's a framework.
Now let's go back, hide that framework, and create a new project, a new Direct Web project. We're going to be doing the same thing. The only reason we're doing it again, and we're not starting from that project we just showed you in the first demo, is we wanted you to be aware of this step. And this- Brent is not going to specify which model we're using. He's instead going to be specifying which framework he wants to add to the default Direct Web application. And the framework contains the model, so we're going to pick it up automatically.
So everything here is very similar. He's just going by creating a Direct Web application. The only difference is that he also said that he wants to link in this additional framework. So we're linking the framework, but initially we're not doing anything with the framework. So the application should look the same. We're not generating any code yet. It's launching right now.
The only thing that we have in our project is the reference to- oh no, that's in the framework now, we can't show you that in our project. This is the same application that we had before. We just got to it in a slightly different way. We'll navigate around. Okay.
First thing, very simple thing you might want to change is the overall look of all of your pages. We give you a blue bar along the left-hand side. Maybe blue is not your favorite color, maybe you want to do something else. So let's do a very simple thing.
Let's change the look of all the pages by adding a banner that says Star Wars along the top, because this is my Star Wars Collection application. One of the components you have in your project is called the Page Wrapper. The Page Wrapper specifies the overall look and layout of all of your pages. In this case, it says there's a blue bar, there's a menu that always shows up on the left, and then the content shows up on the right.
So we always want this banner to show up at the very top. So what Brent is going to do is he's going to go ahead and add a new banner. is he's going to add an image component at the very top. And he's just going to say, I want this image, the image Star Wars banner, which is a resource in my framework, to show up. It's a resource in the rapid development framework.
This is another part where rapid development comes into play. We're not doing any code, we're not doing any recompiles, all he's doing is changing the HTML and saving. But WebObjects has something called rapid turnaround, and all he has to do is refresh the page and we pick up the banner.
So now that he navigates around, we have- the banner follows him around, okay? It's a very simple HTML page, but I'm sure all of you have some sort of graphic designer or something that- or a group like that in your companies where they want you to have the particular look of the company, so you have access to the overall layout. Now let's do something more interesting. Let's go to the list page for the item.
Is this the list page for the item? Yeah. So by default we're showing you the name of the item, the secondary name of the item, the notes on the item, but you know, this is, I mean, the coolness about this application is that you see the images. So I want to show the images here.
So let's add the image column to this list page. So I already have a primary photo data method in one of my objects. I just added using the Web Assistant, and I click update, and now I'm adding, I have all of the default columns we had plus the image column, okay? So we have a default, we have the default image implementation.
That's great, but you know what? This default implementation isn't very good. It's the, we, the images are kind of big, and the image takes one whole column, and the way I want to develop my application, I want all of those four columns, one, two, three, four, to be collapsed into one column, and I want the layout a little different.
So I want the image on my left, and then right alongside the image, I want the four fields of the thing. We don't give you that in Direct to Web, okay? That's not a problem because you can write your own custom component and plug it into the application.
We already wrote this custom component. It's in our framework. It doesn't do much. We just didn't write it at this moment to not have any typing mistakes, but it's a very simple component. It's going to show you the image on the left. And the four fields that we were showing as columns right next to the image. Show the bindings.
When you write a custom component, what you have to be aware of is that we- Direct2Web is going to give you two things: the object that we want you to render, and the key that we want you to render. So you're going to get those two variables in.
And once you know that those two things exist, you can do whatever you want in your code and associate the bindings. Now how do you use it in your application? This component is already pre-built, pre-compiled. Now what Brent does is- He adds, he removes all of the columns and leaves only one particular column.
And then look at that, the pop-up he's going to click on. The very last entry in the pop-up is, "I want to use my own custom component." So he clicks custom component, you type in the name of your component, and it's your formatted item component. We click update.
And there's your custom component. So it's a very simple component in this case, but you might want to have more sophisticated things. I just wanted to show you guys how to plug in your own HTML. This is one of those places where you're plugging in your thing, you're plugging in your HTML and your little snippet of Java code, but you're not getting full access to the page.
So it's still dynamic. You can still add columns to that page using the web assistant, so you're not getting full access. Let's say that you ultimately get to the point where this page, you want it to be a lot more sophisticated, and you just want full access to that Java and that HTML. For that, you go to the Expert setting.
In direct to in the web assistant, and one of the options there is freeze component. Every time you see the word freeze, we mean give me access to the Java and the HTML. So you freeze the component, we go back to the project, And you see that we generated all of this code for you.
And put it in your project. So now you have full access to the list page. You have all of the HTML, you have all of the Java, but now it's yours. Now notice that we only froze the list page. If we go to the edit page or if we go somewhere else, we can still use the Web Assistant and configure our application there. But the list page, because we reached the limits of direct-to-web, we wanted full access to it.
So it's not blind code generation. And that's all, that's it for this demo. So if we go back to slides. So that's the end of the direct web section. Now I'll bring Brent up to actually speak. Sorry. And he'll do the Java client part of the talk. Thanks, Miguel.
Well, Direct Web is great because we can get HTML applications without writing hardly any code. But when we want to get customized the application, we can write code, and we can have access to all the HTML and Java that we need. But HTML interfaces are great, but sometimes you need a little bit more. Sometimes you need a desktop interface. Sometimes you want a richer UI, something that allows your users to browse their data more quickly and in a different kind of way. And for that, WebObjects provides a technology called Java Client.
So before we talk about direct-to-Java Client, let's talk about Java Client. So just like direct-to-web builds on the HTML frameworks and tools that WebObjects provides, direct-to-Java Client builds on top of the Java Client technologies. So let's go back for a moment to our most optimistic idea of what rapid development is. So just like in direct-to-web, it would be great if we could have an application on the system that just said, build my application. But rather than building a web application, an HTML application, it could build a web application.
So we can get you pretty close to this, just like we do in direct-to-web. So let's step back. So what is Java Client? Well, Java Client allows you to build distributed applications, applications that you distribute over the web. These are three-tier applications that include a WebObjects application server in the middle, and the WebObjects app server accesses the database through the Enterprise Objects framework.
And like I said, these are swing desktop applications that you can build on the system. So you can build a web application on the system that you're using, and you can build a web application on the system that you're using. And you can build a web application on the system that you're using, and you can build a web application on the system that you're using. So these are the three-tier applications that users use, just like any other application on their system.
But what this adds up to are multi-platform EOF applications. So this is one of the huge advantages of having EOF in Java. So rather than be limited to one platform, you have available to you any Java 2 platform to deploy the client application. Of course, the middle tier, the app server, accesses the database using EOF. And because we have this app server, it can control and mediate all access to the data store.
So in a two-tier client server application, in which the client has direct access to the database, you don't have as many opportunities to secure that data. But in a three-tier setup, you have all the control you need. And because it's a WebObjects application server, you have the full support of WebObjects sessions, so you can provide users a customized experience, even within these swing desktop apps.
And of course, these applications, you can bundle them as double-clickable applications or deploy them through Java Web Start. So that's what Java Client is. So what does Direct to Java Client add on top of that? Well, just like Direct to Web allows you to build HTML web applications quickly, Direct to Java Client allows you to build swing applications quickly. Again, both of these technologies share a lot of characteristics. They're both data and rule-driven. But unlike Direct to Web, which uses components and dynamic versions of WebObjects components to generate HTML, Direct to Java Client uses something we call controllers to generate swing.
: It relies on the rule system to generate the user interface. So just like you saw Miguel go through how the rule system works and how it figures out how to generate a particular page, Java Client does this the same way. It uses the same rule system and the same set of rules, but it produces a swing interface instead.
Miguel Sanchez : And just like Direct Web has a number of different tasks for editing data, for editing relationships and traversing relationships, Java Client also has multiple tasks. And Java Client introduces some new tasks that are specific and more appropriate to desktop applications. We're going to talk about some of those. And just like with Direct Web, Direct to Java Client has many customization techniques. So if the default app isn't exactly what you want, we provide you a lot of interesting ways to customize the application.
So again, this helps you change your development focus, allows you to write to focus on the important things, which are your business logic. The important things in writing a desktop swing app is not writing the swing. It's something that has to be done. It can be a buggy process, but we take care of it for you, so you can focus on the most important part of your application, which is the business logic.
Miguel Sanchez, Brent Shank So we're going to be working on a lot of different things. We're going to be working on a lot of different things. We're going to be working on a lot of different things. We're going to be working on a lot of different things. And just like with DirectWeb, you can get a working prototype, fully functional in minutes or seconds. And I say in hours, because my idea of a Java client prototype is something that is really fully functional, that even can include a very rich login panel.
And we provide frameworks to do all of that, so you can have a really functional prototype in hours. Miguel Sanchez, Brent Shank So we're going to be working on a lot of different things. We're going to be working on a lot of different things. We're going to be working on a lot of different things. And part of this development focus is that we allow you to have a complete working application throughout the whole lifecycle of the app.
Okay, so let's review the direct-to-Java client process. It's very similar to the direct-to-web process. It all starts with a data model. You use EOModeler to create that data model. You use Project Builder to create the default application. But what you get instead is a swing application. Customization techniques.
Just like Direct Web has an assistant that allows, which is a front end to the rule system, allows you to customize the application, we provide something called the Direct-to-Java Client Assistant. So this is actually an application, a swing application, that runs inside of the client application and allows you to make customizations on the fly without writing any code.
If you really get comfortable with the rule system, you can actually write your own rules in a rule editor, just like you can with direct web. And in the course of customizing React, you may find that you need to refine your EO model. Maybe you need to add some attributes to an entity, or maybe you want to make a relationship that was a 2-1 and too many. And you can do that. In most cases, we synchronize the changes you make in your EO model, and because we're doing dynamic user interface generation, you see those changes reflected right away.
So, Direct to Java Client has some advanced customization techniques. So I talked briefly about the idea of a controller class. The controller class is analogous to a WoE component. And just like you can freeze and extend and write your own WoE components and D2W components for Direct to Web applications, you can write and extend controller classes in Java Client. So if you want total control over a particular user interface in the Java Client application, we allow you to do that.
An interesting feature of Java Client is that you can actually use Interface Builder, the same application that you used to build Mac OS X, Carbon, and Cocoa UIs, to build static swing interfaces. So we actually write out swing classes for you, and you can integrate these swing classes into your Direct-to-Java Client application.
And when you do this, it doesn't mean that your whole application suddenly becomes full of these static swing classes. You can target just a particular part, a particular window of your application, so you get the best of both worlds. You get the dynamic functionality of Direct-to-Java Client, but in some cases where you need precise, exact control over the layout of a UI, you can get that too.
If you want to get really fancy with the rule system, you can start to write your own custom assignment classes. We talked a little bit in the technical overview yesterday about inheritance in EOF, which allows you to think about your data in object-oriented terms. Well, you can actually extend the rule system. This is something that I've done to provide some support for inheritance in the rule system.
So, in the end, you can get a Java client interface that looks nothing like what you get out of the box for free from us, but by writing a little swing and by learning about the rule system, you can get the exact interface you want. And we're actually going to build this one that you see on the screen.
Okay, so these controllers are very important, so they warrant a couple slides of their own. Like I said, they're analogous to WoW components, and they really implement client functionality. And they do this because they're the glue between your business objects, between your data, and between the user interface. So they look at the description of your data that you provide us in your EO model. This can be the same EO model that you use in a direct-to-web application, or even in a traditional WebObjects application of any type.
So by looking at your EO model, different types of controllers are responsible and generate different parts of the client application. So there are four main types of controllers. There are application-level controllers, which are responsible for bootstrapping the client application, and are responsible for getting all the other controllers up and running.
There are user interface-level controllers, which are responsible for knowing how to draw windows or modal dialogues. And there are entity-level controllers, which look at the entities defined in your model and create an appropriate user interface for them. And there are property level controllers, which usually are expressed in the client as a particular widget, whether it's a text field, a text area, or an image view. And these correspond to the attributes in your data model.
So these controllers work together to form a hierarchy, and this hierarchy provides the complete description of the client application and of each user interface within the client application. And we'll look at the director of Java Client Assistant, which actually will show you the controller hierarchy throughout your application. So this is a very abstract view of what the controller hierarchy is.
So we see that this particular hierarchy is enclosed by window tags. And these aren't the actual tags, it's just abstract for our purposes here. So that window is encompassed by window tags. It also includes an action button controller, which is responsible for drawing the toolbar, and a tab view controller, which is responsible for drawing the tabs. So you don't really need to worry about the details of this right now, but if you're curious about how we build up this interface and the components behind it, we use controllers in this controller hierarchy.
Okay, so, well, how does all of this happen? This is kind of a complicated slide, but I'm sure some of you are interested. So the client application starts up, and it needs to generate a user interface. So how does it do this? Well, it relies on an object called the controller factory. So it says to the controller factory, give me a window for something. It could be for a particular entity, or it could be a controller for a particular widget.
Well, the controller factory knows how to do a lot of things, but it needs to rely on the rule system for a lot of the information. So it sends a request to the rule system. Now, the rule system lives on the server, and it lives on the server because your EO models and your rule files live on the server, and it's mainly for security and performance reasons. So now you have a sense of where these objects lie on the client-server divide. So the rule system, then, is contacted by the controller factory.
And it may need to consult your rule models and your data models for more information. So it packages an XML description of these controllers, and it hands it back to the controller factory. And then the controller factory is responsible for creating this hierarchy that we talked about before. And in the end, what you get is a user interface in your application. So this is all described in the documentation. Again, you don't really need to know about it, but it gives you a sense of all of the work that's going on behind the scenes.
So I said there are a number of customization techniques in Direct to Java Client, and let's go over them now. So there's the Assistant, and the Assistant is a very high-level customization technique, and it's very low cost. And these are listed roughly in order of cost. The more you customize your application and the more advanced technique you use, just like with Direct to Web, you lose a lot of the dynamic flexibility.
Now the nice part is, you can make the decisions about- you can choose a customization technique on an interface-by-interface level. So you don't have to say, "Well, I want to freeze the XML controllers for my whole application." No, you can say, "This one window is really important, and I need to have total control over this particular window." So you freeze the XML for that window.
So let's go through these. You can write your own custom rules, like I said, in Rule Editor. You can extend controller classes. So all of the windows you see on the screen are back. They're backed by a controller class. And if you want to tweak the functionality of a particular window, you can simply subclass one of these controller classes and provide that custom functionality. And like I alluded to, you can actually freeze the descriptions of these controllers and edit the tags manually if you want.
And you can use Interface Builder, of course, to build static interfaces. And you can actually interact programmatically with this ControllerFactory object. So behind the scenes in a running application, the ControllerFactory is constantly being talked to, and the application is constantly making requests to it. But you may want to do that programmatically. It's a very powerful way to get a particular interface.
And of course, you can write your own controller classes. And we're going to show you, I think, all of these customization techniques in this demo.
[Transcript missing]
I'm going to start a new application. I'm going to use the same model that we used in the HTML, the Direct Web application. So I'm going to select Direct to Java Client.
I'm just going to take the defaults for now. And I'm going to select the same model, like I said. And you notice this WebStart pane here. These allow you to configure the parameters for the JNLP file that we dynamically generate for you that allows you- provides the client application without you having to do anything more about it. So I'm going to build and launch the application. And while that's building and launching, let's just look at what Project Builder created for me.
So this project template is actually simpler than the direct-to-web project that we created. It contains just the classes that WebObjects needs to bootstrap a Java client application. So there are two web components. You see in our resources we have the Star Wars model and one of these rule models. But there's really- we're not doing code generation as Miguel said. It's all happening on the fly. This is going to start up. And you see, rather than starting in a browser, we have this swing application.
Okay, we'll figure that out in a second. And it has a number of interesting features. So I can search for items in Miguel's collection, and I get the results back here. I can drill down and look at the form of one of these. But one of the best things you get for free is undo and redo. So I'm just going to change a couple things here. I'm going to change item name and save it. I'm going to select a different condition for the item.
Miguel Sanchez, Brent Shank And I'm going to select a different movie. Now, Miguel's not going to like that I'm doing this, but because we have full undo and redo, it's not going to matter. So I'm going to undo what I just did. So you notice that episode three changed back to episode five, and the condition changed back to what it was, and the item name changed back. So you get all of this for free. And yes, you can write your own undo managers and things like that, but why do it when we do it for you? So that's one of the best features of Java Client.
Miguel Sanchez, Brent Shank So let's look for a minute at the Assistant, since it's the first customization tool. And the first pane I want to draw your attention to is the XML pane. And the XML pane allows you to view what we call the specifications, and these are the controller hierarchies for each of the user interfaces in your application. Miguel Sanchez, Brent Shank So let's look at this item form window. So this is a form window for an item record. And I identify that over here.
And we can see, just like you saw on the abstract slide about the controller hierarchy, We see that it's enclosed by this frame controller, which corresponds to the window tag on that slide. And we have this actions button controller that corresponds to the action buttons. So in the Save to File button here is one way that you can get a hold of this XML if you want to customize it and move things around, if you want to do things that the Assistant doesn't allow you to do. Now, we encourage you to use the Assistant to make all the customizations that you possibly can in it, and then to move on to the other customization techniques.
So let's customize this app. So it's nice seeing the results of my search in this table view here, but I really want to see the photos of these items, just like I did in the Direct Web app. Well, how do I do that? Well, I actually wrote a framework that provides this custom functionality, and I'm going to add it to the project. And then we're going to go through, and I'm going to show you, we're going to walk through the framework so you can understand what it's doing.
I'm going to add it both to the application server target and the web server target. The web server target corresponds to the client application in this case. And because clients today are very smart and have a lot of processing power, we can actually ask the client to do a lot of things.
So it makes sense to have the client perform some of these functions. So I'm going to rebuild the project now that I've included this framework. What I expect to see is, rather than see the results of the search in the table view, I want to see photos. So let's bring the framework up while that's building. Takes just a second.
So again, all I've done is I've added this framework to the product. So what I expect to happen is When I search for items, and I'm going to search for everything, you can search with wildcards and things like that, all of the item names that have "Darth" in them.
Alright, so you see I get the results back in this resizable window. I can actually click on the results and see more information about them, and I have a tooltip there and all of that. So, how does this happen? Well, like I said, this uses a lot of the advanced Direct-to-Java client customization techniques. So, let's look at it.
Let's actually look at the framework. So the first thing we do is when the user clicks the Find button, we need to, in a sense, intercept that request and take control of the application at that point. So I'm using the rule system to do that. So let's open up this rule file that's in the framework.
So it says, for the query task, and we're querying on an item, for a controller that's an entity controller, item is an entity in my model, use a different class. So rather than use the query controller class, which is the default, the EOQueryController class, which is the default, use this custom controller class.
So if I look at my framework for a class named QueryController, We see that it's a subclass of EOQueryController. So it doesn't do much, but the most important thing it does is it overrides the find method. And this allows me to take control when the user clicks find. So I get the fetch specification that directJavaClient constructs for me. So when the user clicks find here, directJavaClient is constructing a description of the data that the user wants to fetch based on the query parameters they've entered.
So now I'm making an invocation on the controller factory. We talked about this controller factory object and that you can do very powerful things by interacting with it programmatically. So I'm asking it to open a window for another task. And in this case, the task is scroll. Well, where does that come from? It's not one of the default tasks, but it's a task that I define in my rule file. And so what I'm saying with this rule is that when asked for the scroll task, provide a window. And the window that I want to provide is corresponds to the definitions in the scroll view component.
You're all following me? So we go to-- back to the framework, and I have a component called scroll view component. And it's a D2W component, so we use D2W templates in Java Client as actually the templates for a lot of these controllers, so don't really need to understand that, but the important thing is that this contains frozen XML. So this is part of- this is an XML hierarchy for the description of the window that I want to display. So it includes a frame controller with a bunch of tags. It includes a single text field controller with static text.
But most importantly, it has this generic controller tag. And this controller tag specifies another class. And this class is a scroll view controller class. So again, I look at my project for scroll view controller. Well, what is this? It happens to be a subclass of EOWidgetController. And I'm subclassing EOWidgetController because it already provides a lot of the functionality, a lot of the smarts to actually display a swing widget.
But I want to write a new widget. So I override this method to return a new widget. And I don't know much about writing swing, but, you know, I spent half a day and looked at the Sun docs and I could figure enough out to actually write that scrolling component. So here I'm actually writing my own swing and plugging that widget into the client application.
[Transcript missing]
Thanks, Brian. I'm sorry. So we talked about direct to web. We talked about direct to Java client. The last thing we had on the introductory slide was direct to web services. We won't talk about that other than this slide because there's a whole session on direct to web services on Friday. What I want you guys to keep in mind if you go to this session is the process.
When you're hearing about direct -- well, they introduced web services a lot more in this session, but there will be a part of the presentation where they talk about direct to web services. So keep the process in mind. You're also starting with a model. You're also getting a default app for free. And you're also using customization techniques very similar to the ones we showed you here. So that's all. And if you want to know more about direct to web services, go to session 612 on Friday.
Summarizing what we talked about today, we talked about the rapid development technologies, the direct-to-start world. You come in at the very beginning by giving us a model, a description of your data. You use direct-to-web, direct-to-Java client, or direct-to-web services, and we give you a default application for free. You use an assistant, the special assistant, depending on which technology you're using, but they're going to be similar functionality. And you start doing basic customization by doing indirect manipulation of the rules.
And you can get very, like roll up your sleeves and do heavy duty HTML, Java, XML, all that stuff you guys do as WebObjects developers. And you can plug in bits and pieces of your components into a running application until you finally get to your customized application. So that's the end of our session today, the roadmap. This is WebObjects Day in this room, if you haven't noticed. We have a bunch of WebObjects sessions all day, I think. Sessions relevant to this one are Advanced DOF at the end of the day here, and the Creating Web Services session on Friday.
contact page. You've probably seen this a lot of times. And this one is important. Brent has put in a lot of work in writing a lot of books and documentation for the Direct to Start technologies and the rest of the doc team. And he's got some books here, and we have a book for Direct to Web, a book for Direct to Java client, the Advanced DOF books. There's a lot of places to start out. And Q&A. Put these slides back while we're in the Q&A, if you guys-- because we never leave them long enough. Are you guys--