Hi, I'm Chuck Hill. For those of you who hang out in the WebObjects mailing list, you'll probably recognize the name Chuck. I'm also one of the authors of Practical WebObjects. If you're doing WebObjects development, you don't have it, you want to. I work for Global Village Consulting, which is a WebObjects development house based in Vancouver, Canada.

My goal today is to make those of you here who are not using Eclipse for your day to day WebObjects development want to start using it. And for those of you who are already using it, pay attention because you might see a few new features you haven't seen yet. I'm also going to give you some idea of what you need to do to get from the IDE you're using today into Eclipse and what the costs to you are going to be of that migration.

Okay, we've had some sessions on Eclipse before at WWDC but they were never really looking at WebObjects. So what I want to do today is I want to look at features in Eclipse that are of particular interest to WebObjects developers. Now, before we get started, I'm assuming everybody has at least heard of Eclipse. Can I have a show of hands of the people who are not using Eclipse for WebObjects development.

Oh my. Oh my. Okay, so let's take a brief look at what it is. Eclipse is a platform neutral IDE for general development. It has become wildly popular, partly I think because it is free and developers like free. As it comes out of the box, it's not particularly for Java. It is for anything. You can do COBOL in it, you can do whatever. It's just a platform for development environments. It does come with some Java tools, which are really good.

But, it doesn't know anything about WebObjects That's where WOLips comes in. WOLips is a plug-in which integrates into Eclipse and teaches it about WebObjects. So, it tells it how do you build a WebObjects application? How do you build a WebObjects framework? What do you do to edit a Neomodel? What do you do to edit a WoComponent? So it's the part that makes Eclipse smart about WebObjects.

Now it also comes with one other thing, which is Will Project, now this is an ant based build system and it's the command line way of building a WebObjects application. So, it's going to replace what we've done in the past with making project builder, with jam in Xcode.

Now, why migrate, why not stick with what you have? You're going to have problems in it, you're going to have to learn the new IDE you're going to have to move all your projects and you might run into problems, but you're not. Tomorrow there's a lab, there is Apple engineers there, ready to help you move your projects. I'll be there, I think Mike Shrag will also be there to help you.

There is a WOLips mailing list mailing list, almost as active as a web objects mailing list, a lot of the same great, friendly people there ready to help you, there's also a Wiki for WOLips that has some pretty good tutorials and getting started. It doesn't cover everything, but between that and the list you can find out what you need to find out. So, why migrate? Why not just stick with what you know? I migrated a long time ago. For me, the reason to migrate was productivity gains. It's a better IDE for Java, it's a better IDE for Web Objects, you can get more done quicker, that's why I moved.

But, this year, Apple has given you an even better reason to move, last year it was announced that some of the tools were going away, EO modeler was going away, WebObjects builder was going away, sometime in the future, we didn't know when, and this year they've announced that, as of Leopard, that transitions complete, bye bye, no more Legacy tools. There're replacements tools right now, today, to replace those in WOLips. So, with the productivity gains and the new tools, the decision makes itself, you really want to be using Eclipse and WOLips. It's the future of WebObjects, it's a great future, embrace that future.

So in a few minutes I'm going to go through a very, very brief demo of some of the key features of what's in Eclipse and WOLips, and I'm not going to be able to show you everything that's up here, but I want you to ask yourself, when you're doing your development, what is your machine doing for you? What is that IDE doing for you You've got a great piece of silicon sitting in front of you, is that IDE helping make your life easier, or is it just sitting there? Is it just a GUI wrapper around some command line tools, the same tools that people have been using for the command line forever.

What about code completion? Does it have code completion? Does it have intelligent code completion? Context sensitive code completion? Debugging, does it even have a debugger? Does it have a Java debugger? Is the Java debugger aware of WebObjects? Does it give you special support for WebObjects? And how about error reporting? Error reporting, for me, is a big thing. I make lots of mistakes, I'm a very bad typer.

Do you have to build to find your errors? Does it show them to you automatically? Does it tell you exactly where they are? Exactly what they are? Does it help you fix your errors? Now I've talked to a lot of people over the years, I migrated back in the days of Project, and I've talked to a lot of people who've gone from Project Builder to Eclipse, from Xcode to Eclipse, and a lot of them did so reluctantly, they kind of thought they were being pushed into it, they weren't too happy about it. I haven't talked to one single person that wanted to move back after a couple of days, or a couple of weeks, of real experience with Eclipse, I don't think any of you are going to be the first. So now we're going to go into a brief demo.

So here's Eclipse, I'm not going to go through what's in the IDE and to do that demo today, we've got the pet store application, which you're probably familiar with through the last few versions of WebObjects. Now, I'll point out that the demo I'm showing today are the WebObjects 5.3 versions of the Pet Store, they're not the WebObjects 5.4 versions, because it appears Don had cleaned up some of the mess that I want to show you today.

So we're going to open this up and we're going to go into one of the classes, and here we have, it's a little bit slow to load up the first time because, again, it's loading the plug-ins into memory, after the first file it snaps right up. So, you take a look here and you can see that there is a little warning sign there and some of the imports are underlined.

Now, Eclipse keeps a model of your project as you're developing it, and it's not just what's in your project, it's not just what files are in your project, it's what in the files in your project, and it can tell here, because it knows what's in this Java file, that none of these imports are being used.

So we can just go here to the source menu and we can just say, Organize my imports, clean them up, and bang, they're finished. It can do the same thing in add imports, so it's an example of something that you've probably done everyday, and it's just grunt work, it's not intelligent, here the machine's doing it for you. It's keeping any eye out for what's going on.

And you'll notice that there's no build button in Eclipse, there's just a run button, because there's no build cycle, because it's constantly doing this in the background, constantly keeping the model updated, all you need to do is run the application. So, there's a lot of great tools you can build with that. We saw one, with the imports, let's take a look at another one here.

So here's a very simple method and it's just copying some strings into some attributes of our order object. So I'm going to go ahead and I'm going to delete that and pretend, like I usually do, that I've forgotten what the thing was. So, I'm going to type address one instead of addrone, and you can see that it puts a red underline in it.

I haven't saved it, I haven't built it, but it says already, okay, whatever you're typing, that's wrong. And, I can go figure it out myself, but why bother? I can just ask for a quick fix and it'll pop up a list of things I can do to bring my Java back into a valid state.

And I don't really want to create local variables, oh I meant, address one. So, just two very simple examples of the way that Eclipse is using that model to help you fix errors as soon as you make them, help you keep them from finding in the run loop. So the only time now that you need to run the application is to find your logic errors, errors when you weren't thinking correctly and you programmed the wrong thing.

Now, the next thing I want to look at is the replacement for WebObjects Builder. The related view kind of takes the place of what groups did in Xcode where it kept all your Java files, all your API files, your files all together, it's there in the related view.

So, we're going to go down here to the file, double click on that, open it up, and the first thing you're going to notice is, oh no, there's no GUI view, and that's true, there's no wizzy wigdo, this is strictly text mode editing, and you can see from this, it's not going to be much fun editing it because this line goes on and on and on and on and on and WebObjects Builder kind of kept some of these things hidden behind the way for you, it didn't show you some of the messy stuff it was creating in the background. And we're not going to want to keep editing five feet of HTML, so we can just quickly come up here and tell it, okay, format that up.

So at least now we've got a fighting chance of being able to read what's there. Now the next thing we're going to get is we've got here, we've got conditional three, conditional one, string 15, conditional five, this are all default names. In Web Builder, WebObjects Builder, it didn't matter because you had a little inspector and you could see what it was, it's not going to cut it anymore, you're not going to be able to do that in text mode, who knows what string 15 is. Now, you don't have to go through and rename them all, it'll do that for you. So, you can come down here, do another refactoring and say, okay, clean up those web builder names.

And now, much easier to read, not has entry error, not as confirmed shipping, page back, edit credit card info, it looks in there, it has bindings and it makes an intelligent guess at what a reasonable name is going to be. It's not completely finished, but it will be done soon. A few more brief things I'll point out is, there's a palette here, just like there was in WebObjects Builder, you can click and insert things into your page.

You'll notice there's a whole lot of red down here, well component editor adds something we've never had before, binding validation, and some of these old examples are dirty, and you can see this one, it's full of dirty code, it's complaining about a lot of bad things it's not going to let you do anymore.

So, one of the impacts of this is, when you run your application, you're not going to see component blah blah has no key name, blah blah, or underscore blah, blah, or, you find that right there, at design time, before you even save. That saves a lot of money, certainly a lot of time.

There is full auto complete on these. Because there's so many errors here I can't really show you in this one, but we can come up here to one that's not all messed up and, so there's full auto complete, so instead of navigating through and dragging up, you can just auto complete through. It works for names, it works for component names, so there's not a whole lot of stuff you have to do.

Now, the last thing we're going to look at is entity modeler, entity modeler being the replacement for EO modeler. And again, like the components in this example, there's some dirty stuff in the model, there's a lot more model validations that you're going to get, finding errors before you run, and it's complaining about a bunch of things that aren't quite right in the model.

So the UI is going to be pretty familiar to those of you who have used EO modeler before, it's basically the same, pretty much the same UI, click on EO, you've got tabs instead of instant views, same attributes, relationships, inspectors to the relationships, it's EO modeler without the bugs. And one more thing, there's a ton of cool new features to it, I don't have time to show you.

Indexes, EOF now does indexes, EO Modeler now handles indexes, support for multiple connection dictionaries, multiple prototype definitions, prototypes, you can switch them live, reverse engineering with guesses to prototypes and does a pretty good job of it, synchronizing of names as you type so you don't have to type the same name three times. It's got wizards, relationship wizard, a many to many relationship wizard, a sub classing wizard, this keeps coming and coming and coming.

Adios EO Modeler, I won't miss you. Okay, why not migrate? Like everything, Eclipse is not perfect, it has some parts of it that aren't so good, and those of you who are not using Eclipse are probably familiar with the parts that are not perfect, because you don't like them. First thing people complain about is, it's slightly slow, and certainly some version back this was true.

So, going to the demo, I hope you saw, it's not really that slow, there are a couple pauses here and there. I mean, when you were watching Mike's demo yesterday, were you thinking, wow, that's really slow? No, probably not because he was just flipping things around as fast as he could go. It's not a serous problem, don't worry about it. Now the big one.

GUI is not OS 10, and that's true. You take a look at Eclipse and you know there have been Apple designers involved in Eclipse, ever, that's pretty obvious. But, it's an effective UI, it's a very functional UI, it gets things done. We're supposed to be engineers, not prima donna's, we're supposed to care about results, getting things done, so forget about the UI, go on with your job, get your work done.

Now there's no GUI component editor and for the way a lot of us work, this is a big, big change, there's no GUI component editor. Now, I hope you saw some of the tools there to clean up the existing code you have, with the auto completion, when you're using rapid turnaround, when you're using Hot Code replace, you can edit the Java too, I actually think this is better. I can do more, quicker like this then I could in the drag and drop view.

It was nice when you started out, but it wasn't nice for very long. So, I think this better, I don't see this as an impediment. Now custom build steps, a lot of people say I've got some special build things I'm doing, how am I going to do it? The Eclipse is ANT based, the build system is ANT based, the easiest way to deal with this is just to take them out of wherever they are now, put them in the shell script, put them in with the project, and just run them from ANT.

It's very easy to do, it's a very easy way to migrate the things across, it works, I think that's the way you should start. Long term, learn ANT, migrate these things into ANT, you've got them in one place for maintenance, you've got them in one place for use. This is not an impediment to migrating, it's just a step that you have to do.

So one of the first questions that's going to come into your mind is, I've got all these projects that are all in Xcode, or IntelliJ or whatever, I've got to get them all into Eclipse, how long is that going to take me? I'm behind schedule, I don't have the time for this. So to try and give you some idea of that, I took the Pet Store Demo that I showed you and I converted it into Eclipse.

So, I took the projects and moved them into Eclipse, got them built, got the errors out of them, got them running, and the time to do that was in minutes for the two projects, thirteen to be exact. Now that might sound like a long time, but that's a worst case scenario. I did that the slowest way I knew how. I didn't practice at all, so that's the worst case.

So, how? Now the tools that I used to migrate the Pet Store in those 13 minutes were finder and Eclipse, popped open finder, popped open Eclipse, find my Java files, drag them over, find my EO Model, drag it over, find this drag it over, it works fine if you have one project, it works fine if you have a small project, long term, if you've got more projects, it's not so good. So there's scripts is what I recommend. With scripts about two to three minutes I can get those migrated over, built and running.

There's a URL there, if you go there you can find the scripts that I've been using, you can find some fairly simple steps about how to get from Xcode, in this case, into Eclipse, there are, as I mentioned before, a lab tomorrow with Apple Engineers, I'll be there, Mike Shrag will be there, some other people will be there to help, there's the WOLips mailing list and there is some tutorials out there. It's not that hard to migrate, you can do it. This year, now, this is the time to migrate. Go, migrate. Thank you.

So, good morning everybody. My name's Anjo Krank, I am with Logic United, that's a German company providing web object services and I was invited by Apple to tell you a little bit about Direct Web and what you can do with it. As some of you may know, Direct Web is a rapid development environment that is part of WebObjects, which in turn is part of the development tools and it's now on your disk. It's also been known as the best keep secret of the best kept secret because virtually no one knows about it.

So, first about Project Wonder. We've been fixing WebObjects since 2001, we have tons of fixes and utility classes and, as you have seen yesterday, we also have great Ajax support. We have more than a dozen frameworks doing all kinds of stuff you might want to do with WebObjects, like, for example, there's an indexing framework and a support framework for all kinds of things.

We have hundreds of reusable components, you can just plug-into your application and use and post on the WebObjects staff meeting list where he can actually get that content. So what is Direct Web? It's, is an environment that takes your information from you, model and creates virtual pages of these, for common tasks like list or inspect or query.

It works by, you have a factory and you ask for a special page for example, a list page for a user entity. You can provide a subclass of that factory and provide your own logic to it. And these, the pages that get returned from that are template pages that are configured by the so called D2W context. Now, the pages, these template pages continue to ask this context for some information like for example, what kind of keys I'm going to display on the page. The D2W context, in turn, asks root system.

And there's, there's two different ways to configure this root system for this information. And then returns it to the D2W context, which in turn returns it to the page. Now, this sounds very complicated and slow, but actually it's very fast because it's cashed on multiple layers. So let me give you a brief example. Let me say the, let me assume the D2W context has been initialized with the task equals list, and the entity is the user entity.

And the page wants to display property keys. Now, let's assume you have two rules. One is if task equals edit and entity name equals user, then the display property keys will be name, login date and password. Because you want, would want to edit the password on the user edit page.

Now, rule number two says if the task equals list and the entity name equals user, then the display property keys are just name and login date. So when this process runs through, rule number two wins. And the, the value is returned to the page of the display property key is just name and login date.

So what do you got to get out of it? Well, first of all, it kind of jump starts your application. You get a lot of default function out of it for free. You don't have when you're starting out, create edit pages, list pages, all this stuff for the It's all basically done for you.

And as such you get incremental delivery. I mean, you're starting out with a complete working application and you can just refine those, the parts that you don't like or you want to extend, either by supplying rules to configure the pages that are there or plugging your own stuff into that. It's very easy.

As such you have to manage fewer assets. You don't have to write no HTML for that. You don't have to write any codes for these pages because it's all provided by a few templates And you can, of course, as such adapt faster to changes, to requirements. Meaning, if someone comes in and wants to add some key to an entity and wants to display it in a half a dozen pages, it's totally easy to do that because he'll just go into his root system, figure out which pages is, of this thing is going to get displayed. At this key, we load your page and it's there.

And I think it leads to an overall better development model because you'll be having your business logic on the one side and tiny specialized property level components. You try to really make reusable on the other side and Direct Web mediating between these two. It's a complete data flow.

So why should you use ER Direct Web? This is the direct, the web frame from Project 1. Of course we have tons of reusable property components for all common tasks for querying or editing or displaying strings, dates booleans, relationship as embedded lists and what have you. We also have a lot of very cool looking, good looking templates also, not only for the common tasks, but also for exporting to CVS, exporting to Excel, having edited of a list pages, grouping pages, reporting stuff, compare. Really, a bunch of stuff.

We also have a good concept for flow control. Meaning, that you can easily create flows of pages which model a distance process. Let's say you start at one thing and click on a select button. Then, the select page comes up. Then, you do some process with a selected item which takes long. And you want to plug a progress page into that. Stuff like that is totally easy to do.

Then, for the international users, we have a great localization system, which is working basically automatically for the English language. But for a foreign languages, you just have to work once through the application and you get returned to dictionary just replacing the keys or translating the values for some keys. And once you restart your application, it will be a totally localized in this other language.

And we have a concept for user preferences. Currently, we use this to store information such as the benching size or the sought audit and the list page. You can configure that to allow that for some pages or not. You can, you could also store information like the selected languages or what have you. It's just open to your own imagination. And we have tons of bug fixes and vastly better rule handing than the rule handling that is currently in WebObjects.

So who should use Direct Web? Well, everybody, of course. In particular, if you have a small team. If you need to get a lot of stuff done with a small amount of people. And you can do that because you wouldn't have to, you won't have to write that much code. And you won't have to write the entire HTML for most of the pages. Also, it's good if you have one large or one growing project or lots of similar projects.

It's important, there's, as someone has said, a learning cliff, in which you, in which you may run. It's, you can get into that stuff, but you have to keep on doing it. You have to, to keep on practicing it. So it's important that you actually stay with this thing. Then, you get a consistent layout for free because it's all created by templates who can make lots of structural changes to the application in an incredibly easy manner.

Also, when you have a complex project, like complex flows, complex business processes, lots of data injury, lots of validation, you all want to do this in your model and have the interface just display the messages that are in your model. You don't want to do that in your page. And Direct Web encourages that approach. Or if you have fast changing requirements. I mean, every five minutes someone's banging at your door and wants some, some stuff done until yesterday. It's really easy to do that with Direct Web.

So who is using that stuff? Well, this is of course, a totally uncomplete list and I have no idea who else is using it. But I'm just going to tell you about the example I personally, half way been involved with. First of all, there's NET Structure. This was a company who originally open sourced the Project Wonder. And they were providing corporate real estate management.

This must have been an incredibly lengthy and complex process because their model had about 200 entities and the entire application had about 1,200 pages. This whole thing was done by five people. Well, six, six, six developers. Then, there's Logic United. We provide a, we maintain a content brokerage system. There's also lots of actors involved, like you have people supplying different forms of content. You have different pricing.

You have, then, the, the people of, of the, the website where this stuff is going to get displayed, you make bundles of that content and so on. It's lots of configuration involved. I'm maintaining this entire backend from, by myself. It's about 150 entities right now. It's also not growing as fast as it was like a year ago. But it's also growing. And it has about 350 pages, something like that.

Then, there is Merces, which ones a product from the late David Teron, who was a committer from Project Wonder who died in 2002. And I was approached by the family to continue this project because he had one customer, who, it was half finished and they, they needed to finish it.

This project has about a 100 entities and about 150 pages and I was able to make the decision if I even wanted, or could maintain this project in about two days worth of time just to, to evaluate the thing and make huge structural changes to the entire application in a very, very short amount of time.

These are all kind of, sort of

So for the ones who were on the talk yesterday when Mike was showing off his block, if you look for Web 2.0 Solutions, this is probably not for you. But this currently isn't for the front-end. I mean, you can very well create back-end applications with that. But a few weeks ago there was a post under WebObjects mailing list from a company called Design Maximum. And these guys are using ER Direct Web to produce a website, it's called, Thank you to Apple for allowing to showcase a competitor to them.

These are all direct web pages and I think you will agree that they look nothing like the stuff you have seen before. So you can make front end applications with it. It takes some configuration and it takes some brain work on that but obviously you can do that.

Now, when I was originally invited here I thought I would make it through a few screenshots of our backend applications or just run through it. I thought it would a better idea to actually provide you with a working example you can get into. You can try to figure it out and configure it yourself making changes and all that stuff.

It turns out in project one since the first version there was a back tracking application actually used at Net Structure. It's pretty simple application it had like 15 entities and about fifty pages. It's done entirely by CSS and the entire user interface had at the time of writing and it's grown a bit since then. It had about 800 lines of code There about eleven pages which mainly deal with specialized reporting, about four special property level components and seven support components and needed one week for the entire first version.

So this is what happens when you are dropping the business logic into a normal direct web application. So you get a generic navigation system like you select the entity, then you select some actions. Then you have these graphically title bars and graphically submit buttons. If you were at the presentation yesterday, Pierre showcased that the direct web look has changed a little bit. Of course it looks more modernized and it's doesn't look like 1979. y But it is still, from a conceptual standpoint, it's pretty much the same. The real backtracking application more looks like this. This is the homepage.

It has a navigation system that is actually that is usable and would conform to the business process of the normal backtracking application. It has some nice features like the quick query and the greeting things in there. On this homepage there is a normalable component which has several embedded list pages inside of that. This list pages in turn are also direct web pages.

Let me show you a little bit about the navigational system that is in the ER extensions framework, ERX navigation. It is a three level navigational system which is configured by a property list. It has nice access control and it is totally easy to configure you just changing some keys in your property list and you can specify that this item is only to be seen if the session dot is admin equals true something like that.

It also has the concept of activities. Activities meaning that you have, let's a complex navigational with dozens of iterms and various levels and you have something interesting like the user has an unread item going on very below this tree. So if you are setting some keys in this property list the information about there is something interesting happening there is kind of bubbles up in the interface. Then you get something like an indicator at the top level that the user should click on there. This is built-in, default functionality. Of course you can override and extend it by your own stuff.

The entire thing is styled by CSS. It is just bunch of leads so you can make it look it was. I'm not a graphic designer so I really put this thing together on the seat of my pants. I would have love to have some app people taking a walk through that. This one is a query page with an embedded results list page. What is notable here is we have the titles are localized. I should have done this is English but I could not have proven that they are localized.

It means search box. The application has a neat mote where you can, in development, some tiny mark and there's a title that pulled from the database. It's just some example of what you can do. I mean you can do vastly different things. You can change the whole thing but it is just an example of probably what you want to do. It's nice in this part that you have some sort of embedded content management but you can have someone else edit the title of your page and you don't have to change the html components.

This thing is also localized in modern languages as much and is easy to do. Then the query is rather long so it's divided into sections. Each section is configured by the display property keys and they are also very easy to do. These are stylable by CSS and you can pretty much do what you want with it. They also have a nice feature and I didn't get around to make an indication of it. When you click on that, I stole this idea from Gyra, it kinds of collapses or de-collapses.

And also what is in there, in the list side of the page, in a non-direct web application there are just, you have tiny edits icon on the one side and the delete icon on the second side. And what this is, is a sort of a collection of actions what you can do with the current item and the list repetition. So the idea being that there's just one class that defines the whole thing. You just have to implement some method and automatically put in the interface and automatically plucked in the localization system. No html involved. Anyhow to get new features and new actions into this component there.

Whoops, sorry. So this is an example of an edit page. Here we have some nice features. Like, for example, when you change a value the background cell gets highlighted indicating to the user that there is some change going on in this item. Also, we have a nice reusable component based on tiny nice where you have rich text html component. You can copy tables from Word into this text and get saved as html in your database. But it's all just an example of what you can do. It's totally usable but just a starting mark.

Then we have, this is a screenshot from Safari. And these are not the input buttons you normally know but button text. Button texts have the nice features that you can use CSS on them and it really goes across browser compatible. So you could make like tiny icons on the side or you can style the rollover and stuff like that. Normally button texts don't that work that well on Internet Explorer on Windows. Actually each version is broken in some different ways. It's really incredible.

So I've been providing some Java script magic to fix that. And now they work fine on Internet Explorer and just the setting in your application startup to replace all the info text by these things here. They are also, as you can see, plucked into the localization system, automatically localized for you. Now here I deleted the title and tried to save although it's the user gets an error because the title is mandatory. We are providing several indications here for the user. One of those is the tiny what is floppy symbol, I don't know the term.

This is showing the user that the editing context on this page, of course the user doesn't know about any context. That there are changes on the page and that he is going to lose them if he leaves the page. This item is also styable by CSS or you can provide your own thing in there. We also have a localized error message that is very nice in that point; I mean title is both now here. If the entry in the model actually wouldn't be called title but something else.

Still you would see here that you should fill out the field title which is important because otherwise the user would get confused or an error message thrown from EOF that he should fill out field 4 when field 4 is not even on the page. To give him even more indication we make some highlights just right beside it to tell him where he should fix his errors. So the backtracking application obviously has quite a bit of features.

I didn't even get around to shoe the rest of the stuff because at some point in time I got mad and decided to put everything we had on project one into this thing. So we have a rest interface, we have a capture interface, we have the reporting engine, the Excel export, what have you.

How do we do that? How do we transform this into this? So on Sunday I was trying to give an overview of the steps you need to create, how to create a control floor? How to link pages together? How to navigate from inside of your pages to some other direct webpages? How to plug-into the localization system, how to customize it? How to build your templates? How to write property level components? And a variety of tips and tricks because you will run into trouble of course. This provides you some means to figure out what is going on.

So, in closing I would like to say again project one is all open source. We have great features and great people. Please visit us on wonder dot sf dot net and please subscribe to the wonder mailing list. Thank you.

Before Benoit starts. This is a new technology that we are working on and this is not available in Leopard This is used internally so we hope to see that in the future version of Web Object and hope you are going to enjoy what you are going to see.

Good morning. My name is Benoit Marchant. I am a Senior Software Engineer in the iTunes store. I work in the contact management application there. And I decided to add some AJAX features like I'm sure a lot of you. So I started that framework and it took about in that context. Previously I was Lead Engineer for Homepage the dot Mac web publishing application from 2000 to 2005.

And through these years, I'm not sure how familiar each of you are with Homepage but it's a web publishing application targeted to the end user. We tried to target people who never used the web before. It was back in 2000 it was not as advanced as it is now.

And the web was really the best way we could do it at the time, still being in OS 9 client side. So we went there and we started to add some Java Script features drag and roll to let you reorganize your photo albums. And it made a huge, huge difference in terms of usability. So today I would like to talk about why I call desktop class web applications.

So I'm going to explain what it is. Before we start I would like to know how many of you were asked to add some AJAX to the application you are working on? Most people in the room. So, if you went to the talk yesterday where Mike was in project wonder that is there now.

It is working well. It can be very easy to use if you take the time to learn a little bit of framework to get there. What I'm going to talk about is more looking ahead slightly in the future. So I'm going to get back to our desktop web publishing applications and then I will explain ways of framework I have been working on and what is the philosophy behind it.

Finally I'll show you some sample code of how it looks like. So first of all, what is desktop web publishing applications? It runs in a browser, it is an application and the big thing is it should feel like a desktop application. It's not like you add some AJAX to an otherwise pretty classical application. You really build an application using Java Script as the cornerstone of your programming language and you use web technologies: CSS, Java Script and XHTML to actually build the interface.

So let's go back in time, 1990, Tim Berners-Lee invented the world wide web on a XCube. That is actually a screenshot of the very XCube he used. And on the very first version of his application which was called the world wide web. In 1996, Next launched WebObjects which is why we owe him that room. Revolutionized the field, by being first of all, the first real objective internet application server available.

Secondly because they used EOF which was available on the desktop and bring the power to be on the web application. Third because the concept of building web pages was built on templates not you as a developer having to code all the HTML code yourself in your object. So the idea is that you get requests and suddenly what is coming by is the merge of the data in the template.

In 2005, something big happened in term of industry wide. Google released Google Maps. That was a big, big awakening for the industry that suddenly technology which was not new, had been around for awhile and suddenly Google with its clout and large visibility released an application that was using Java Script in a very, very serious way to do very, very serious things. That scale is very wide. So people started to notice. In the very same year, Jesse Garrett from Adaptive Path coined the term AJAX which means Asynchronous JavaScript and XML.

So in AJAX the idea is to start using more on the client side and stop relying entirely on the server for everything. So you get the first request and some of the presentation back and from that point on the idea is to the client just ask data to the server.

And that data can be returned in different forms. You can return XML or you can return JSON which means JavaScript Object Notation which is kind of a serialization format of Java Script objects. In 2000, we'll see the idea would be to build to keep the trend of doing even more stuff on the client side and really start building real applications.

I don't know if you've checked the job market in the field, but it is crazy. Everybody wants to do that but you're in a situation where you want to do an application and that is really complex. So here we're talking about instead of us serving taking care of presentation the server would just return the static resources: HTML, Java Script files, CSS which will start the bootstrapping of your obligation on the client side.

And from that point on we're back to the point where clients ask data and the server responds to data. The big difference is that the merging of the data and the JavaScript, sorry, the merging of data to actually produce what you want happens entirely on the client side.

Basically you relieve the server from doing that since there is a need growing within AJAX, which is kind of funny because the first you return is the your server side application did most of the Java rendering that UI. Suddenly on the client side you want to retrieve data and then you don't have the same tools we used to use to do that on the client side.

So what are the benefits of doing such applications? The big one is you get the goals you had to give back to the user a desktop class user experience. And that's really the main focus. The second huge benefit is that you get instant deployment. It's not like a Cocoa application where you have to share, download. Everytime your clients are going to trigger the browser to hit your servers you did all the application.

The application is statefull. Your client side is the real application. The page is not going to reload. Suddenly you can start having session states being ended by the client side without having the server to worry about it. And the server, therefore, can become leaner, more focused on doing the data layer and become stateless. Doesn't have to be, but it's much, much more easier.

So we are going to show you a demo of what we've completed for that to show you. We are going to receive an email it's about a monitor application about web AJAX. So we are going to receive an email saying an instance is down and not responding. So this instance 2002. So we are going click here and enter a small application to go in and fix it.

So here we enter an application that is formatted to run on a mobile device. Here you can see we have the navigation route. We have the size, the host, the preference is users and we are going to click on fix me to get to the instance that was down So here is the instance and we get the picture of the instance where we can see it stopped and then it was up. So may be it was down because the port was misconfigured. So we are going to go in and change the port.

There we go. Then we have to stop and restart. There we go. And we are going to save. And let's get back to look at the operations. So let's get down to size that the application will show. The size you would manage by size you would have release of the apps and you would click on the apps you would have all the other instances. And you have different inspectors, one is for instances We've seen that let's get back to the apps.

This instance. This is for the application. So here is, from a technical standpoint, all you see there has been created using client side components. So, basically, you take web components, the idea, you move those to the client side, and all these features, all you see on the screen are component, so then you detail that.

The column view view is a component itself which is its own JavaScript class, its own XHTML, which is loaded dynamically. The overall application, which is the first page you land in, is a component all by itself. You have the JavaScript class, which again control the XHTML. Everything start with CSS. The animations use CSS as well, and all the inspectors are as well components with their own XHTML and JavaScript. And now we're done, let's get the demo. There we go. Thank you. Let's get back to the slide.

So, that sounds all fine and dandy, but if developing desktop class web applications was easy, we would see a lot more of them, so it's not, and the reason is that technologies we are talking about, JavaScript, HTML, CSS, were not initially designed to be on such high level constructions as applications.

And so therefore, applications are complex, we know that, and we've been doing them client-side on the desktop for many years. The other side of developing desktop applications involve the server. You still have to implement the server side, and Web Objects is probably one of the best tools to do that. To me it is the best, even if we stray a bit from doing the presentation layer, we still have the amazing layer there, and the request doing the business logic there, so that's pretty what's the service will be focused, but you still have to integrate both together.

How do you make the client talk to the server. At what point, which point in the flow do you decide it needs to talk to the server? How do you find what change in your graphic objects client side? All these are technical decisions that you need to make, and there is no, there is no guideline currently.

And of course, you have to use JavaScript, DOM, and CSS. Let me take the occasion to say that JavaScript has very bad press, and a lot of people try to hide it as much as they can. I don't want to learn that stuff, it's too bizarre, it's not friendly, it's different. The truth is the job market is super hot in the Javascipt land because people want to start doing much more stuff on the client side, but it used to be traditionally the realm of web developers who are after all mainly designers who turn into html coder.

We turn into an html coder, and here we're talking about building applications which require, I mean, it doesn't require, but you're better off if you have a software engineering background, or years of experience in doing real development, whether desktop or server doesn't matter. But you have to have the training or the experience to manage the complexity, and it is, I think it is time to embrace JavaScript. JavaScript is hot in the market, and the very good reason for that is it's very fun to use.

So, what I started to think, to think about AJAX to my own project Apple, I was, if I had a wish list for framework, what would I pick? I have five years of background in Cocoa, seven in WebObjects AJAX, what would I like? So, first of all, I would like a real object orientation in JavaScript, and by real I mean something that is much more familiar to what I know, then the object orientation JavaScript has built in. JavaScript is object oriented. The only difference that is in everything is prototype based compared to be class based, so basically you have to chain objects, you have to chain instances to individual capabilities, and that's not the way we do that in Objective C or Java.

So the first thing would be have a layer that make, that bring me back to what I know in terms of language. The other one would be familiar APIs. Like I said, I've been using Cocoa and WebObjects for many years, I have nothing against framework like Dojo, Scritaculous, Prototye but all those APIs are pretty strange to me, and a lot of them are actually pretty function oriented, not object oriented, so not friendly. So if I had a framework where I could find stuff I know, like I know NS arrays, and these dictionaries, notification center, web components, stuff like that, that would be great.

Client side components then. Web components. I have been using web components, you've been using components on server side for many years. Now, if we could have the same concept working on the client side to take care of building the UI, that'd be awesome. UI controls, well, table views, column views, that's a given, and you need this in framework to have that, and actually most of the framework are extremely rich in that respect.

Data management. KVC, KVO, KVB, if your not familiar with this abbreviation and what it does, so KVC's Key Value Coding, KVO, Key Value Observing, KVB, Key Value Binding. These are all Cocoa technologies. Well, Key Value Coding was introduced by WebObjects, but I encourage you to go check on the website, the ADC documentation to know more about that. The idea is these are tools to let your data flow through your UI controls without having to code every time your data change.

Animations are a cornerstone of any modern UI, especially more so with Leopard, the train is irreversible now. Drag and drop, obviously, and finally server side integration with AJAX and on server side and the client side. So, I'm going to focus on three points in that list which are probably the most original and why I'm going to show you, and I'm going to jump first to the client side component.

So, like I said before, it's inspired from WebObjects components, where you have not now Java class on the client side, but the Java suite class would play the exact same role, have the same roles in controlling the XHTML templates, and really for the, I don't know if maybe some of you in the room are not WebObjects developers.

The class, the role of the class really is to be the container of that UI, pretty much like a nib owner in Interface Builder. The topic is XHTML, and you can obviously, if it's inspired from web components, you would assume that you can declare sub components in it, declare with the WOD syntax preferably, and the bindings inside of the declarations uses actually the Key Value Bindings to make sure that once your UI controls are wired, and you refresh your data through AJAX, well it just flow back into the UI.

The next part is the AJAX request reference loop. So, the idea is, well, let's take a scenario, you have an application on the client side, and your user actually changed the properties on the object, and you clicked the save button. So, the save button would be wired to trigger an action on your page level component which most likely would be called save action. So, your component receives save action.

Save action is most likely going to have to send back what changed to server side. So, let's assume we have the save methods in your client side component, web component. The client would invoke a prepackage to do that which could be called invoke remote action. So, you call invoke remote action passing name as a string.

Then what would happen is invoke remote action would call appendto request, passing a request that's been created for you, down to subgraph of the objects that actually receive the action. And the idea is to get a chance to all the objects involved, and one of them obviously could be a low quality sync context when you would knew the changes that you have on your light weight EOs on the client side. To piggy back on that request that's about to leave, all the information they have.

In the same idea, you have elements, web components have a unique ID so they are identified on the other side. Same idea. Every subject would be tagged, piggy back information, then the request is being sent, arrive on the server, where you have a more object version of tech values from request, it happens, then the invocation, again objects are oriented to take care of the cache and stuff like that.

And finally an append to response phase An append to response phase which contributes to the sub graph, which is most likely equivalent to your client side graph, your client side object peers on the server side, it will have to, but most of them will be in variable editing context is going to have a peer editing context on the server side, they get a chance to piggy back some information, so for examples, let's change a person, and I change the name on the client side, and when we save, we find out there is a conflict, in context refresh, the conflict wasn't too bad because somebody else changed another property like the address for example.

The object is merged, saved back again. The address changed, and the response look want to send me that to my client side object, so it would attach the new address to the client side EO to the response that's about to leave. So, when that process is done, the response arrive, trigger a call back on the client side, and again, all sub objectives involving the sub graph will receive a message, take value from response, basically giving them the occasion to extract from the response that came back what might be relevant to them. Finally, you have the did invoke remote action that's called on the component actually trigger initially and send the real request and you have completed the loop. So, now I would like to show you some sample code.

So, the first part is going to be about the component, the JavaScript part itself. So, one of the things that we are all, we all take for granted on the server side are dependencies. When you write code in Java or Objective-C, you have an import function, and you can say my class inits from that class, so I need to import it, and if you use other classes in your code, well, then you import them.

Unfortunately in JavaScript there is no such thing. You have to basically put your source JavaScript, that script tag, in your html. In an environment like Dojo, there is a combination of metas called provide and require, which implement my file and import, and I tried that first, but to my surprise, what happens that in order to implement dependency, they actually use an XML http request in a synchronous way, so it's blocking, and that's the way they insured your dependency is respected. So, what I came up with is a system where it is not synchronous, it is asynchronous.

So, basically the imports are going to be executed adding script tags dynamically to your page, and there is going to be a bunch of code beyond the scene to track events when stuff is being loaded, triggering other things. And it just works. It's not blocking so your browser keeps working as these resources are being done, and your html is still being passed. Other resources, images, css files being downloaded by the browser, and that uses as much bandwidth as the browser can have, which is usually around 4, 6 requests, http requests at the same time.

So here, file is about the same where you are. Imports the list of the stuff you need Then the next step is creating the class. So, I tried to come up with a syntax that is as close as I could get to stuff we are familiar with, and I came up with a three fold code.

You have the first code which is class, upper case C C because class work is reserved. You pass the name of the class you want to create. You chain an extends call, that's the name of the superclass you want to init from, and implements, you really pass implementation.

It's not like a Java interface implements, and you pass JavaScript object, where you have encased the IVARS names, or the meta names if these, if the values are functions, so here we have an album, setter for an album, setter for, album, the instance variable initialized in there, and you can, well, let me get back, and you have also a super, so I provide a super meta to let you be object oriented in a way again, you're used to using more traditional languages.

Super doesn't exist in JavaScript. You can do it by hand to some extent, but when you start narrating with more labels, you start to get iffy. So that super meta data go up the chain of init instances and involve the right method for you. And finally, you can do class methods by predicting with static.

You can do category as well. The same syntax. You just keep the initerates, you take a class, it's going to return one if it exists instead of creating one, and you can pass implements, and that way with a syntax I can add the objected index method to the array object, which is in native JavaScript to make it more friendly.

So, let's move to the component parts. Sorry, the template parts. So, that's an XHTML, totally standards for now. You can import stuff like you would do in html, so that's a link to a css file, that's packaged with my components. That's going to be the way I want to style it. This is a script tag to declare the package of my own application, and to link the JavaScript file inside the page.

Next is declarations. So, I told you we're using the same declaration from WebOjects, I was not kidding. That's a script tag with the different types, text declaration so that the browser's not going to try to evaluate that, but it's a very convenient container, and here you can see I declare two subcomponents. One is artistURL, it's a hyperlink, like a WO hyperlink hyperlink, with an HREF HREF which is bonded to a key path, and artist name is a string, again, bonded to my album that artist name came from.

So, in the the mapping here between these components, and where they happen is the name. So, here you see atistURL you will find DOM elements, sorry, a tag in the page with artistURL and you will find a tag with the ID artist name, and these are most likely dynamic elements. The same is true for component label. The inspector you've seen in the demo, they were component label, and all the fields you are seeing were using input tags, were using strings to be dynamic in the exact same way.

And that's it. So, again, to conclude, I think that the time is pretty close where all this technology we have on the client side, which again, we know we're not meant to do that, are going in that direction. I mean, there is a train in a way that is not stoppable. Everybody's doing that, everybody wants to do it, the tools are not perfect, they are pretty good. I mean, they're getting better. You have a larger and larger choice.

Every week on Ajaxian.com, I don't know if many of you read that website, but there are also one or two new frameworks every month. So, I mean, there is an explosion of people working that field, and as far as I can tell in my experience, pushing the envelope further, doing real applications, there are not many tools available which lets you provide the level of structure you are accustomed to use on the server

in WebObjects, or on the desktop with Cocoa, to actually raise the bar and save you work to actually do these kind of applications. Thank you, and I'm going to pass the microphone to Pierre.