• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Bookmarkable JSF: PrettyFaces
 

Bookmarkable JSF: PrettyFaces

on

  • 11,910 views

An analysis of JSF bookmarking frameworks, and a proposed new solution.

An analysis of JSF bookmarking frameworks, and a proposed new solution.

Statistics

Views

Total Views
11,910
Views on SlideShare
7,404
Embed Views
4,506

Actions

Likes
2
Downloads
91
Comments
2

8 Embeds 4,506

http://ocpsoft.com 2824
http://ocpsoft.org 1655
http://www.slideshare.net 15
http://translate.googleusercontent.com 8
http://64.233.163.132 1
http://www.lmodules.com 1
http://webcache.googleusercontent.com 1
http://www.linkedin.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

12 of 2 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Bookmarkable JSF: PrettyFaces Bookmarkable JSF: PrettyFaces Presentation Transcript

      • Agenda:
      • Goals and desired behavior
      • Standard JSF Behavior
      • Discussing JBoss Seam, PrettyURLPhaseListener, and RestFaces behavior
      • Proposing PrettyFaces
      An analysis of bookmarking & navigation techniques, and a proposal for a new solution. Making JSF “Pretty” ? ?
      • Methods of Navigation:
      • HTTP Links: <a href=“/bookmarkable/page/33”>link</a>
      • HTTP Forms: <form action=“/submit/here”>…</form>
      • Server side redirect (From either of the above)
      • Goals of our web-framework:
      • Achieve bookmarkable URLs
      • Minimize traffic and processing required per request
      • Minimize response time (faster is better)
      • Minimize java code (reduce the need to handle HTTP data manually, let JSF backing beans do the work)
      • Make it easy for developers, intuitive
      Goals and Desired behavior JSF Navigation
    • 1. Client requests /faces/page.jsf 2. Server renders /faces/page.jsf Web Client JSF App Server Before: Client URL: N/A Client viewing: N/A After: Client URL: /faces/page.jsf Client viewing: /faces/page.jsf Step 1: Initial Request Standard JSF Navigation
      • Client submits form to /faces/page.jsf
      2. Server processes navigation and renders /faces/page2.jsf Before: Client URL: /faces/page.jsf Client viewing: /faces/page.jsf After: Client URL: /faces/page.jsf Client viewing: /faces/page2.jsf Web Client JSF App Server Notice: client’s address bar does not match content displayed on the page. Step 2: Form Postback With Validation or Simple Navigation (no redirect) Standard JSF Navigation
    • Web Client JSF App Server
      • Client submits form to /faces/page.jsf
      2. Server processes navigation and sends redirect to /faces/page2.jsf Two requests means additional bandwidth, response time, and CPU-utilization. 4. Server renders /faces/page2.jsf 3. Client submits request for /faces/page2.jsf Step 2: Alternate… Form post-back With redirect navigation to preserve view Id Standard JSF Navigation Before: Client URL: /faces/page.jsf Client viewing: /faces/page.jsf After: Client URL: /faces/page2.jsf Client viewing: /faces/page2.jsf
    • 1. Client requests /mapped/page 2. Server renders /faces/page.jsf Web Client JSF App Server Before: Client URL: N/A Client viewing: N/A After: Client URL: /mapped/page Client viewing: /faces/page.jsf (Eg: PrettyUrlPhaseListener, RestFaces, JBoss Seam, …) Step 1: Initial Request (Eg: PrettyUrlPhaseListener, RestFaces, JBoss Seam, …) Mapped JSF Navigation
    • <html> <body> <form action=“/faces/page.jsf”> … </form> </body> </html> /mapped/page Web Client Before: Client URL: N/A Client viewing: N/A After: Client URL: /mapped/page Client viewing: /faces/page.jsf (Eg: PrettyUrlPhaseListener, RestFaces, JBoss Seam, …) Rendered Output (Eg: PrettyUrlPhaseListener, RestFaces, JBoss Seam, …) Mapped JSF Navigation Since JSF does not render the mapped URL, and instead renders the JSF view ID. After form submit, the URL will no longer be bookmarkable, or “pretty.”
    • 1. Client submits form to /faces/page.jsf 2. Server processes navigation and renders new view Web Client JSF App Server Before: Client URL: /mapped/page Client viewing: /faces/page.jsf After: Client URL: /faces/page.jsf Client viewing: /faces/page.jsf or /faces/page2.jsf (Eg: PrettyUrlPhaseListener, RestFaces, JBoss Seam, …) Form post-back with validation or navigation (Eg: PrettyUrlPhaseListener, RestFaces, JBoss Seam, …) Mapped JSF Navigation: ( Without) Redirect URL Rewriting Pattern Notice: On validation, the client’s URL will no longer be the mapped URL, and on navigation the URL will not reflect the current view.
      • Pros:
      • Only one request/response required to render output
      • Simple to implement (JSF does it for you)
      • Cons:
      • URL is no longer bookmarkable
      • Physical JSP directory structure and location are exposed to client
      • Any parameters parsed out of mapped URL are lost, and must be manually submitted with the form in order to preserve GET URI information
        • E.g. A value of:
        • /mapped/project/ 24 /
        • must now be included in form input data, and either manually mapped to a backing bean, or manually retrieved from request parameter map.
      (E.g.: PrettyUrlPhaseListener, RestFaces, JBoss Seam, …) Pros / Cons Mapped JSF Navigation: ( Without) Redirect URL Rewriting Pattern
    • Web Client JSF App Server Before: Client URL: /mapped/page Client viewing: /faces/page.jsf After: Client URL: /mapped/page Client viewing: /faces/page.jsf (Eg: PrettyUrlPhaseListener, RestFaces, JBoss Seam, …) Form postback with validation or navigation (Eg: PrettyUrlPhaseListener, RestFaces, JBoss Seam, …) Mapped JSF Navigation: ( With) Redirect URL Rewriting Pattern
      • Client submits form to /faces/page.jsf
      2. Server processes navigation and sends redirect to /mapped/page Again, with this solution, we have wasted bandwidth, even if we redisplay the same page. 4. Server renders /mapped/page 3. Client submits request for /mapped/page
    • (E.g.: PrettyUrlPhaseListener, RestFaces, JBoss Seam, …) Pros / Cons Mapped JSF Navigation: ( With) Redirect URL Rewriting Pattern
      • Pros:
      • URL remains bookmarkable
      • URL parameter information is preserved
      • Cons:
      • Physical JSP directory structure and location are still exposed to client in <form action” /faces/exposed/page.jsf ”>
      • A second request/response is required
        • Increased load on server
        • Increased bandwidth
        • Increased response time to client
      • Difficult to implement
    • <html> <body> <form action=“/mapped/page”> … </form> </body> </html> /mapped/page Web Client Before: Client URL: /mapped/page Client viewing: /faces/page.jsf After: Client URL: /mapped/page Client viewing: /faces/page.jsf PrettyFaces (Use the mapped URL as the form action) Mapped JSF Navigation: Proposed Solution Using the mapped page URL as the form action, instead of the JSF view ID, and doing conversion on the server, we solve several of our problems.
    • 1. Client submits form to /mapped/page 2. Server processes navigation and renders new view Web Client JSF App Server Before: Client URL: /mapped/page Client viewing: /faces/page.jsf After: Client URL: /mapped/page Client viewing: /faces/page.jsf or /faces/page2.jsf Notice: The client’s URL will remain correct even after failed validation, or navigation back to the same page. PrettyFaces (Use the mapped URL as the form action) Mapped JSF Navigation: Proposed Solution
      • Pros:
      • URL remains bookmarkable
      • URL parameter information is preserved
      • Redirect is not required for validation, or in cases where no navigation occurs (client stays on same page)
      • Cons:
      • Additional configuration
      • New framework to learn
      • Not compatible with existing frameworks?
      PrettyFaces (Pros/Cons) Mapped JSF Navigation: Proposed Solution
    • pretty-config.xml <pretty-config> <url-mapping id=“viewProject”> <pattern> /project/#{viewProjectBean.projectId}/ </pattern> <view-id> #{viewProjectBean.getPrettyTarget} --or-- /faces/viewProject.jspx </view-id> <action method=“#{viewProjectBean.loadData}” /> <post-to-jsf-view /> </url-mapping> </pretty-config> PrettyFaces pretty-config.xml Mapped JSF Navigation: Proposed Solution Prevent manual link generation by using values in mapped EL property to generate dynamic URLs. Specify method(s) to be called after URL params are parsed Allow dynamic specification of view ID, for decoupling of URL from view Enable disabling of pretty-POST
    • PrettyFaces References Mapped JSF Navigation: Proposed Solution