1 / 39

Case Study: The Design of a JSP Framework

Case Study: The Design of a JSP Framework. By Michael Alford malford@orbitz.com March 29, 2001. Acknowledgments. Xqsite, Inc. Zak Jacobson John Koszarek Nick.Vujasin Greg Skudlarick Orbitz LLC. Web Development. Forces. Quick and easy development Simple to maintain High performance.

dahlia
Download Presentation

Case Study: The Design of a JSP Framework

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. Case Study: The Design of a JSP Framework By Michael Alford malford@orbitz.com March 29, 2001

  2. Acknowledgments • Xqsite, Inc. • Zak Jacobson • John Koszarek • Nick.Vujasin • Greg Skudlarick • Orbitz LLC

  3. Web Development

  4. Forces • Quick and easy development • Simple to maintain • High performance

  5. Quick and Easy Development • Just get the damn thing out the door! • Engineers vary widely in skill/experience. • Make common case very simple. • Make difficult stuff easy to plug in. • Mismatch: Graphic artists work visually, while engineers work with code. • Reuse previously written code.

  6. Simple to Maintain • Low complexity. • Easily extensible with use of patterns. • Easily configurable. • Straightforward to debug & monitor. • Judicious logging. • Don’t impair app server tools.

  7. High Performance • Instantiate as few objects as possible. • Cache reusable objects. • Avoid Java reflection. • Minimize synchronization. • Minimize indirection. • Minimize dynamic content.

  8. Common Practices

  9. Custom Tags • <html:iterate collection=“aList” > <html:valueOf obj=“anObject” /> • </html:iterate/> • Tag Handler • Java code • Evaluates custom tags • Properties • pageContext • parent tag

  10. Benefits of Custom Tags • Eliminate Java code from HTML. • Greater separation of content from presentation. • Promote consistency across site. • Reusable within context of a website.

  11. Liabilities of Custom Tags • Designers cannot work visually. • Inefficient iterative back-and-forth between designer and developer. • Custom modules for visual tool? • Closely tied to HTML, limiting reusability. • Lower performance versus embedded code. • No industry standard set of tags.

  12. JSP Model 2(Model-View-Controller variant)

  13. Benefits of MVC • Multiple views of same model. • Pluggable views and controllers. • Separation of development tasks. • Reuse potential. • Frameworks potential.

  14. Liabilities of MVC • Increased complexity. • Close coupling between view & controller. • Close coupling of views & controllers to a model. • Difficulty of using MVC with some web development tools.

  15. Document-View • Combine View and Controller • MVC variant • Java Swing’s UIDelegate

  16. Xqsite Page Architecture Core Classes

  17. Design Goals • Fast to develop for the common tasks. • Even at the cost of flexibility. • Most of a website is specific to a project. • Simple. • Pluggable services for the hard stuff. • JSP 1.0.

  18. Architectural Overview

  19. Page • Container of Fields • Mediator between View and Business Layer • The “use bean” tag in JSP is simple and easy to use.

  20. Page Benefits • Standardizes development team on a common design. • Automates validation and formatting of various types of data. • Automates required field handling. • Extensible - add new field types or services without modifying existing architecture. • Provides file uploading services. • Easily configurable page-specific, field-specific, and locale-specific error messages; can even use a properties file.

  21. Page: Init & Control • <jsp:useBean id="pageObject" • scope="request" • class="yourPageSubclass"> • pageObject.onLoad(pageContext); • </jsp:useBean> • onLoad • Calls initFields • Calls business layer depending on whether this is first view or a submission of form data.

  22. Page: Example OnLoad With Validation • public void onLoad(PageContext pageContext) throws Exception { • super.onLoad(pageContext); • // Check if submit button was pressed • if (isButtonSelected("createAccount")) { • // Process the state when createAccount is clicked • if (isFormValid()) { • // call business objects here • } • } • if (isButtonSelected("cancel")) { • // Process the state when cancel is clicked • redirect("/location/of/maybe/the/previous/page"); • } • else { • // User’s initial visit or reload of page • // Typically do nothing here • } • }

  23. Submit form back to JSP • <form name=“myForm" action="<%= request.getServletPath() %>" method="POST">

  24. Page: Buttons • Radio buttons • <input type="radio" name="salutation" value="mrs" <%= page.getButtonSelected("salutation", "mrs") %>> • Checkboxes • <input type="checkbox" name=“factor" value="10" <%= page.getButtonSelected(“factor", "10") %>>

  25. Page: Text Field and Error Messages • String getErrorMessage(String key, String fieldName) • String getRequiredMessage(String fieldName) • JSP: • <input type="text" name=“lastName" size="20" maxlength="40" value='<%= page.getFieldValue(“lastName") %>' required="true"> • <%=page.getErrorMessage(page.MESSAGE_FIELD_MISSING, “lastName")%>

  26. Field Abstract Class • abstract void validate(); • boolean isRequired(); • boolean isValid(); • read/write properties: • Name • Description • Value • Invalid and Missing Messages

  27. Field Subclasses • ButtonField • DateField • NumericField • SelectField • TextField

  28. Xqsite Page Architecture Minimizing the Designer/Engineer Conflict

  29. PageGenerator • Uses the HTML Parser sunlabs.brazil.handler.HtmlRewriter • For every HTML page, creates a subclass of Page. • For every HTML input field, adds a Field to the Page subclass. • Stubs out the onLoad method of Page subclass. • Creates JSP with most of the necessary code to access the Page.

  30. HTML Layer Requirements • Each input field must be named uniquely. • Add a fieldType attribute to those fields that need to be specified less generically. • Will not adversely affect visual HTML editors. • Example: HTML Text field may have a fieldType attribute of DateField. • Add a required attribute for those fields that the user is required to enter.

  31. Xqsite Page Architecture Service Delegation

  32. Interceptor Pattern • “Allows services to be added transparently to a framework and triggered automatically when certain events occur.” • Services are defined in a config file, and registered upon app startup. • Page class onLoad acts as central dispatcher, passing a Context object to services.

  33. Context control • Context object provides accessors for services to retrieve state information. • Context object provides mutators so that services may modify request. • Example: Authorization service forwards user to a login page by setting target on Context object.

  34. Possible Services • File upload • Configuration • Authorization/Authentication • Throttling • Logging • 3rd-Party Integration

  35. Applying Page Concepts to Current Industry Practices

  36. Adopt Custom Tags • All Field subclasses can be made into custom tag handlers. • PageGenerator creates a JSP of custom tags instead of embedded Java code.

  37. Adopt MVC • Eliminate Page in favor of FrontController • Make FrontController a Interceptor dispatcher. • If using Struts, PageGenerator can create an ActionForm.

  38. Other Java-based Web Frameworks • Struts • WebMacro and Velocity • HyperQbs • Janx • WebWork • Cocoon (XSP) • Resin (XTP) • Brazil

  39. References Crupi, Malks, Alur, Core J2EE Patterns, or http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/ Gamma, et al.,(aka Gang of Four), Design Patterns Buschmann, et al., Pattern-Oriented Software Architecture; A System of Patterns Schmidt, et al., Pattern-Oriented Software Architecture; Patterns for Concurrent and Networked Objects Struts Framework, http://jakarta.apache.org/struts

More Related