Bookmarkable JSF: PrettyFaces

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

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

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