Hi,
On Mon, Nov 3, 2014 at 9:57 AM, Frank Caputo <frank_at_frankcaputo.de> wrote:
> yes scanning is needed, but IMO no problem. This is a minimal performance issue, because you do it only once.
Indeed, I don't really worry about that either.
But I haven't seen an answer yet to the question about how to handle
views that are resolved via a ResourceHandler. Any ideas how to do
that?
Kind regards,
Arjan
>
> 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
>>>
>>>
>>>
>>>
>>>
>>
>