jsr344-experts@javaserverfaces-spec-public.java.net

[jsr344-experts] [730-FacesFlow] Feedback

From: Rossen Stoyanchev <rstoyanchev_at_vmware.com>
Date: Thu, 15 Nov 2012 19:22:11 -0800 (PST)

Hi,

Phil and I had a look at the FacesFlow samples and have some feedback to provide. Of course much of our experience is based on Spring Web Flow and we hope that this perspective will be useful to the group!

One observation is with regards to access to flow scoped data. When using the provided buttons, everything works as it should, i.e. flow scoped data is created at the point of entering the flow and destroyed when the flow is exited. However, it is easy to bypass the entry and exit points. For example I can go directly to a page associated with a flow without entering the flow, and if the page tries to access flow data, the result would be ContextNotActiveException. I experimented by typing a URL in the browser and one might argue that I should not do that but the point is it's possible. Reversely while on a page within an active flow X, it is possible to navigate to a page outside flow X without leaving the flow, possibly navigating to a page associated with flow Y, while still being able to access data from flow X. Maybe this is intentional? It does make it difficult to reason about access to flow data in the context of an active flow, without an active flow, or of some other flow.

A second question is about what defines the navigation rules of a flow? In a number of examples, flow definitions don't contain navigation rules. Instead command buttons have actions that point to other pages. This is a convenient convention but the end result is that the flow definition does not encapsulate all navigation rules, nor can it enforce them. For example a shopping cart followed by shipping options and then payment options must be navigated in that order. Note that this point relates closely to the previous point above where a page associated with a flow can be reached directly without formally entering the flow, i.e. nothing enforces what's possible in terms of navigation.

Are there plans as part of the FacesFlow feature to ensure that the URL in the browser matches the current page and not the one the user came from?

Regarding the use of a window id, access to flow scoped data is nicely separated from different browser tabs. However, if I copy and paste the current URL into a new tab, chances are that my tab already has a window id assigned I will copy it over. Then the two tabs are accessing the same data. Apologies if this has been discussed already or accounted for but I thought it should be mentioned.

When flows are defined under the web application's root, I can easily access their source from a browser which is a security concern. I can see there is an example that puts the flow definition under WEB-INF but the pages are still under the web application root and hence the flow is in two different places. It would be useful to be able to keep a flow with all its files in a folder under WEB-INF.

A relatively minor point that view states seem to require a vdl-document sub-element even if they're the same:
<j:view id="create-customer">
    <j:vdl-document>create-customer.xhtml</j:vdl-document>
</j:view>

Regards,
Rossen