Hi,
On Mon, Nov 3, 2014 at 7:53 PM, Frank Caputo <frank_at_frankcaputo.de> wrote:
> the idea was to let the developer create the mapping just by adding the
> view. It is always annoying, if one has to touch another file.
I agree with this. The pattern where meta data is specified with the
artifact to which it applies instead of in some central file certainly
looks to be the most popular way now (see also my recent mail to this
list regarding 1196-faceletTagConveniences). Just think of the URL
specified in @WebServlet for Servlets or @Path for JAX-RS.
Yet, as with almost all such meta data, an override in a central (XML)
file should be possible as well. And of course this very same file can
also be the primary source of the mappings; it should not be required
that it has to override an existing meta data section in a view. I
think that with such setup we can address both Kito's and Frank's use
case, can't we?
Kind regards,
Arjan
>
> Ciao Frank
>
> Am 03.11.2014 um 18:17 schrieb Kito Mann <kito.mann_at_virtua.com>:
>
> I wonder about spreading the patterns throughout all of the files. I like
> the idea of handling this in one place..
>
> How does PrettyFaces do this?
>
> On Sun, Nov 2, 2014 at 11:38 AM, Frank Caputo <frank_at_frankcaputo.de> 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
>>
>>
>>
>>
>
>