Hi Leonardo,
yes scanning is needed, but IMO no problem. This is a minimal performance issue, because you do it only once.
Ciao Frank
Am 02.11.2014 um 23:16 schrieb Leonardo Uribe <leonardo.uribe_at_irian.at>:
> 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
>>
>>
>>
>>
>>
>