Week 15: AJAX
This is a team exercise (use week 14 teams).
Prerequisites. You should have completed the week 14 exercises (permalink filter and exercise set 11a) as well as attended the lectures. Regardless, you might want to review the week 14 lecture slides while you are working on this exercise.
- (1) Fixing view person. The AJAX version of "view person" fails to display the person's information. Locate the problem and fix it. Hint: you might want to ensure that you understand how the browse people functionality is implemented both on the client and the server sides. Also, making use of the browse Developer Tools to view the View Person request response: can you see what is missing?
- (2) Enhancement. Adjust the XHTML and/or AJAX so that instead of a static "Person Information" heading, the person's name is displayed as part of the heading text like this: "Alice's Information".
- (3) Extra (time permitting). Enhance the interface when Increase Age fails due to a lost update by showing a "Refresh Information" button that will refresh the information of the person being viewed. Note that this button should only be shown immediately after a lost update. Once the person information has been refreshed, the button should no longer appear in the pane.
- (4) Non-AJAX extra. The non-AJAX increase age functionality is not working. Can you find out why and fix it (without changing the increase age dispatcher or domain command).
Submit to KSOL your solution as a .war file, including sources.
Week 14: Permalinks and Servlet Filters
This is a team exercise. Using the KSOL .war file as a base, your main goal in this practice exercise is to refactor the given permalink functionality and place it into a Servlet Filter class. In detail, here is what you need to do:
- (0) Setup and smoke test:
- Get the .war file associated with this practice exercise from KSOL.
- Ensure that it runs out-of-the-box. Of course, do not forget to setup MyResources.properties. (Note that this app uses the same database table as the previous exercise.)
- [Question 1] In the lecture slides of week 13, permalink URL patterns are suggested for the Buddy Age application. What are the patterns and which use cases do they correspond to?
- Create the file "WebContext/QnA.txt" (or .html if you prefer).
- Place a copy of this question and your answer in the QnA file.
- Do the same for subsequent questions marked [Question] below.
- [Question 2] With this version of the Buddy Age app running:
- (a) Browse people: which URL appears in your browser when you perform this action?
- (b) View Alice: which URL appears in your browser.
- (c) In BrowsePeople.jsp, what is the value of href used to view a person?
- (d) In web.xml, what is the servlet-mapping for the Front Controller?
- (1) Factor out from the permalink functionality from the Front Controller servlet and package it in a Servlet Filter by:
- First creating a filter. The easiest way to do this is to right-click on the project's deployment descriptor and select New >> Filter.
- In the New Filter dialog enter the following information in the first pane:
- Package: org.dsrg.soenea.buddyAge.appPres.filter.
- Class name: BuddyAgePermalinkFilter.
- Superclass: [leave blank]
- Select Next in the New Filter dialog and Edit the given Filter Mapping to trigger on the activation of the Front Controller servlet (at least on request and forward actions).
- In the new filter's doFilter() method is where you add your filter code. Note that the request parameter can be safely case to an HttpServletRequest as needed.
- [Question 3] Now that you have created the Servlet Filter, inspect the web.xml file. Which new entries were added to the web.xml file as a result of creating a new filter following the steps outlined in the practice exercise description?
- [Question 4] For each of the following HTTP response status code ranges, given an example of one specific status code (hint: see week 13 slides): 200, 300, 400, 500.
- (2) Visit the increment age link on a person, say Alice, and look at the URL shown in your browser ...
- In your browser, the URL has an ending of the form "inc/1?version=3". Instead, the URL that should appear, should be the one you recorded as your answer to Question 2(b). To achieve this, ...
- Change Increment Age so that its response to the browser is an HTTP redirect (status 301), giving it a URL to view the person instead.
- Open two browsers and attempt to do, in succession, an increment age on the same person in both browser windows. Of course, this will cause a lost update exception to be raised on the second increment age attempt. You will notice that the increment age domain command sets a warning attribute in this case and that the view person JSP is setup to display this warning if present. If you implemented the HTTP redirect correctly, then the warning will no longer show up in the viewed response. Why? How can you remedy the situation?
- [Question 5] There is a bug in the implementation of the delete person use case. What is the bug and how should it be fixed?
- (3) Change the functionality of delete so that it behaves like increment age; i.e., it does an HTTP redirect when appropriate.
Submit to KSOL your solution as a .war file, including sources and your QnA file.
Week 12: Buddy Age using Revised Patterns 4
Use your solution to the previous practice exercise as a base. In this practice exercise, your goal is to:
- Create a summary of the key points of Chapter 5 of Thiel.
- Format: point form, no more than 2 to 3 pages.
- List the names of your team members in the document.
- Suggestion: collaborate using a Google doc.
- Make corrections to your previous solution based on the feedback your team was given. This is your opportunity to get 100% in the "Buddy Age using Revised Patterns 3" part!
- Ensure that you implement a Person Factory with createClean() and createNew() methods as suggested by Thiel.
- Refactor the given Front Controller to make use of Thiel's revised approach involving a Dispatcher and a Domain Command hierarchy.
- Some of the Front Commands have duplicate code; e.g., the delete person Front Command has the code of browse people. Find the most appropriate way to eliminate this code duplication as part of your refactoring.
Submit to KSOL a .war file of your updated project (including sources) as well as the Chapter 5 summary.
Week 12: Buddy Age using Revised Patterns 3
Use the solution to the previous practice exercise as a base. In this practice exercise, your goal is to:
- Redesign the application to make use of SoenEA’s Unit of Work, in the "caller registration" style.
- Implement a delete buddy cascaded referential action. I.e., deleting a person deletes every other person that has him or her as a buddy.
Note that this implies the need to:
- Refactor your Person Mapper into I/O Mappers.
- Create a Person Factory class.
- Also making use of SoenEA's Identity Map.
Use your notes from Chapter 5 of Thiel to guide you (especially those for Sections 5.2.2 and 5.2.3).
Submit to KSOL a .war file of your updated project (including sources).
Week 11: Buddy Age using Revised Patterns 2
The .war file given as a starting point for this exercise is a solution to last week's practice exercise. A video illustrating how to solve last week's practice exercise is given here
. For this week, the objective of the practice exercise is to add support for a Delete Person use case, including an implementation of the "set to null" referential action. Since this exercise does not involve use of the SoenEA Unit of Work, you should implement the referential action directly in the mapper delete method (as if you were dealing with a dependent mapping); i.e., no need to use the GenericOutputMapper's cascade* methods.
Optional: adapt the Front Controller pattern to match that suggested by Thiel; i.e. use a Dispatcher and a Domain Command hierarchy (along with the SoenEA helpers).
Submit to KSOL a .war file of your updated project (including sources).
Week 10: Buddy Age using Revised Patterns 1
Using your experience with previous WEAs, import the KSOL "Buddy Age Revised Patterns 1" exercise starting .war file and get it running on a Tomcat 7 server. Note:
- Before running the WEA you must create a new database table (using prefix "BuddyAge7_"). You can use the init SQL file included in the .war (under WebContent/WEB-INF).
- Remember to define an appropriate MyResource.properties file following the given sample file (under the project's src folder). In particular note that this project uses a new database table prefix.
- FYI: add and delete commands have not been implemented in the given sample project.
The created dynamic web project that results from importing the .war file should have no compilation errors. If, compilation errors exists due to Servlet related types not being found then open the project's properties and ensure that Tomcat is selected under the Target Runtime property group.
Locate the modules that you will be using, starting with DomainObject: from the Project Explorer, open the project's Java Resources >> Libraries >> Web App Libraries >> SoenEA2.jar. DomainObject will in the package org.dsrg.soenea.domain; IDomainObject will be in org.dsrg.soenea.domain.interf. Can you find DomainObjectProxy?
Modify the given WEA to support Person Proxy's using Stuart Thiel's patterns and classes (DomainObject, IDomainObject, DomainObjectProxy) as illustrated in Figure 4-1 and as described in Section 4.1 and 4.3 of the thesis, and in this week's lectures. Figure 5-1, illustrates the relationship that exists between user modules and the SoeanEA modules like DomainObject, IDomainObject, DomainObjectProxy; you can use this as a guide for creating something similar for Person (rather than Group).
Note: you do not need to create DomainObject, IDomainObject, etc. but rather use these modules as provided by SoeanEA. Use Eclipse's name completion feature to find these modules.
Test your implementation by modifying the SQL file so that Bob and Carl are mutual buddies. Reload this modified SQL init file and test viewing Bob and Carl.
Submit to KSOL a .war file of your updated project (including sources).
Week 06: Buddy Age Iteration 3 & 4 Refactoring
Read all instructions before starting.
This is a pair-programming exercise. Your pair-programmer should be a member of your week 6 team. You may want to sit close to your other team member pairs in case your team wants to do an occasional problem solving huddle.
For this practice exercise, you are given a .war file which holds a dynamic web project to start from. The .war file has 2/3 of the BuddyAge Iteration 3 refactoring done; only increment age needs to be completed. Your objectives are to:
A. Complete the Iteration 3 refactoring; i.e.,
- Review the Buddy Age Iteration 3 class diagram in the thesis.
- Examin the given, partial Iteration 3 solution. E.g., look at how View Person and Browse People have been implemented.
- Complete the Iteration 3 refactoring for increment age. (Note that in the given design, there is no helper class. Do not create a helper class, see how the other Transaction Scripts are implemented).
B. Complete Iteraction 4 refactoring; i.e.,
- Review the Buddy Age Iteration 4 section of the thesis (note that this was required reading).
- Like the given Iteration 3 solution, do not use helper classes.
- I suggest that you tackle this refactoring in stages, in the following order:
- Implement support for Optimistic Offline Locking. In preparation for this step you need to do the following:
- Source the given init4.sql (under WebContent/WEB-INF) into your database.
- Change the table prefix in your MyResource.properties file to be BuddyAge4_.
- Ensure that your WEA is still running.
- Proceede with refactoring your code.
- Factor out the Page Controllers from the Transaction Scripts. In doing so, ensure that you put the newly created classes into appropriate Java packages (that you will have to create), e.g., named: domLogic, appPres (and with the already existing techSvc, these represent the three layers).
C. What to submit
- Ensure that the names of the programmer pair appear in the index.html file.
- Submit to KSOL a .war file, including source, of your solution.
Week 04: Buddy Age Iteration 1 Refactoring Design Review
- Completion of the Buddy Age Iteration 1 Refactoring exercise.
- You are sitting together with you team mates (roaster has been e-mailed to the class mailing list).
Goals and objectives:
- Present and defend your Buddy Age Iteration 1 refactoring.
- As a team, compare solutions and create a "best team design".
- Bundle your design into a .zip or .war file (make sure you exclude your MyResource.properties file).
- Include in this bundle the names of team members who actually participated (do not include names of absentees).
- Submit your design to KSOL (under content >> practice >> Buddy Age Iteration 1 Design Review >> Team X, where X is your team number).
- Two members of each team will be chosen to come present and defend the team's design. The instructor will be choosing the presenting members and will be guiding the presentation via questions.
- You might want to split your team into two groups and that each group come up with a "best design", then consolidate the two best designs. This will likely be easier than trying to compare 6 or so solutions at once.
Week 03: Buddy Age Iteration 1
As was mentioned in class, we will be using the simple Buddy Age application as a running example. We will effectively be learning Fowler's EA patterns by implementing them as refactorings to an initial Buddy Age design in which each use case is realized by a single do-it-all servlet.
- Successful completion of the "Hello Web" and ES1aQn2 hands-on exercises.
Checking out iteration 1 of Buddy Age
- Launch a Eclipse (Java EE bundle). The remaining steps are performed in Eclipse.
- Select from menu Window >> Open Perspective >> Other >> SVN Repository Exploring. If you do not see an SVN perspective, then follow the instructions in the sub-bullet.
In SVN Repositories, right-click, select New >> Repository Location. Use the following URL: svn+ssh://cislinux.cis.ksu.edu/home/faculty/chalin/repo/cis562-public using your cislinux user id and password.Open the repository and right-click on BuddyAge/BuddyAge-Iteration1-DoItAllServlet and select Checkout.Switch to the Java EE perspective. You should see the BuddyAge-Iteration1-DoItAllServlet project.Under the problems tab, ensure that there are no problems reported for this project. If you checked out the project into a new workspace, you may have to select Run >> Run on Server for this project to associate it with a tomcat 7 server.
- Select from menu Help >> Install New Software: Work with "All available sites"; in the filter type svn (then wait 10 sec); from the list select "Subversive SVN Team Provider"; later in the installation of SVN, select SVNKit 1.3.7.
Eclipse database access configuration
- From the Java EE perspective, locate the BuddyAge-Iteration1-DoItAllServlet project.
- Open the project's "Java Resources/src" folder.
- Locate the file named MyResources.properties.sample, right-click and select Copy.
- Paste a copy of the file in the src folder and name the copy "MyResources.properties".
- Open "MyResources.properties" and add the required information.
- Note that if you have not created a database yet in your MySQL account, then do so now. Choose a suitable name and use that name in the properties file.
- In Eclipse, locate and open the file BuddyAge-Iteration1-DoItAllServlet/WebContent/WEB-INF/init.sql. Can you figure out what it is doing?
- Using your preferred way of interacting with your CIS MySQL database (see below for alternatives), import (i.e. source) the init.sql file. This should create a table and populate it with some entries.
Running Buddy Age (Iteration 1 code)
Ensure that you can run this version of the Buddy Age application (launch it like you did the previous WEA that you worked on). Explore its functionality: Browse People, View Person and Increase Age.
Note: If you are off campus, you will need to tunnel into K-State's network in order to access your MySQL account. There are a few ways of doing so, but the simplest is to follow the instructions given here: How do I access the campus VPN?
Exercise (Refactor to match Interaction 2 design)
Your objective is to refactor the code in the given BuddyAge-Iteration1-DoItAllServlet project so that it respects the design given in Section 3.4 of the Stuart Thiel's Thesis
. In essence, you are factoring out Data Source functionality and putting it into a Row Data Gateway class.
Submission via KSOL
As was done in the previous exercise, export your project as a WAR file and ensure that you check the "include source" checkbox. Submit this WAR file via KSOL.
Your own machine setup
For this course, you should setup the following tools on your own machine or learn how to launch them from one of the lab machines. The following are essential:
This will be useful a little later:
Lab machine setup
Eclipse 4.2 is available on the lab machines under Windows and Linux. Under Linux, launch Eclipse 4.2 using the eclipse42
command (which should be in your path, if not, add /usr/local/bin
to your path). Instructions for setting up and running Tomcat from Linux are given here
News Flash: The host cislinux.cis.ksu.edu actually resolves to one of two machines: viper or cougar. One of these machines has the setup described in that page. The other machine only has Eclipse 4.2 and it is named just "eclipse" not "eclipse42". This should be fixed shortly.
CIS MySQL account access
CIS MySQL accounts have been created for all on the CIS MySQL server. Instructions for access and use can be found in the CIS support FAQ
. Some useful information from that page:
- Access via the web with phpMyAdmin or via the command line like this: mysql -p -h mysql.cis.ksu.edu
- MySQL Host: mysql.cis.ksu.edu; MySQL Port: 3306 (default).