jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [jsr372-experts mirror] Re: Url mapping

From: Leonardo Uribe <leonardo.uribe_at_irian.at>
Date: Sun, 2 Nov 2014 17:16:39 -0500

Hi

Try something like <f:view id="bookDetails" pattern="/books/{bookId}"
...> could cause a problem, because this requires to compile and scan
every jsf page to build the mapping logic. The reason is JSF needs to
know where the mapping goes to on the incoming request. If that logic
is on a faces-config.xml or a bean annotated class sounds better.

regards,

Leonardo Uribe

2014-11-02 16:32 GMT-05:00 Cagatay Civici <cagatay.civici_at_gmail.com>:
> Hi,
>
> We should also consider mapping multiple patterns to the same page, having a
> single pattern attribute might not allow this. f:pattern maybe?
>
> Also a faces-config.xml based configuration could be an alternative, maybe
> both where faces-config takes precedence.
>
> Regards,
>
> Cagatay Civici
> PrimeFaces Lead
> PrimeTek Informatics
> www.primefaces.org
>
> On Sunday 2 November 2014 at 18:38, Frank Caputo wrote:
>
> Hi Experts,
>
> the idea was to define the url directly in the markup and reuse as much as
> possible from JSF:
>
> <f:view id="bookDetails" pattern="/books/{bookId}">
> <f:metadata>
> <f:viewParam name="bookId" value="#{books.bookId}" required="true"/>
> </f:metadata>
> </f:view>
>
> Using the f:viewParam here has the advantage of getting validation and
> converters from JSF. If validation fails, I sent a 404. One drawback is that
> you might need the parameters right after the ApplyRequestValuesPhase, so
> validation and model updates must be done immediately in the
> ApplyRequestValuesPhase.
>
> The id of the view was registered in the navigation handler, so that you
> could use:
>
> <h:link outcome="bookDetails">
> <f:param name="bookId" value="147"/>
> The book
> </h:link>
>
> Comments are welcome.
>
> Ciao Frank
>
> Am 14.10.2014 um 19:28 schrieb Cagatay Civici <cagatay.civici_at_gmail.com>:
>
> 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
>
>
>
>
>