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.
Subversion Server
Since I want to do this project as a sample that will work for anyone reading it, not just the students in my class, I'm not going to set up a local Subversion repository for the code.
Instead, I'll use a site that offers free Subversion hosting. XP-Dev.com has both free and paid modes. One of the things I liked about their free mode is that there's no limit on the number of users. So if I decide later to take on collaborators, they can get access to the code.
Another free service that looked good was Unfuddle.com. They limited their free version to just a couple of users, though, and didn't provide as much storage space.
So I created an account over at XP-Dev.com. First step there is to create a Subversion repository. It'd be helpful at this point to know what my project was going to be about, to name the repository appropriately. Since I don't, I'll just pick a working code name for the repository.
Click on Subversion in the list on the right after you're logged on to XP-Dev.com, and then click on New Repository. Put in a name of some sort and click the Save button.
The next page that shows gives you the addresses you'll need to configure Subclipse. Copy the No SSL address and start Eclipse.
Create a new project in Eclipse (File->New->Web Application Project). Name the project, and give it a package name, too (that can be the same as the project name). Make sure that it's checked to use the latest versions of GWT and App Engine. Click the Finish button.
Open Window->Open Perspective->Other..., and choose SVN Repository Exploring. In the upper left pane, choose the little icon that has a + and SVN on it to add your new repository. Paste in the URL you copied from XP-Dev.com after you created your SVN repository, and click the Finish button.
Enter your XP-Dev.com user id and password when asked. You should then see your repository listed in the upper left pane.
Now let's hook that repository up to the project you created. Get back to the Java perspective (Window->Open Perspective->Java) and right click on the name of the project in the upper left pane. Choose Team->Share Project..., choose SVN and click the Next button. Use Existing Repository Location should already be selected, and you'll see your XP-Dev repository listed. Make sure it's selected, too, and click the Next button. On the next screen it asks for the folder name, I just left the default selected and clicked Next.
On the next screen click Finish, and it'll ask if it should open the Synchronize View perspective. Click Yes, and the Team Synchronizing perspective opens. This is where you can add files to the repository so that they're under version control. To do this we right click on a file and choose Add To Version Control.
We can do the same thing from the Java perspective, by right clicking on a file and choosing Team->Add To Version Control.
Let's go ahead and add everything using the Team Synchronizing perspective. Right click on the name of the project and choose Expand All. Select all the actual files (but not the directories) by holding down the control key as you click on each file.
Be sure to select all the .jar files from war/WEB-INF/lib. You haven't written those files, but including them makes it easier to recreate the project from SVN if you have a computer or disk crash.
Right click on one of the selected files and choose Add To Version Control. Then right click on one of the files and choose Commit. You'll now be able to enter a comment to be attached to this particular version of the files in the repository. I entered "Initial version" and clicked OK.
Subclipse will now upload those files to the repository. If you log in via the web to XP-Dev.com you can browse the repository and see the files there.
We'll need to remember to add new files we create to version control, and to Commit changes to version controlled files.
More on that as we go along, and other Subversion related topics.
Instead, I'll use a site that offers free Subversion hosting. XP-Dev.com has both free and paid modes. One of the things I liked about their free mode is that there's no limit on the number of users. So if I decide later to take on collaborators, they can get access to the code.
Another free service that looked good was Unfuddle.com. They limited their free version to just a couple of users, though, and didn't provide as much storage space.
So I created an account over at XP-Dev.com. First step there is to create a Subversion repository. It'd be helpful at this point to know what my project was going to be about, to name the repository appropriately. Since I don't, I'll just pick a working code name for the repository.
Click on Subversion in the list on the right after you're logged on to XP-Dev.com, and then click on New Repository. Put in a name of some sort and click the Save button.
The next page that shows gives you the addresses you'll need to configure Subclipse. Copy the No SSL address and start Eclipse.
Create a new project in Eclipse (File->New->Web Application Project). Name the project, and give it a package name, too (that can be the same as the project name). Make sure that it's checked to use the latest versions of GWT and App Engine. Click the Finish button.
Open Window->Open Perspective->Other..., and choose SVN Repository Exploring. In the upper left pane, choose the little icon that has a + and SVN on it to add your new repository. Paste in the URL you copied from XP-Dev.com after you created your SVN repository, and click the Finish button.
Enter your XP-Dev.com user id and password when asked. You should then see your repository listed in the upper left pane.
Now let's hook that repository up to the project you created. Get back to the Java perspective (Window->Open Perspective->Java) and right click on the name of the project in the upper left pane. Choose Team->Share Project..., choose SVN and click the Next button. Use Existing Repository Location should already be selected, and you'll see your XP-Dev repository listed. Make sure it's selected, too, and click the Next button. On the next screen it asks for the folder name, I just left the default selected and clicked Next.
On the next screen click Finish, and it'll ask if it should open the Synchronize View perspective. Click Yes, and the Team Synchronizing perspective opens. This is where you can add files to the repository so that they're under version control. To do this we right click on a file and choose Add To Version Control.
We can do the same thing from the Java perspective, by right clicking on a file and choosing Team->Add To Version Control.
Let's go ahead and add everything using the Team Synchronizing perspective. Right click on the name of the project and choose Expand All. Select all the actual files (but not the directories) by holding down the control key as you click on each file.
Be sure to select all the .jar files from war/WEB-INF/lib. You haven't written those files, but including them makes it easier to recreate the project from SVN if you have a computer or disk crash.
Right click on one of the selected files and choose Add To Version Control. Then right click on one of the files and choose Commit. You'll now be able to enter a comment to be attached to this particular version of the files in the repository. I entered "Initial version" and clicked OK.
Subclipse will now upload those files to the repository. If you log in via the web to XP-Dev.com you can browse the repository and see the files there.
We'll need to remember to add new files we create to version control, and to Commit changes to version controlled files.
More on that as we go along, and other Subversion related topics.
Installing Eclipse
The IDE I'll be using for this project is Eclipse.
For the course, the computer labs will already have Eclipse installed and configured. Most of the students will also already have Eclipse installed on their home machines and/or laptops. But, they probably have the Eclipse IDE for Java Developers, not the one for Java EE Developers. We're moving into web programming now, so let's move to the version of Eclipse that has tools specifically for web programming (at this point, I have no idea if we'll need the extra tools or not...that's how software development goes when you're trying something new, you seem wise only after you've made your mistakes).
Head over to the Eclipse downloads page, and download the latest Eclipse IDE for Java EE Developers. Have some coffee, or take a walk in the sun, while you wait for the download to complete.
What the download gets you is a zip file. If you've never installed Eclipse before, just unzip this file somewhere (the root of your C: drive is traditional, but if you have another version of Eclipse there and don't want to overwrite it, anywhere will do). You'll end up with an Eclipse directory with a whole bunch of files and directories under it. One of those files immediately under it will be Eclipse.exe. Make a shortcut to that somewhere handy, like on your Desktop.
Start Eclipse, and wait for a bit more. When it asks you about the workspace, you can accept the default or change it. You should know where your workspace is if you aren't going to be using a hosted version control system, so you can regularly back up your code.
Now, for the plugins. Note that everything but the Google Plugin was part of the Pro Web 2.0 toolset, so credit goes to Jeff Dwyer for choosing them for his project. I'm just following his lead.
Google Plugin
This is an important one, since it takes what used to be a bunch of command line typing for managing GWT and App Engine projects and instead gives us Eclipse menus. See the Google page about installing this plugin. To find out what version of Eclipse you have (if you've forgotten what you downloaded), in Eclipse look at Help->About Eclipse Platform.
Once you figure out which of the URLs you need, copy that and then go into Eclipse's Help->Software Updates menu. Click on the Available Software tab, and then on the Add Site button. Paste in the URL from you copied from Google's page and click OK.
You should see now the option to download not only the plugin, but also the latest versions of GWT and Java App Engine. Go ahead and check all three and click the Install button. It'll take a few seconds to calculate dependencies, and then will display an Install wizard. Go ahead and click Next, and then accept the terms of the license agreements. Click the Finish button, and it'll actually do the install. Click Yes when it asks if you want to restart Eclipse.
We now have the Google Eclipse plugin, plus the GWT and App Engine files we need to develop those sorts of applications.
Subclipse Plugin
This plugin allows Eclipse to work with a Subversion repository (a particular type of online version control). That's the sort used by Google Code, so if you're making your project Open Source then you'll be able to use Google Code to host it. If you aren't making it Open Source, then you'll have to find another Subversion server to use (do a Google Search on free subversion hosting and you'll find some that are suitable for single person projects).
To install Subclipse, go to the Subclipse web site and click the Download and Install link on the left. Scroll down a bit to where it lists the links for the most recent version. Copy the link that's labeled Eclipse Update Site URL.
In Eclipse, go back to Help->Software Updates, and back to the Available Software tab to Add Site with the URL for Subclipse. Click the box next to that URL when it shows up in the list to install everything from that site. Click Install, Next, agree to the license agreements, and Finish.
Restart Eclipse again.
Find Bugs Plugin
Install the Find Bugs plugin. This plugin will look for some common causes of errors in Java programs. These sorts of errors will pass the compiler, but cause you problems. There's a huge variety of bugs that are looked for as part of this. Most you won't ever see, but if it saves you the time tracking down even one obscure bug, it'll have been worth installing.
That's it for Eclipse.
For the course, the computer labs will already have Eclipse installed and configured. Most of the students will also already have Eclipse installed on their home machines and/or laptops. But, they probably have the Eclipse IDE for Java Developers, not the one for Java EE Developers. We're moving into web programming now, so let's move to the version of Eclipse that has tools specifically for web programming (at this point, I have no idea if we'll need the extra tools or not...that's how software development goes when you're trying something new, you seem wise only after you've made your mistakes).
Head over to the Eclipse downloads page, and download the latest Eclipse IDE for Java EE Developers. Have some coffee, or take a walk in the sun, while you wait for the download to complete.
What the download gets you is a zip file. If you've never installed Eclipse before, just unzip this file somewhere (the root of your C: drive is traditional, but if you have another version of Eclipse there and don't want to overwrite it, anywhere will do). You'll end up with an Eclipse directory with a whole bunch of files and directories under it. One of those files immediately under it will be Eclipse.exe. Make a shortcut to that somewhere handy, like on your Desktop.
Start Eclipse, and wait for a bit more. When it asks you about the workspace, you can accept the default or change it. You should know where your workspace is if you aren't going to be using a hosted version control system, so you can regularly back up your code.
Now, for the plugins. Note that everything but the Google Plugin was part of the Pro Web 2.0 toolset, so credit goes to Jeff Dwyer for choosing them for his project. I'm just following his lead.
Google Plugin
This is an important one, since it takes what used to be a bunch of command line typing for managing GWT and App Engine projects and instead gives us Eclipse menus. See the Google page about installing this plugin. To find out what version of Eclipse you have (if you've forgotten what you downloaded), in Eclipse look at Help->About Eclipse Platform.
Once you figure out which of the URLs you need, copy that and then go into Eclipse's Help->Software Updates menu. Click on the Available Software tab, and then on the Add Site button. Paste in the URL from you copied from Google's page and click OK.
You should see now the option to download not only the plugin, but also the latest versions of GWT and Java App Engine. Go ahead and check all three and click the Install button. It'll take a few seconds to calculate dependencies, and then will display an Install wizard. Go ahead and click Next, and then accept the terms of the license agreements. Click the Finish button, and it'll actually do the install. Click Yes when it asks if you want to restart Eclipse.
We now have the Google Eclipse plugin, plus the GWT and App Engine files we need to develop those sorts of applications.
Subclipse Plugin
This plugin allows Eclipse to work with a Subversion repository (a particular type of online version control). That's the sort used by Google Code, so if you're making your project Open Source then you'll be able to use Google Code to host it. If you aren't making it Open Source, then you'll have to find another Subversion server to use (do a Google Search on free subversion hosting and you'll find some that are suitable for single person projects).
To install Subclipse, go to the Subclipse web site and click the Download and Install link on the left. Scroll down a bit to where it lists the links for the most recent version. Copy the link that's labeled Eclipse Update Site URL.
In Eclipse, go back to Help->Software Updates, and back to the Available Software tab to Add Site with the URL for Subclipse. Click the box next to that URL when it shows up in the list to install everything from that site. Click Install, Next, agree to the license agreements, and Finish.
Restart Eclipse again.
Find Bugs Plugin
Install the Find Bugs plugin. This plugin will look for some common causes of errors in Java programs. These sorts of errors will pass the compiler, but cause you problems. There's a huge variety of bugs that are looked for as part of this. Most you won't ever see, but if it saves you the time tracking down even one obscure bug, it'll have been worth installing.
That's it for Eclipse.
Possible GWT Books
Part of the problem with teaching something that's still changing as quickly as GWT and App Engine is finding a suitable text book. GWT is at version 1.6 right now, and the books I've seen haven't caught up yet.
So far, I've received evaluation copies of Pro Web 2.0 Application Development with GWT, and Accelerated GWT. Kudos to Apress for getting those out to me very quickly! I'm still waiting to hear from Manning Publications on a review copy of their GWT In Practice.
Which book I end up using will depend in part on how this sample project goes. So far, I'm very impressed with the topics covered in Pro Web 2.0 Application Development with GWT. The author, Jeff Dwyer, takes you through the development cycle for a full web 2.0 application. Along the way he talks about how he solved those issues that always come up when you start to move away from toy sample applications. In particular, his discussions of real web 2.0 security concerns are excellent.
But, the tool stack Dwyer chose for his project may not match what I'll end up using. I'll give some of the tools he chose a try, but since I'm using App Engine for the server and he didn't, not everything will match. So I'm not sure it'll be a good text for the course, even though I consider it to be an invaluable reference for web 2.0 development issues.
Accelerated GWT looks very nice, although it's more of a general book, and not focused on developing one specific application. It covers GWT 1.4, though, and the version I'll be using will be 1.6 (it's hard to tell what it'll be up to by spring 2010, when the course runs).
Even so, it seems like it would function better as a general text, since it nicely covers server integration but doesn't rely on a particular tool stack.
We'll see what other books I can come up with to review, but I'm not going to wait on picking the text to start development. My free time is pretty limited, so it'll take most of the summer to put this together.
If I only knew what I was going to develop...
So far, I've received evaluation copies of Pro Web 2.0 Application Development with GWT, and Accelerated GWT. Kudos to Apress for getting those out to me very quickly! I'm still waiting to hear from Manning Publications on a review copy of their GWT In Practice.
Which book I end up using will depend in part on how this sample project goes. So far, I'm very impressed with the topics covered in Pro Web 2.0 Application Development with GWT. The author, Jeff Dwyer, takes you through the development cycle for a full web 2.0 application. Along the way he talks about how he solved those issues that always come up when you start to move away from toy sample applications. In particular, his discussions of real web 2.0 security concerns are excellent.
But, the tool stack Dwyer chose for his project may not match what I'll end up using. I'll give some of the tools he chose a try, but since I'm using App Engine for the server and he didn't, not everything will match. So I'm not sure it'll be a good text for the course, even though I consider it to be an invaluable reference for web 2.0 development issues.
Accelerated GWT looks very nice, although it's more of a general book, and not focused on developing one specific application. It covers GWT 1.4, though, and the version I'll be using will be 1.6 (it's hard to tell what it'll be up to by spring 2010, when the course runs).
Even so, it seems like it would function better as a general text, since it nicely covers server integration but doesn't rely on a particular tool stack.
We'll see what other books I can come up with to review, but I'm not going to wait on picking the text to start development. My free time is pretty limited, so it'll take most of the summer to put this together.
If I only knew what I was going to develop...
Monday, May 18, 2009
Hello World
This blog exists for one purpose only, to document my sample GWT & Google App Engine project. This will be used as a guide for students in a Web Applications class to be held Spring 2010. I'll start by assuming you know what GWT and App Engine are, because otherwise the other posts are going to be either boring or mystifying, or both.
I haven't decided what the project will be yet; I'm leaning toward something more complicated than a typical to-do list sample, because that'll give my students a better guide (along with giving them the odd laugh or two as they see my mistakes along the way).
I'll be using GWT for the client side because my students already know Java. Not all of them will have had Swing programming yet, but I'm confident they'll come up to speed on that quickly enough. Which wouldn't be the case if I decided to go with Java Script for the client side.
For the server side I'd really like to use Python, and would if it were just my own project. But again, my students will already know Java so it's hard to justify switching languages on the server. Especially since App Engine is available in a Java version that plays well with GWT Serialization.
So, GWT on the client, and Java App Engine on the server. The next few posts will be about getting the environment set up. We'll be using Eclipse with some relevant plugins for both client and server code.
I'm going to be using SVN for managing my project. My students are welcome to follow along and do that, too. That isn't required, but if you've ever deleted a big Java file from your hard drive accidentally, you know the motivation for having every version saved somewhere safe.
That's it for the first post. Hopefully by the time I've done all the setup posts, I'll have figured out what this project is!
Important Note: I'll be posting Java code in many of the posts. Code does not format well on the blog posts, so don't expect to be able to simply copy and paste the code into your files. Treat the code as a text book example...type it in yourself to get a feel for what it's doing, rather than copying and pasting.
I haven't decided what the project will be yet; I'm leaning toward something more complicated than a typical to-do list sample, because that'll give my students a better guide (along with giving them the odd laugh or two as they see my mistakes along the way).
I'll be using GWT for the client side because my students already know Java. Not all of them will have had Swing programming yet, but I'm confident they'll come up to speed on that quickly enough. Which wouldn't be the case if I decided to go with Java Script for the client side.
For the server side I'd really like to use Python, and would if it were just my own project. But again, my students will already know Java so it's hard to justify switching languages on the server. Especially since App Engine is available in a Java version that plays well with GWT Serialization.
So, GWT on the client, and Java App Engine on the server. The next few posts will be about getting the environment set up. We'll be using Eclipse with some relevant plugins for both client and server code.
I'm going to be using SVN for managing my project. My students are welcome to follow along and do that, too. That isn't required, but if you've ever deleted a big Java file from your hard drive accidentally, you know the motivation for having every version saved somewhere safe.
That's it for the first post. Hopefully by the time I've done all the setup posts, I'll have figured out what this project is!
Important Note: I'll be posting Java code in many of the posts. Code does not format well on the blog posts, so don't expect to be able to simply copy and paste the code into your files. Treat the code as a text book example...type it in yourself to get a feel for what it's doing, rather than copying and pasting.
Subscribe to:
Posts (Atom)
