Hi,
On Thu, Oct 23, 2014 at 4:39 PM, Neil Griffin
<neil.griffin_at_portletfaces.org> wrote:
> FYI, adding adding *.xhtml to the default mappings affects existing
> requirements of the JSF Portlet Bridge. Specifically, the requirements for
> ExternalContext.encodeActionURL(String), getRequestPathInfo(), and
> getRequestServletPath() in section 6.1.3.1 titled "Methods that deviate from
> Faces 1.2 Javadoc”
I'm not that familiar with Portlets, but what will change for Portlets there?
For Servlets both methods are pretty straightforward.
encodeActionURL first adds the client window parameters (if any) and
then calls straight through to HttpServletResponse.encodeURL.
getRequestPathInfo and getRequestServletPath are even simpler, as they
call directly through to HttpServletRequest.getPathInfo and
HttpServletRequest.getServletPath.
At any length the idea is thus that the default mapping will only be
altered for application that opt-in to JSF 2.3.
Maybe Portlets will then "just" need to specify a new bridge for JSF
2.3? (I know it's never that easy, but wasn't there talk about this
already?)
Kind regards,
Arjan
>
> On Oct 22, 2014, at 5:51 PM, Edward Burns <edward.burns_at_oracle.com> wrote:
>
> On Wed, 22 Oct 2014 00:03:31 +0200, arjan tijms <arjan.tijms_at_gmail.com>
> said:
>
>
> [...]
>
> AT> An optimal solution going forward and absolutely trivial to implement
> AT> is just adding *.xhtml to the default mappings. However, this may have
> AT> backwards compatibility issues and has therefor been rejected
> before.
>
> Indeed.
>
> AT> Another solution is to use the recently introduced switch, that uses a
> AT> 2.3 faces-config and/or 4.0 web.xml for possibly incompatible EL
> AT> resolving behavior, to switch between having *.xhtml as a default
> AT> mapping or not. Meaning a 2.3 faces-config.xml causes a mapping on
> AT> *.xhtml by default, any lower versioned or no faces-config keeps the
> AT> current mappings.
>
> I can see this, and it would be easy to implement in the
> ServletContainerInitializer impl. In Mojarra this is FacesInitializer.
> Can someone code up a patch for this?
>
> AT> Yet another solution, that incidentally also ties in with the
> AT> extensionless URL mappings that were discussed on this list a while
> AT> back, is to have a dedicated folder from which views are loaded.
>
> AT> This is not entirely unlike the dedicated folders for contracts and
> AT> composites that already exist today. Views in that folder would be by
> AT> definition JSF views, so the runtime can safely map them, with or
> AT> without extension. A while back I created
> AT> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1099 for this
> AT> and implemented it in OmniFaces.
>
> That sounds good too.
>
> Ed
>
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 12 work days til Devoxx 2014
>
>