On Mon, Jan 18, 2016 at 9:36 AM, Xavier Dury <kalgon_at_hotmail.com> wrote:
> > What does "messed up" means?
>
> The rewriting rule is not applied at all, giving something like
> http://localhost:8080/document.xhtml?id=1 (without context name) instead
> of http://localhost:8080/appctx/document/1
>
> > What happens when you use "/foo/#{someBean.param}", which was said to be
> specifically supported?
>
> Well, I don't like to use that type of parameter.
>
Of course, I don't think many would like that.
But technically #{someBean.param} should be indistinguishable from
#{requestScope.param}. So if the former does work but the second doesn't,
it may give us an interesting data point. If #{someBean.param} also doesn't
work, it's very likely to be a PrettyFaces bug, as they seem to mention
that that would be supported.
So it would be interesting just to try it and see what happens.
> <h:outputLink value="/document.xhtml">
> <h:outputText value="link" />
> <f:param name="id" value="#{whatever.you.want}" />
> </h:outputLink>
>
A trick I used in the past was to declare a request scoped Map (using
faces-config.xml, but may use a named CDI producer as well I guess) and
then use that map. E.g.
<f:param name="id" value="#{myMap.whatever}" /> or if you prefer <f:param
name="id" value="#{myMap['whatever']}" />
Still, that *should* be the same as requestScope.whatever, but to be sure
it's one extra thing to try.
>
> ________________________________
> > Date: Mon, 18 Jan 2016 09:04:04 +0100
> > Subject: Re: JAVASERVERFACES-3939
> > From: arjan.tijms_at_gmail.com
> > To: dev_at_javaserverfaces.java.net
> >
> > On Mon, Jan 18, 2016 at 8:44 AM, Xavier Dury
> > <kalgon_at_hotmail.com<mailto:kalgon_at_hotmail.com>> wrote:
> > Incoming requests are handled fine (and without the warning) but
> > rewriting links is messed up.
> >
> > Thanks for the followup. This could potentially be a PrettyFaces issue.
> > What does "messed up" means?
> >
> > 1. Link does not render at all
> > 2. Crash / exception when link is rendered
> > 3. Wrong parameter names and/or wrong parameter values in link
> > 4. Something else?
> >
> > What happens when you use "/foo/#{someBean.param}", which was said to
> > be specifically supported?
> >
> >
> >
> > Xavier
> > ________________________________
> >> Date: Fri, 15 Jan 2016 20:21:26 +0100
> >> Subject: Re: JAVASERVERFACES-3939
> >> From: arjan.tijms_at_gmail.com<mailto:arjan.tijms_at_gmail.com>
> >> To: dev_at_javaserverfaces.java.net<mailto:dev_at_javaserverfaces.java.net>
> >>
> >> It's not a PrettyFaces bug for sure. I glanced over the code, and I'm
> >> fairly sure they just write to whatever value expression you supply. As
> >> per Christian's reply, "/foo/#{someBean.param}" works as well,
> >> so "/foo/#{requestScope.id}" should work too.
> >>
> >> The only question is whether "/foo/#{id}" doesn't trigger some special
> >> behaviour where the value after /foo/ is not just written to the value
> >> expression, but also transformed into a query parameter.
> >>
> >> At any length, just using #{name} is what triggers the scope searching,
> >> which on its turn triggers the problematic behaviour.
> >>
> >> I've to double check what the spec says about this though.
> >>
> >>
> >>
> >>
> >>
> >> On Fri, Jan 15, 2016 at 7:58 PM, Xavier Dury
> >>
> > <kalgon_at_hotmail.com<mailto:kalgon_at_hotmail.com><mailto:kalgon_at_hotmail.com
> <mailto:kalgon_at_hotmail.com>>>
> > wrote:
> >> Ok, I will try with #{requestScope.id} instead of #{id}.
> >>
> >> I originally thought it was a prettyfaces bug. If you have better
> >> arguments than me, you could still leave a comment
> >> at https://github.com/ocpsoft/rewrite/issues/208.
> >>
> >> ________________________________
> >> Date: Fri, 15 Jan 2016 19:27:13 +0100
> >>
> >> Subject: Re: JAVASERVERFACES-3939
> >> From:
> > arjan.tijms_at_gmail.com<mailto:arjan.tijms_at_gmail.com><mailto:
> arjan.tijms_at_gmail.com<mailto:arjan.tijms_at_gmail.com>>
> >> To:
> > dev_at_javaserverfaces.java.net<mailto:dev_at_javaserverfaces.java.net
> ><mailto:dev_at_javaserverfaces.java.net<mailto:dev_at_javaserverfaces.java.net
> >>
> >>
> >> Hi,
> >>
> >> On Fri, Jan 15, 2016 at 7:15 PM, Xavier Dury
> >>
> > <kalgon_at_hotmail.com<mailto:kalgon_at_hotmail.com><mailto:kalgon_at_hotmail.com
> <mailto:kalgon_at_hotmail.com>>>
> > wrote:
> >> <url-mapping id="document">
> >> <pattern value="/document/#{id}" />
> >> <view-id value="/document.xhtml" />
> >> </url-mapping>
> >>
> >> I don't think replacing #{id} with #{requestScope.id} in the
> >> prettyfaces configuration will work.
> >>
> >> Okay, so it's PrettyFaces that essentially does the write to #{id}
> >> which will end up in request scope? (I don't know PrettyFaces that
> >> well).
> >>
> >> Depending on what PrettyFaces exactly does you could try it though. If
> >> it's a general value expression where whatever comes after /document/
> >> is written to it may actually have a chance of working.
> >>
> >> I don't know if there are other places in the code where
> >> UIViewRoot.getViewMap() is being called without considering that the
> >> current view may be transient.
> >>
> >> I think the view being transient or not does not even matter that much.
> >> After all, you can also have a view that simply doesn't use a form (so
> >> no state) or have state written to the client.
> >>
> >> What (IMHO) matters most is that code, and specifically frameworks,
> >> should always be wary of accidentally creating sessions when not
> >> strictly necessary.
> >>
> >>
> >>
> >>
> >>
> >>
> >> ________________________________
> >> Date: Fri, 15 Jan 2016 17:18:57 +0100
> >> Subject: Re: JAVASERVERFACES-3939
> >> From:
> > arjan.tijms_at_gmail.com<mailto:arjan.tijms_at_gmail.com><mailto:
> arjan.tijms_at_gmail.com<mailto:arjan.tijms_at_gmail.com>>
> >> To:
> > dev_at_javaserverfaces.java.net<mailto:dev_at_javaserverfaces.java.net
> ><mailto:dev_at_javaserverfaces.java.net<mailto:dev_at_javaserverfaces.java.net
> >>
> >>
> >> Hi,
> >>
> >> On Fri, Jan 15, 2016 at 4:31 PM, Xavier Dury
> >>
> > <kalgon_at_hotmail.com<mailto:kalgon_at_hotmail.com><mailto:kalgon_at_hotmail.com
> <mailto:kalgon_at_hotmail.com>>>
> > wrote:
> >>
> >> String attribute = (String) property;
> >> FacesContext facesContext = (FacesContext)
> >> context.getContext(FacesContext.class);
> >> ExternalContext ec = facesContext.getExternalContext();
> >> if ((ec.getRequestMap().get(attribute)) != null) {
> >> ec.getRequestMap().put(attribute, val);
> >> } else if ((facesContext.getViewRoot()) != null &&
> >> (facesContext.getViewRoot().getViewMap().get(attribute)) != null) {
> >> facesContext.getViewRoot().getViewMap().put(attribute, val);
> >> } else if ((ec.getSessionMap().get(attribute)) != null) {
> >> ec.getSessionMap().put(attribute, val);
> >> } else if ((ec.getApplicationMap().get(attribute)) != null) {
> >> ec.getApplicationMap().put(attribute, val);
> >> } else {
> >> // if the property doesn't exist in any of the scopes,
> >> put it in
> >> // request scope.
> >> ec.getRequestMap().put(attribute, val);
> >> }
> >>
> >> This code seems indeed problematic. The view map is created only to
> >> check it, which not only causes an annoying warning, it also causes the
> >> creation of a session.
> >>
> >> The same thing holds for the session map check.
> >> ec.getSessionMap().get(attribute) will create a session, even when this
> >> would not be needed.
> >>
> >> For some types of applications, the needless creation of sessions is a
> >> serious problem. So regardless of the message being annoying or not, or
> >> clear or not, this session creation seems problematic to me.
> >>
> >> The question is; how strict is the spec about mandating this?
> >>
> >> Regardless, wouldn't changing the value expression mentioned in the
> >> issue to one that explicitly contains the scope work around a
> >> particular instance of this problem?
> >>
> >> E.g.
> >>
> >> ValueExpression ve = ef.createValueExpression(context.getELContext(),
> >> "#{requestScope.id}", Object.class);
> >>
> >> instead of
> >>
> >> ValueExpression ve = ef.createValueExpression(context.getELContext(),
> >> "#{id}", Object.class);
> >>
> >> ?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
>
>