Lab 7
Web
Services
Introduction
This week we learned how web services can provide useful
data to web applications. In this lab you will use a web service to get new
relevant data, transform it via XSLT, and display it in your application.
Instructions:
- Copy your Lab06 new Lab07 directory. Your main file
should still be called index.html
2.
Here is what you what you want to have when you are
finished. Suggested plan of attack for
getting there is below (read it before
you start!):
- Try to keep the functionality from your previous
lab (e.g. don’t start over and delete things, but you don’t have to fix
things either. Talk to the
instructor if you have a reason to modify this).
- There should be a button(s), link(s), or something
to click or interact with such that when you click on one the following
happens:
- You use AJAX
to invoke a Perl/PHP proxy
- The proxy invokes a web service (you choose, see
below)
- The web service returns XML to the proxy, which
returns it to your HTML/JS application
- You transform that XML with XSLT (same general
idea as last week, but see details below).
- You display part of the transformed XML in your
page.
- All of this should happen within the same HTML
page (e.g. the URL up top should not change)
- The web service must return different results based on different data in your database. For instance, if you have people, you
might show weather for their hometown when you click on one. If you have products, you might show
related pictures when you click on it. Thus, the same web service will be
invoked, but different data from you will yield different results. This
implies that your web service should accept some argument (talk to the
instructor if you find a web service that you really want that doesn’t
have this).
- It is perfectly fine to insert some new info into
your database to make this lab work.
For instance, maybe you didn’t have zipcodes before, but now you
need them for a service – go ahead and add them.
- You may choose any web service (some exceptions
below) that returns XML and that permits you to use it for free
non-commercial use (though you will likely have to register). Start this early! You may have to
wait for a “key”, or it may turn out the service doesn’t provide what you
need. Details:
- Tip: use www.programmableweb.com
to find web services. Click on “API Directory” – then look for search
options. Search for those
with protocol of SOAP, REST, or GET. You want the data
format to be XML. NOTE: not all the services have the “protocol” and
“data format” fields stored on this site – so you might not want to
filter on those at first. Start
by looking at the categories to see if you can find something that looks
useful.
- Try to pick a service that adds real usefulness to
your site. Talk to the instructor
if you need ideas.
- You may not
use the two services used as lecture examples (weather.com for REST
and Flickr for SOAP). Note:
Flickr also offers REST – if your application really calls out for photos,
and Flickr is really what you need, you can try to convince the
instructor to allow you to use Flickr via REST, subject to some
additional requirements.
- You probably do NOT want to use a mapping-based
web service (we’ll add that later).
- Your must use a proxy that directly interacts with
the web service using Perl or PHP (as the two examples in class did).
For instance, you may not use
one of the Google JavaScript libraries that directly adds a map and
handles all the interactions behind the scenes (we’ll do that later)
- You must use XSLT to modify the XML that you get. It should transform the XML so that
it fits in with your existing page. Don’t just display the XML that
you get back! Having some reasonable style and appearance count here.
- As always, your code must be commented!
- On your default.htm page, provide some good, very specific comments for
a user (e.g. the instructor) on how to use your site. This should be specific to this lab –
e.g. how can I see that your site meets the requirements for this lab?
For instance, what to click, what to enter, etc.
- Default.htm must have these additional links:
- The “invoke link”: a link that directly invokes
your web service, so that clicking on it shows the raw XML returned from
your web service. This should not
be to a saved XML file – instead, after clicking on this you should be
able to modify the argument that is shown in the URL in order to see
different XML results.
- Link to test1.xml. In the browser, clicking on
this should show the result of the transformed XML.
- Link to test2.xml. In the browser, clicking on
this should show the raw XML.
- Suggested plan of attack (see also helpful info at
end)
- Do NOT
follow the requirements above in order. Instead…
- First identify a web service and register (if
necessary).
- Figure out how to access the web service via your
browser (or a Perl proxy, if it’s SOAP).
- In default.htm, add the “invoke link” that is
described above.
- Using the “invoke link”, save a sample XML result
from the web service – call it test1.xml. You will have to turn this in.
- Write a XSLT transformation and test it on
test1.xml by adding the XML processing instruction up top. Don’t forget
to verify your XSLT file alone by loading it in a browser.
- Copy test1.xml to test2.xml, and remove the XML
processing instruction from the top of test2.xml.
- Write the JavaScript to load the XML (from
test2.xml), apply the XSLT to it, then insert some of the result in your
page.
- Modify your JS to invoke the Perl/PHP proxy to get
the dynamic XML data (instead of fetching the static XML), then transform
via XSLT and display on your page.
- In default.htm, add instructions AND links to
test1.xml and test2.xml (see requirements above).
- Test and make sure everything still works! You’d be surprised how often things get
accidentally broken that you were sure worked.
4.
Ensure your page works with Firefox. Having it work on
IE is encouraged but not required.
5.
Ensure all your pages validate and that you have met
all requirements.
NOTE: all HTML files must validate as XHTML without errors
for full credit. The penalty for a file that does not validate is 10%.
Helpful stuff
- See the plan of attack above!
- For problems with perl, see tips about creating Perl files.
- As always, the “Error Console” in Firefox is
invaluable.
- On the command line, database errors will usually
appear automatically. From the
browser, they won’t – instead insert this as a debug:
print $DBI::errstr;
- Do not use
the die() function alone – the error it generates can’t be seen from your
web page.
Deliverables
1)
All of your files for Lab07 should be in a folder
called "Lab07" (without the quotes) on the Web drive.
2)
Your main page for Lab07 should be called
"index.html" (without the quotes) and placed inside the folder Lab01.
3)
All files must be complete and saved to your Web drive
before you submit the hardcopy of your assignment. Do NOT modify your files
after you have submitted your assignment.
4)
Turn in the following hardcopy on or before the due
date, stapled together in the following order (coversheet on top):
a)
A completed assignment coversheet. Your comments will help us improve the
course.
b)
The first page of the output of the W3C validator, as run
on the final version of your Lab07 HTML that does the new transformation. This should show that your document correctly
validated, but turn it in anyway if you can’t get your page to validate.
c)
A printout of the
source to your Lab07/index.html file (or other HTML file that has the new
transformation). Truncated lines are
not acceptable – use Crimson Editor vice Notepad if needed for printing. You could also paste into Microsoft Word etc.
if needed.
i)
NOTE – turning in just the JavaScript fragment that
does the transformation and insertion is acceptable if you wish.
d)
Printouts of external JavaScript files, if any.
e)
Printout of your Perl/PHP file that acts as a proxy
f)
Printout of sample.xml
returned by the web service you use. Just the first page is okay, if it’s long.
g)
Printout of your XSL file