In general it would be great to introduce it but then we have to think about what happens with ExternalContext and Porlet Integration in future.
Its not nice when we have a API (ExternalContext) for Portlet and Servlet and then directly Import servlet stuff.
I feel ExternalContext might have been an over-abstraction. Unless I'm really missing something here, why can't Portlet implementations provide an HttpServletRequest implementation that behaves in whatever way is needed for Portlets and throw UnsupportedExceptions for any thing it really can't support? Essentially that is what ExternalContext now does anyway, but just using a different type. I understand there's a potential difference regarding the UnsupportedExceptions, but still.
It may have been a good idea at the start, but going forward we may just be duplicating the existing API without good reasons.
To me it feels a little like the hype in mid 90s (for those who remember :P) where you coded your application to be abstract of the UI toolkit that was being used. Most of the times you ended up just duplicating any existing UI toolkit within the app.
Maybe the solution is for Servlet and Portlet to come up with better base-interfaces so ExternalContext.getRequest() can return something a little bit more meaningful than just Object.
Maybe we should ask NeilNeil Griffin to chime in.
Not sure he is on this mailing list.
I assumed he was, but I'll cc him in.
For now, for Mojarra, I can use HttpServletMapping internally using the utility method that we're now using to calculate the mapping. That particular Mojarra version would then not be Porlet compatible, but as it's Faces 4, and there's no bridge for that, it would not be compatible anyway for now. A later Mojarra version for Faces 4 could then always be made compatible again.
Btw, the overal goal is to slim down the code by better taking advantage of functionality in other APIs without going through so many layers of abstractions.
Kind regards,
Arjan
Manfred Riem wrote on Mon 30 Aug 20:38:
> +1 -- All for simplifying any Faces API
Thanks! So I'm thinking about starting with a FacesContext.getHttpServletRequest(), AND/OR ExternalContext.getHttpServletRequest().
For the AND case, specify that FacesContext gets HttpServletRequest from ExternalContext, so Portlet integrators still only have to provide an ExternalContext implementation. They do have to return an HttpServletRequest implementation then.
Kind regards,
Arjan
Hi,
For Mojarra we have an open TODO to utilize the HttpServletMapping from Servlet:
However, as usual Portlets prevent direct usage.
Now we could move getHttpServletMapping() to ExternalContext, but the type it returns is in Servlet too. Wrapping that again in Faces specific types is a little against making the code simpler. Things will get more complicated and tedious again.
Maybe it's time to move to supporting HttpServletRequest only and ask whatever technology that integrates with Faces to supply an HttpServletRequest to Faces, whether it's actually Servlet or not?
Thoughts?
Kind regards,
Arjan
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
faces-dev mailing list
faces-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/faces-dev
