First off, Gavin I wanted to say thanks for all the improvements to pages.xml since 1.0. Even though my patch didn't make it in (JBSEAM-397), it's great to see most of the functionality there. I do have a couple of questions about how it's all been implemented though.
In my experience most pages within a specific conversation seem to match a wildcard (say /cart/*) where one of the pages in that group (say /cart/view.jsf) is responsible for starting the conversation. In my head this would translate into:
<page view-id="/cart/*" conversation-required="true" no-conversation-view-id="/cart/view.xhtml"/>
<page view-id="/cart/view.xhtml" conversation-required="false">
<begin-conversation join="true"/>
</page>
The way Pages is implemented however, since pages are processed individually starting with the worst match, the conversation-required attribute on the wildcard forces a redirect before the conversation can be begun by the more specific match. When I put my patch together I had laid out pages in a parent child relationship so that single parameters like conversation-required could be overridden by more specific matches and multiple parameters like action could still be processed worst match first. It makes more sense to me that way and I noticed at least one other poster with a similar problem regarding login-required. I'm not saying that my way was better, but could we find a compromise between the two? It seems like the ability to override wildcards would be useful in mutliple circumstances.
I am willing to submit another patch, but I wanted to see what others thought and gauge how well it would be accepted before I do.
Thanks.
