Hi
+1 for url mapping/rewriting. It is just something too useful to ignore.
+1 for make a better javascript library for jsf.
The list of problems with the current jsf.js file that comes to my mind are:
- It is not possible to override or extend jsf.js. Tool vendors cannot
customize this part, or they just bypass it and implement its own
javascript api, which at the end cause incompatibility problems
between javascript components. The most common case is all ajax
request should be send through a queue, so the state does not get
broken.
- Lack of callbacks on custom ajax request.
- Lack of a standard way to initialize jsf javascript (set properties
like development/production mode and other flags, but in a global
way).
- No standard way to define which javascript files should be loaded first.
But before continue talking in this thread, shouldn't we create
separate threads to discuss each feature we want to include in JSF
2.3? There is a lot of things to discuss, but it is important to keep
focus on the ones that receive most attention or the topics that are
more relevant for the scope of the new spec.
regards,
Leonardo Uribe
2014-10-14 18:02 GMT-05:00 arjan tijms <arjan.tijms_at_gmail.com>:
> Hi,
>
> On Tue, Oct 14, 2014 at 8:55 PM, Neil Griffin
> <neil.griffin_at_portletfaces.org> wrote:
>> In addition, the PrettyFaces servlet filter causes an issue with the JSF 2.2
>> h:inputFile component in Tomcat:
>> http://stackoverflow.com/questions/8047173/how-to-enable-multipart-form-data-in-tomcat-7-0-8-server/8050589#8050589
>>
>> I think that whatever we define for url mapping should not rely on servlet
>> filters.
>
> The problems with Servlet Filters and specifically forwards (which if
> I'm not mistaken is what PrettyFaces uses exclusively) are rather well
> understood I think.
>
> In OmniFaces we also took a stab at solving this issue (simple
> extensionless views, not elaborate arbitrary mappings) with our
> FacesViews feature. Next to the Filter and Forward approach that
> PrettyFaces and a couple of others use, we have another approach (it's
> the default since OmniFaces 1.4 actually). With this approach we do an
> upfront scanning of the available top level Facelets, and use the
> Servlet 3.0 programmatic mapping feature to programmatically do a
> "Servlet exact mapping" (i.e. mapping without patterns) of each
> encountered Facelet on the FacesServlet.
>
> We do use a Filter anyway, but it's to wrap the request in order to
> fool JSF that it's a normal request (otherwise it's prefix/suffix
> mapping heuristics would fail).
>
> If this was done within the core JSF implementation then obviously no
> Filter to fool itself would be needed. I've documented the approach
> here: http://omnifaces.org/docs/javadoc/1.8/org/omnifaces/facesviews/package-summary.html
> and posted an article about it here:
> http://arjan-tijms.omnifaces.org/2013/03/easy-extensionless-urls-in-jsf-with.html
>
> Related to this is a Servlet issue I created some time ago that asks
> for the Servlet container to reveal the mapping they chose to
> interpret the incoming URL. The container of course has this
> information, while JSF has to use complicated heuristics to reverse
> engineer it. See https://java.net/jira/browse/SERVLET_SPEC-73
>
> Specifically with Ed as the co-spec lead on Servlet I hope
> SERVLET_SPEC-73 can be given some serious consideration.
>
> Kind regards,
> Arjan
>
>
>
>
>
>
> Also, it would need a flexible API that the JSF Portlet Bridge can
>> use to integrate with portal-vendor-specific friendly URLs.
>>
>>
>> Best Regards to all,
>>
>> Neil
>>
>> On Oct 14, 2014, at 1:28 PM, Cagatay Civici <cagatay.civici_at_gmail.com>
>> wrote:
>>
>> Hi Cagatay,
>>
>> I'd also like to see some url mapping stuff as a big ticket. I've done this
>> for a customer and it is really not so complicated to implement. I will
>> share the ideas (which are basically borrowed from PrettyFaces) after my
>> holidays in 2 weeks.
>>
>> Ciao Frank
>>
>> Great, looking forward to hearing your feedback.
>>
>> Cagatay Civici
>> PrimeFaces Lead
>> PrimeTek Informatics
>> www.primefaces.org
>>
>> On Tuesday 14 October 2014 at 20:25, Frank Caputo wrote:
>>
>> Hi Cagatay,
>>
>> I'd also like to see some url mapping stuff as a big ticket. I've done this
>> for a customer and it is really not so complicated to implement. I will
>> share the ideas (which are basically borrowed from PrettyFaces) after my
>> holidays in 2 weeks.
>>
>> Ciao Frank
>>
>> Am 13.10.2014 um 15:37 schrieb Cagatay Civici <cagatay.civici_at_gmail.com>:
>>
>> Hi,
>>
>> We need 2 or 3 big ticket features in JSF 2.3.
>>
>> My big ticket offer would be related to url mapping.
>>
>> For example app/user/ maps to WEBAPP/pages/userpages/user.xhtml
>>
>> I don’t think it is very hard to do in terms of implementation as well.
>>
>> Would be good to have a configuration by exception just like the rest of
>> Java EE by following a certain convention of mapping.
>>
>> Regards,
>>
>> Cagatay Civici
>> PrimeFaces Lead
>> PrimeTek Informatics
>> www.primefaces.org
>>
>> On Monday 13 October 2014 at 16:22, Bauke Scholtz wrote:
>>
>> Hi,
>>
>> How about a native push component using websockets which is new since Java
>> EE 7?
>>
>> Cheers, Bauke
>>
>> On Oct 13, 2014 3:00 PM, "Josh Juneau" <juneau001_at_gmail.com> wrote:
>>
>> I listened to the audio from the expert group meeting at JavaOne. I
>> apologize again that I could not make it due to one of my talks being
>> scheduled at the same time. That said, it seemed as though the meeting went
>> very well, and I was happy to hear that there are others (Neil in
>> particular) that also would like to see at least one big ticket item for JSF
>> 2.3.
>>
>> I feel that it is important to have at least one feature that will catch the
>> attention of the community...mainly because such features help to maintain
>> the visibility of technologies. If there are no big ticket items in 2.3,
>> then it may be overlooked by some, making it look like JSF is becoming a
>> waning technology...falling to the single-page frameworks, or being pushed
>> aside for the MVC initiative. We all know that JSF is still widely used and
>> excellent at what it does, but I think JSF needs to remain highly visible
>> with the 2.3 release as the leading server-side web framework for Java EE,
>> especially given that there are a couple of years between each release.
>>
>> Maybe the big feature could be the "decorate response" phase that was
>> mentioned in the meeting, or even "increased support for HTTP 2.0", covering
>> the dispatch priority concerns. Perhaps better integration with single-page
>> frameworks, as addressed in Ian's presentation?
>>
>> Thanks for your time, I appreciate it.
>>
>> Josh Juneau
>> juneau001_at_gmail.com
>> http://jj-blogger.blogspot.com
>> https://www.apress.com/index.php/author/author/view/id/1866
>>
>>
>>
>>