On Sun, Nov 2, 2014 at 5:38 PM, 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>
It looks nice, but I wonder if you have given any thought to how JSF
should discover the patterns?
In OmniFaces we partially solved the issue by having a dedicated
folder from which views are loaded (WEB-INF/faces-views/), with an
option to specify additional locations within the web archive. The
same idea can be used to scan views that directly reside within jar
files (convention and ability to specify a location).
One complication is that views may also be "hidden" behind a
ResourceHandler, which may do its own mapping instead of just fetching
views 1:1 from some location. When such ResourceHandler is used, it's
not really possible to scan the views it provided access to upfront.
Maybe a solution for that last problem could be to have a method on a
ResourceHandler that enumerates all resources that are behind a
ResourceHandler? (if said ResourceHandler is capable of doing this,
the operation can not be mandated of course).
Kind regards,
Arjan
>
> 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
>
>
>
>