Since we know our application will need to have registered users, I figured I'd start by implementing the user authentication framework.
There are several options, some of which can be used together.
Use OpenID
OpenID is a pretty cool mechanism that allows you to register on one web site, and use that id and password on another web site. So instead of registering with each web site, you only register the once. It's a lot like Google Accounts, but there's no centralized control over where you register. You can register on any OpenID enabled site, and that site then becomes your home site.
The problem with OpenID is that it's still very much a geeky sort of thing to use. I don't want to force non-technical community members to figure out OpenID in order to use my application. It'd be cool to allow OpenID for those who already have those IDs, but I don't want to require it.
On the other hand, the geeks at places like Google and Yahoo allow their ids to be used as OpenID ids, so people might already have an OpenID and not know it.
Use Google's Authentication
App Engine makes it nearly trivial to hitch on to the authentication Google uses for Gmail and other Google services. No code needs written to force someone to log in before seeing a specific page, and only a little code is needed to get the email of the currently logged in user. That email can then be used as a key into an application specific data store.
One problem is that people have to register for a Google Account if they don't have one...that isn't all that serious, since people would have to register on the web application anyway.
Another issue is that this doesn't support any OpenID account, just Google Accounts (which can also be used as OpenID accounts). So an OpenID user who used a different OpenID provider than Google would still have to register for a Google Account.
Maintain My Own Database
The traditional way of handling a web application is for that web application to maintain a list of registered users. A new user must register with the web application, and their user id and password is specific to that web application.
The advantage here is that I can write this so it plays well with OpenID, and have both. Since a Google Account also works as an OpenID account, I'd be automatically supporting those, too.
The disadvantage is that there's quite a bit of code to write, compared to the nearly zero effort of just supporting Google Accounts via App Engine.
What To Do?
Having talked about three options, I think I'll use a fourth.
RPX is a website that allows a site to piggy back on logins people already have, such as OpenID, Google, Yahoo, Facebook, etc. So someone could sign onto my site with their Facebook ID. The basic service is free, so no worries there.
The disadvantage to this is that I'm now dependent on a third party site for processing my user authentication. No doubt this opens up all sorts of security problems, but for the purposes of this course I can accept that. I'll talk at some point during the course about security concerns with web applications, and how to reduce security issues.
For a company, or a site that expected to have a huge user base, RPX might not be the best option (at least not the free version...but then a company could afford the paid version). But to get something up and running easily that allows access to a fairly large number of people, I'll go with RPX.
We'll start to work through the details of this in the next post.
Thursday, May 21, 2009
Wednesday, May 20, 2009
Examining The Sample App
When we created our project in Eclipse, we got a sample GWT/App Engine application for free. It doesn't do much, but it's a good way of seeing the sorts of things we'll have to deal with in our own application.
App Engine works by means of Java Servlets. These are Java classes that are associated on the server with a specific URL. When a web browser asks the server for that URL, the Java class is run and it returns data back to the browser. That data may be a complete web page, or it may be smaller amounts of data.
GWT will call servlets in the server by asking for specific URLs. GWT can then parse the data sent back to figure out what to change on the current page.
In the Eclipse project, look under war/WEB-INF and open web.xml. Expand web-app and then servlet, and you'll see that the servlet named greetServlet maps to the Java class omega.server.GreetingServiceImpl. Expand servlet-mapping and you'll see that the servlet named greetServlet also maps to the URL /omega/greet (yours will have project names different from omega).
For servlet based projects, the web.xml file manages the mapping between URLs and Java classes.
You should also see an HTML file at the same level as WEB-INF. That's the HTML file that provides the container for the GWT app. If you look at it, you'll see that there are a couple of empty divs for the name field and the send button. The GWT code in Omega.java fills those in wtih an edit field and a button, and calls the server when the button is pressed.
Now look at Omega.java (again, the name of yours will depend on your project name). In the onModuleLoad method, you'll see what looks like Java Swing initialization. Note though the RootPanel.get lines. Those are actually adding user interface elements to the HTML page itself, in the divs with those specific ids.
Scroll farther down to the MyHandler nested class. This handles the click on the button, or the pressing of the Enter key. Both call sendNameToServer, which is just below them in the file. The line that starts greetingService.greet makes a call to the server. The onFailure method is run if that call fails for some reason. The onSuccess method is run if the call succeeds. On success a dialog box is shown that contains the HTML sent back by the server.
Now look at GreetingServiceImpl.java in the server folder. This is the class that gets called by the client. You can see it just returns some HTML with info about what browser they're running.
That's a quick tour through the sample app. Studying this will give you a better handle on what we'll be doing as we add our own functionality.
App Engine works by means of Java Servlets. These are Java classes that are associated on the server with a specific URL. When a web browser asks the server for that URL, the Java class is run and it returns data back to the browser. That data may be a complete web page, or it may be smaller amounts of data.
GWT will call servlets in the server by asking for specific URLs. GWT can then parse the data sent back to figure out what to change on the current page.
In the Eclipse project, look under war/WEB-INF and open web.xml. Expand web-app and then servlet, and you'll see that the servlet named greetServlet maps to the Java class omega.server.GreetingServiceImpl. Expand servlet-mapping and you'll see that the servlet named greetServlet also maps to the URL /omega/greet (yours will have project names different from omega).
For servlet based projects, the web.xml file manages the mapping between URLs and Java classes.
You should also see an HTML file at the same level as WEB-INF. That's the HTML file that provides the container for the GWT app. If you look at it, you'll see that there are a couple of empty divs for the name field and the send button. The GWT code in Omega.java fills those in wtih an edit field and a button, and calls the server when the button is pressed.
Now look at Omega.java (again, the name of yours will depend on your project name). In the onModuleLoad method, you'll see what looks like Java Swing initialization. Note though the RootPanel.get lines. Those are actually adding user interface elements to the HTML page itself, in the divs with those specific ids.
Scroll farther down to the MyHandler nested class. This handles the click on the button, or the pressing of the Enter key. Both call sendNameToServer, which is just below them in the file. The line that starts greetingService.greet makes a call to the server. The onFailure method is run if that call fails for some reason. The onSuccess method is run if the call succeeds. On success a dialog box is shown that contains the HTML sent back by the server.
Now look at GreetingServiceImpl.java in the server folder. This is the class that gets called by the client. You can see it just returns some HTML with info about what browser they're running.
That's a quick tour through the sample app. Studying this will give you a better handle on what we'll be doing as we add our own functionality.
How GWT Works & Our First Design Decision
GWT allows you to write Java code, which then gets compiled down into Javascript suitable to run in any major web browser. For Java programmers, this means using your familiar language to create the client side of a web application. Hooray!
A GWT application does run inside of a web page; it's important not to forget that we aren't actually writing Java. We're writing Javascript that runs in a browser, so not everything is the way we're used to it.
Our first major design decision is how to integrate the GWT application into the web page. Here are the options:
HTML First
In this option, the HTML files control the layout and look and feel of the site, while the GWT application will fill in specific areas in the page with their own information. A web designer would create the page, and leave in blank divs for the GWT application to use.
The advantage of this is that the web designer doesn't have to understand anything about GWT. They just have to give their divs appropriate ids.
Pure GWT
In this approach, the basic HTML file is empty, and the entire user interface is built using GWT. The advantage of this is that you have, basically, only one page in the entire application. It all loads, and after that asynchronous calls are made to fetch data. The GWT code can change the components on the page all it wants.
The disadvantage is that it looks like an application, not a pretty web page. You can take alook at Gmail to see what this would look like.
Another disadvantage is that a pure GWT site won't index well in search engines. This isn't a problem for member-only areas, but is for the public areas of the site.
And The Answer Is?
Ultimately, I think the HTML First option is the way to go. It allows you to leverage talented web designers to create a very nice looking site, and allows the GWT programmers to focus on just the logic of the application and not on how it looks. We can also get pages indexed.
Unfortunately for my students, if they choose that option it means they'll have to learn some HTML. If they've escaped it so far, that isn't such a bad thing in this day and age. But it does mean extra work learning something we won't cover in class.
I'll be using that option for my sample application. I'm not a great web designer (just the opposite, in fact), but I hope to be able to find someone to make it pretty later.
A GWT application does run inside of a web page; it's important not to forget that we aren't actually writing Java. We're writing Javascript that runs in a browser, so not everything is the way we're used to it.
Our first major design decision is how to integrate the GWT application into the web page. Here are the options:
HTML First
In this option, the HTML files control the layout and look and feel of the site, while the GWT application will fill in specific areas in the page with their own information. A web designer would create the page, and leave in blank divs for the GWT application to use.
The advantage of this is that the web designer doesn't have to understand anything about GWT. They just have to give their divs appropriate ids.
Pure GWT
In this approach, the basic HTML file is empty, and the entire user interface is built using GWT. The advantage of this is that you have, basically, only one page in the entire application. It all loads, and after that asynchronous calls are made to fetch data. The GWT code can change the components on the page all it wants.
The disadvantage is that it looks like an application, not a pretty web page. You can take alook at Gmail to see what this would look like.
Another disadvantage is that a pure GWT site won't index well in search engines. This isn't a problem for member-only areas, but is for the public areas of the site.
And The Answer Is?
Ultimately, I think the HTML First option is the way to go. It allows you to leverage talented web designers to create a very nice looking site, and allows the GWT programmers to focus on just the logic of the application and not on how it looks. We can also get pages indexed.
Unfortunately for my students, if they choose that option it means they'll have to learn some HTML. If they've escaped it so far, that isn't such a bad thing in this day and age. But it does mean extra work learning something we won't cover in class.
I'll be using that option for my sample application. I'm not a great web designer (just the opposite, in fact), but I hope to be able to find someone to make it pretty later.
Teaching & Development Philosophy
Okay, one more post before I start writing some code.
My general teaching philosophy with this course is that we are learning how to develop web applications. We are not just learning GWT (which is the client side), and we are not just learning App Engine (which is the server side).
We're learning how those two tools (and a host of others) hook together to form a complete web application.
In these posts, I'm not going to cover the basics. If you're not in the course, and you're reading this, and you haven't done any Java Swing work before, head for a tutorial. That'll be important for understanding how to create a user interface in GWT.
There will probably be other things that I won't cover as well. I'll try to post tutorial links when I remember to do so.
Another important aspect of my development philosophy is that I favor having a working application at all times. I'm not going to write tons of code in GWT for the screens, and then move on to the server work. At every stage we will have a working application and full client/server interaction for the features we've implemented so far.
It may take a few blogs posts to get through a particular feature, but I believe strongly that having a working application is the best way to know if you're heading in the wrong direction early.
The first step of this project is going to be user authentication. At the end of that step I'll have a web server that can accept logins and registrations, even if it doesn't do anything else.
Okay, enough talking, the next post will start the technical bits. Promise.
My general teaching philosophy with this course is that we are learning how to develop web applications. We are not just learning GWT (which is the client side), and we are not just learning App Engine (which is the server side).
We're learning how those two tools (and a host of others) hook together to form a complete web application.
In these posts, I'm not going to cover the basics. If you're not in the course, and you're reading this, and you haven't done any Java Swing work before, head for a tutorial. That'll be important for understanding how to create a user interface in GWT.
There will probably be other things that I won't cover as well. I'll try to post tutorial links when I remember to do so.
Another important aspect of my development philosophy is that I favor having a working application at all times. I'm not going to write tons of code in GWT for the screens, and then move on to the server work. At every stage we will have a working application and full client/server interaction for the features we've implemented so far.
It may take a few blogs posts to get through a particular feature, but I believe strongly that having a working application is the best way to know if you're heading in the wrong direction early.
The first step of this project is going to be user authentication. At the end of that step I'll have a web server that can accept logins and registrations, even if it doesn't do anything else.
Okay, enough talking, the next post will start the technical bits. Promise.
What Project?
Okay, I think I'm at the point where I finally have to decide on a project to do.
Sure, I could put it off for a bit longer...after all, any web project will need a login and authentication infrastructure, but last night my wife suggested doing a community events site, where people and organizations could post their events. I liked the idea, so I don't have any need to keep procrastinating.
What makes a community events site a good candidate for this project? Aren't there tons of those out there? It's true that there are a lot of sites that attempt to provide this functionality, but if people from the community don't use them they have no value. I think a site developed by a member of the community might get better buy in from the community itself.
And the technical aspects of the project are great. I get a typical web model, where visitors don't need to be logged in to see events, but do need to be logged in to generate or discuss events.
I get the opportunity to do some cool mashups with Google Maps and weather data (for directions to the event and the weather forecast for the event).
The project is complicated enough to make for a good sample, but not so complicated that most of my time is going to be spent on logic not related to the technology.
So, that's it...I'm not sure what it'll be called yet, but it'll be a community events site. Now I can start writing some code!
(Note to my students...I'm going to be designing as I go, and refactoring as needed. This works for me because of my experience in developing software, and because I do a lot of head-work design while walking to work. I'd strongly suggest that you do some on paper design work to show what you want the screens on your site to look like. That'll help get your head around what has to happen on the server.)
Sure, I could put it off for a bit longer...after all, any web project will need a login and authentication infrastructure, but last night my wife suggested doing a community events site, where people and organizations could post their events. I liked the idea, so I don't have any need to keep procrastinating.
What makes a community events site a good candidate for this project? Aren't there tons of those out there? It's true that there are a lot of sites that attempt to provide this functionality, but if people from the community don't use them they have no value. I think a site developed by a member of the community might get better buy in from the community itself.
And the technical aspects of the project are great. I get a typical web model, where visitors don't need to be logged in to see events, but do need to be logged in to generate or discuss events.
I get the opportunity to do some cool mashups with Google Maps and weather data (for directions to the event and the weather forecast for the event).
The project is complicated enough to make for a good sample, but not so complicated that most of my time is going to be spent on logic not related to the technology.
So, that's it...I'm not sure what it'll be called yet, but it'll be a community events site. Now I can start writing some code!
(Note to my students...I'm going to be designing as I go, and refactoring as needed. This works for me because of my experience in developing software, and because I do a lot of head-work design while walking to work. I'd strongly suggest that you do some on paper design work to show what you want the screens on your site to look like. That'll help get your head around what has to happen on the server.)
Using SVN Productively
Most of my students won't have used a version control system before, so I thought I'd better write on the best way for them to use it.
First off, it takes a bit of discipline to use SVN productively. If you do it right, then you'll be able to work on your project at home, at school, on your laptop, and always be sure that you have the most current version of your code.
Do it wrong, and you'll find yourself with three different versions of the code and faced with the problem of merging the changes.
So I'll lay out some general rules for using SVN:
1) Before you start to work on your code in a particular location, right click on the project name in Eclipse and select Team->Update To HEAD. This downloads the most recent version of the files from the SVN repository, making sure that you'll see any changes you made on other machines.
2) When you're done with a particular change in a file (e.g. you're satisfied you fixed the bug, or the functionality you've added works), right click on the file and select Team->Commit and then enter a description of what you changed.
3) Before you stop working on a particular machine, Commit anything you've changed, even if you're not done with it yet. This makes sure it'll be available on other machines when you update them.
If you keep to these rules, you shouldn't have any trouble with needing to merge different changes to a file, or possibly losing changes to a file. At least not with a single developer project, which is what you'll be doing in the course.
First off, it takes a bit of discipline to use SVN productively. If you do it right, then you'll be able to work on your project at home, at school, on your laptop, and always be sure that you have the most current version of your code.
Do it wrong, and you'll find yourself with three different versions of the code and faced with the problem of merging the changes.
So I'll lay out some general rules for using SVN:
1) Before you start to work on your code in a particular location, right click on the project name in Eclipse and select Team->Update To HEAD. This downloads the most recent version of the files from the SVN repository, making sure that you'll see any changes you made on other machines.
2) When you're done with a particular change in a file (e.g. you're satisfied you fixed the bug, or the functionality you've added works), right click on the file and select Team->Commit and then enter a description of what you changed.
3) Before you stop working on a particular machine, Commit anything you've changed, even if you're not done with it yet. This makes sure it'll be available on other machines when you update them.
If you keep to these rules, you shouldn't have any trouble with needing to merge different changes to a file, or possibly losing changes to a file. At least not with a single developer project, which is what you'll be doing in the course.
Tuesday, May 19, 2009
Why GWT & App Engine?
I said last post that we didn't have any code written yet, and that's technically true.
We haven't written any code yet, but by creating a Web Application Project using GWT and App Engine, we do have a skeleton project that shows communication between a GWT client and an App Engine server. And it'll all run right on our machine from within Eclipse.
Start Eclipse and click on the project name for your project in the upper left pane. Then click on the toolbar icon that looks like a red suitcase with a G on it. On the next screen click Compile. That will take the GWT code and compile it down into Javascript.
Now if you right click on the project name and choose Run As->Web Application, a local web server will start with Java App Engine running, and the web page defined by our GWT application will open. Type in your name and click Send to see a full round trip to the server and back.
It's important to understand that all this is running on your local machine. We haven't signed up for App Engine space yet (and won't until we figure out what the project is!), and we haven't had to transfer anything to a web server. It's all local, and we can keep it local until we're ready for it to go online.
Okay, so on to the question, Why GWT? There are many reasons, but here are the important ones for this course.
1) My students already know Java, so they don't need to learn Javascript.
2) GWT takes care of browser compatibility
3) GWT limits the security concerns of web apps (to at least a manageable level)
4) It all works in Eclipse, which my students are already used to using
Why App Engine? We could write GWT apps that communicate with any server language, including PHP, Python, etc, hosted on any shared hosting account. We're using App Engine because:
1) With Java App Engine and Eclipse, it all integrates beautifully for testing locally
2) There's no cost for App Engine hosting at the basic level
3) If a student's project takes off, App Engine can scale with their success
Sure, I could have used a Javascript library on the client and PHP on the server, but I'd have lost at least some of the advantages of GWT and App Engine in doing so. This way, I'll know that students who complete the course will have a leg up on their colleagues who don't have this sort of experience.
We haven't written any code yet, but by creating a Web Application Project using GWT and App Engine, we do have a skeleton project that shows communication between a GWT client and an App Engine server. And it'll all run right on our machine from within Eclipse.
Start Eclipse and click on the project name for your project in the upper left pane. Then click on the toolbar icon that looks like a red suitcase with a G on it. On the next screen click Compile. That will take the GWT code and compile it down into Javascript.
Now if you right click on the project name and choose Run As->Web Application, a local web server will start with Java App Engine running, and the web page defined by our GWT application will open. Type in your name and click Send to see a full round trip to the server and back.
It's important to understand that all this is running on your local machine. We haven't signed up for App Engine space yet (and won't until we figure out what the project is!), and we haven't had to transfer anything to a web server. It's all local, and we can keep it local until we're ready for it to go online.
Okay, so on to the question, Why GWT? There are many reasons, but here are the important ones for this course.
1) My students already know Java, so they don't need to learn Javascript.
2) GWT takes care of browser compatibility
3) GWT limits the security concerns of web apps (to at least a manageable level)
4) It all works in Eclipse, which my students are already used to using
Why App Engine? We could write GWT apps that communicate with any server language, including PHP, Python, etc, hosted on any shared hosting account. We're using App Engine because:
1) With Java App Engine and Eclipse, it all integrates beautifully for testing locally
2) There's no cost for App Engine hosting at the basic level
3) If a student's project takes off, App Engine can scale with their success
Sure, I could have used a Javascript library on the client and PHP on the server, but I'd have lost at least some of the advantages of GWT and App Engine in doing so. This way, I'll know that students who complete the course will have a leg up on their colleagues who don't have this sort of experience.
Subscribe to:
Posts (Atom)
