Hi Arjan,
we should provide some Java API, where one can register programmatically the mappings. This API can then be called, by the custom ResourceHandler.
Ciao Frank
Am 03.11.2014 um 23:13 schrieb arjan tijms <arjan.tijms_at_gmail.com>:
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>