1 / 27

Indy Java User’s Group

Indy Java User’s Group. March 27, 2001 Sallie Mae 6:00p.m. Mission Statement. Promote the use of the Java language and components across all levels of interest in the greater Indianapolis area, by serving as a resource for knowledge , experience and career opportunities . Agenda.

reed
Download Presentation

Indy Java User’s Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Indy Java User’s Group March 27, 2001 Sallie Mae 6:00p.m

  2. Mission Statement Promote the use of the Java language and components across all levels of interest in the greater Indianapolis area, by serving as a resource for knowledge, experience and career opportunities.

  3. Agenda • Pizza Welcome!! 6:00-6:15 • Announcements 6:15-6:30 • Joe Caron 6:30-7:30 • Quality Tip 7:30-7:45 • Performance Tip 7:45-8:00

  4. Announcements • Next Meeting - April 24, 2002 • Mike Burba – Sun ONE • Java Jam - Kurt Kirkham • Feedback Results • eGroups.yahoo.com • http://groups.yahoo.com/group/indyJug • http://groups.yahoo.com/group/indyjug_opensource • BOT Contest – Deadline March 31 • http://developer.digi-net.com

  5. Announcements • CRN – Annual Survey • 1) Call 1-800-939-6206 • 2) Ask for Amy Johnson • 3) Request your gift – • Sweatshirt • Cap • T-Shirt • Visit www.metafacts.com • Visit www.crn.com

  6. Presentation Lineup • Mark Steenbarger • Indy Jug • Joe Caron • KingArthurFlour.com • Mike Slattery • SearchSoft.net • Frank Morton • Base2Inc.com

  7. JDBC & Servlets/JSP Joe Caron Indianapolis Java Users Group March 27, 2002

  8. Database access through the web • Sample application overview • JDBC Fundamentals • Servlet/JSP Fundamentals • Implementation & sample code • Pitfalls, Surprises, Work-arounds

  9. Sample Application • Message Board • Membership Based • Pass membership info to catalogue site for “quick check-out” • Accumulate “bakers points” redeemable against online orders • Member “recipe box”

  10. Sample Application • JSP for presentation • Servlets & other java for app logic • MySQL as the RDBMS • Tomcat as Servlet/JSP container • Linux (Red Hat 6.2)

  11. Sample Application • www.bakingcircle.com • Staging Server • Entity Relationship Diagram • Application Diagram • Presentation Diagram

  12. JDBC Fundamentals • Standard means of accessing any RDBMS for which there is a JDBC driver • Drivers which implement Sun’s JDBC standard capture a DB connection as Java Object • Change DBMS without changing any application code (except driver) • Sun JDBC API overview

  13. JDBC Fundamentals • Key objects • Connection • Statement • PreparedStatement • ResultSet / Rowset • ResultSet MetaData • DB MetaData

  14. JDBC Fundamentals • Sun JDBC overview • Basic Example - MySQL • Basic Example - ORACLE • Statement vs. PreparedStatement • Stand-Alone Example • API Documentation • JDBC Optional: DataSource

  15. Servlet/JSP Fundamentals • “Servlet Container” (Tomcat, for example), working in conjunction with Web server (Apache or IIS) • Integrated in J2EE compliant server (BEA, Iplanet, Orion) • Many options regarding both the products and how to set them up

  16. Servlet/JSP FundamentalsCommon Set-Up Redirect based on conf file Web Server Servlet Engine .jsp & /servlet/ .html & others Client Common directory structure

  17. Servlet/JSP Fundamentals • Servlets like any other Java class, except: • Must extend HttpServlet • Must contain a doPost or doGet method • Come equipped to handle the laborious points of http • Http requests and responses are made into Java objects • Best alternative to traditional CGI

  18. Servlet/JSP Fundamentals • Anatomy of a Servlet • Optional init method, executes the first time a servlet is invoked • doGet/doPost methods execute when request is made • method signature accepts http request and response as parameters • Optional destroy method • www.servlets.com Samples

  19. Servlet/JSP Fundamentals • One instance of Servlet for each Servlet name • Same instance serves all requests to that name • Instance members persist across all requests to that name. • Local /block variables in doPost & doGet are unique to each request

  20. Servlet/JSP Fundamentals • Instance members vs local variables • Major request and response methods • More major request and response methods • Making use of servlet context • Keeping sessions: the bane of all Web programming

  21. JSPs: Servlets in disguise... • Better alternative for presentation. • Insert special brackets into HTML page to mark off Java code. • A JSP is compiled into a Servlet the first time it is called. • Crash course in JSP syntax

  22. JSP as presentation model Servlet Performs the hard work Helper objects Persistent “bean” objects DB Connections, etc App logic Simple calls to bean properties Client request JSP Unsuccessful results JSP Successful results Subsequent client request Presentation No servlet need if bean still set

  23. JSP alternatives • JSP can still result in unwieldy code creeping into HTML • Most HTML editors don’t like it • JSP:Taglibs and other “templating” programs may help. • Much depends on how HTML documents are produced and what business logic you are presenting

  24. In Depth Examples • Encapsulation of SQL calls • List results and view thread detail • Post reply and add to favorites • Set all bean properties w/ request • Edit users • Query central

  25. Pitfalls, surprises, and work-arounds • HTTP works via requests and responses. Client caching of responses poses a problem. • Guard against evil use of the “back” button • Don’t assume everyone’s client will respond properly to the “defaults” • Guard against easy spoofs of any GET request which alters data.

More Related