I am curious, why if I have several <url-mapping>’s with different id, but mapped to the same view-id, all the <h:link>’s with outcome with any of this url-mapping ID’s would result in anchor that is referencing to the FIRST url-mapping?
<pattern value=”/page1″ />
<pattern value=”/page2″ />
<h:link outcome=”pretty:id2″ value=”link” /> would result in “/page1”!!! WHY?
the problem is that there is now way for us to find out what mapping this h:link is referring to. I think in most cases there is only one PrettyFaces mapping for a view. So the outbound rewriting works well in nearly all cases.
If you want more control over the link generated, I suggest to take a look at the pretty:link component:
Correct. In order to integrate with the JSF navigation system, PrettyFaces must replace the “pretty:id2” value with “/page” before the link is rendered. After the link is rendered, PrettyFaces then attempts to perform outbound rewriting on “/link”, for which it finds mapping “id1”
However, we could actually do something a bit tricky here, and try to “embed” some metadata into the view-id if outbound rewriting is enabled, something like:
This would then be removed by prettyfaces when the outbound rewrite occurs in PrettyFacesWrappedResponse, resulting in:
However, I’m not really sure how safe this would be, since it is quite hack-ish.
Interesting idea. Theoretically this would be possible. But I think we should use the query-parameter-like syntax that is already used in JSF when returning something like /view?faces-redirect=true&includeViewParams=true.
So we could use something like this: /view?com.ocpsoft.mappingid=srcMappingId.