Hi
I think this topic has been already discussed somehow. What we are
trying to do is add some information of the navigation with the page.
In JSF 2.2 we tried to add flow or navigation information to the page,
but later that idea was discarded. We also discussed about the best
place to define which views are protected or not (CSRF protection).
Please note we have all information related to normal navigation, flow
navigation and protected views already in faces-config.xml. The
problem discussed here is already something related to navigation. We
have done something to define flow navigation using CDI annotations
and code, so for this feature maybe this is no different.
An example could help. Lets suppose /books/{bookId} map to
/showBook.xhtml . If I do a navigation between some other page and
/showBook.xhtml, I hope that the link inside my other page be in the
format /books/{bookId}. This is more like a "bidirectional url
transformation", that we should apply in all places where an url is
generated.
The problem we are dealing with is JSF is a "page controller"
framework, that means it is more natural for JSF to see the flow of
the application as a set of transitions between pages. But each page
is a controller itself, so it has a lot of sense that each page has
its own set of actions (that's another topic to discuss, how to
improve JSF adding custom page/component actions).
Let's suppose we have created a view url mapping in faces-config.xml like this:
<view-mappings>
<view-mapping>
<url-pattern>/books/{bookId}</url-pattern>
<to-view-id>/showBook.xhtml</to-view-id>
</view-mapping>
</view-mappings>
And then we have this navigation case:
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>showBook</from-outcome>
<to-view-id>/showBook.xhtml</to-view-id>
</navigation-case>
</navigation-rule>
And then we have in a page a h:link like this:
<h:link outcome="showBook">
<f:param name="bookId" value="#{some EL to get the book id}"/>
</h:link>
The generated link would be
http://localhost:8080/myJSF23app/faces/books/2334
Or if we can control the mapping directly with the new Servlet 3.0 API:
http://localhost:8080/myJSF23app/books/2334
Please note in JSF markup there is no reference to the mapping. Why
the developer needs to know the structure of the URL?, what happen if
that changes? The developer doesn't need to deal with all that
complexity in every page it needs to make a url, and start changing
urls all over the place. Instead, we make use of the JSF abstraction
to build the URL in terms of an "outcome" and some "params". Just an
small entry in faces-config.xml, and JSF will take care of everything.
In the experiment I did for JSF and MVC:
https://github.com/lu4242/test-draft-actions-for-jsf
I tried this (code changed to fit to this problem):
<ma:defineLink id="renderTemplateLink" outcome="toSomePage">
<f:param name="savedValue"
value="This is something to be sent in the url"/>
</ma:defineLink>
<a href ="#{ma:getLinkFrom('renderTemplateLink')}"
target="_blank">Render plain HTML from template</a>
The idea was to add a component (ma:defineLink) that holds the
definition of the url with the same algorithm as h:link compose links.
Then, we use an EL expression to render that link based on the
definition, so we do not pollute the HTML or the Javascript. That
leads to a clean approach where we make a definition of the possible
URLs as components, and then we can write Javascript or HTML and just
add an EL function to fill the gap.
The original objective was to create links for view/component actions
inside a view, but the same approach/pattern works for this case too.
About use an specific path for views I think it has a lot of sense,
but we have already discussed that. In JSF 2.2, I warned about .xhtml
files inside resource library contracts automatically can be located
as views. .xhtml files inside flows are views too. Right now there is
no policy, and it is hard to know which files can be views or not.
But maybe we can add some configuration in faces-config.xml to deal with this:
<view-mappings>
<load-views-from-base/>false</load-views-from-base> <!-- disable
load views from / folder -->
<views-folder>
<view-folder>/WEB-INF/my-view-folder</view-folder>
<view-library>some.library.somewhere</view-library>
<view-contract>mycontract</view-contract>
</views-folder>
<view-mappings>
We can imagine something better (suggestions are welcome). I like the
idea of have a default folder to hold views, but we need an option to
disable the current approach too.
regards,
Leonardo Uribe
2014-11-03 13:59 GMT-05:00 Frank Caputo <frank_at_frankcaputo.de>:
> It was also possible by annotations as I remember.
>
> Ciao Frank
>
> Am 03.11.2014 um 18:19 schrieb Cagatay Civici <cagatay.civici_at_gmail.com>:
>
> As I remember, this was handled in pretty-config.xml
>
> Cagatay Civici
> PrimeFaces Lead
> PrimeTek Informatics
> www.primefaces.org
>
> On Monday 3 November 2014 at 19:17, Kito Mann wrote:
>
> 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
>
>
>
>
>
>
>