I have started learning JSF, but sadly most tutorials out there present only a log in or a register section.
Can you point me to some more in depth examples? One thing I'm interested in is a page presenting a list of products. I'm on page home and I press on page products so that I can see the latest products added. And every time I visit the page, the product list will be created from the latest entries in the database. How can I handle this?
One way to solve this would be to create a session scoped managed bean in which I would place different entities updated through other managed beans. I found this kind of approach in some tutorials, but it seems quite difficult and clumsy.
Which would be the best approach to solve a thing like this? What is the correct usage of session scope in two-page master-detail user interface?
Use it for session scoped data only, nothing else. For example, the logged-in user, its settings, the chosen language, etcetera.
See also:
Typically you use the request or view scope for it. Loading of the list should happen in a
@PostConstruct
method. If the page doesn't contain any<h:form>
, then the request scope is fine. A view scoped bean would behave like a request scoped when there's no<h:form>
anyway.All "view product" and "edit product" links/buttons which just retrieve information (i.e. idempotent) whould be just plain GET
<h:link>
/<h:button>
wherein you pass the entity identifier as a request parameter by<f:param>
.All "delete product" and "save product" links/buttons which will manipulate information (i.e. non-idempotent) should perform POST by
<h:commandLink>
/<h:commandButton>
(you don't want them to be bookmarkable/searchbot-indexable!). This in turn requires a<h:form>
. In order to preserve the data for validations and ajax requests (so that you don't need to reload/preinitialize the entity on every request), the bean should preferably be view scoped.Note that you should basically have a separate bean for each view and also note that those beans doesn't necessarily need to reference each other.
So, given this "product" entity:
And this "product service" EJB:
You can have this "view products" on
/products.xhtml
:And you can have this "edit product" on
/products/edit.xhtml
:And this converter for
<f:viewParam>
of "edit product":See also:
As a small improvement to what BalusC recommended, sometimes you can remove the
required
/requiredMessage
part from the<f:viewParam>
of your "details" screen and instead use the conditional rendering of the editing form (as BalusC did) with a reverse condition for recommending a specific link for the "list/master" screen or, even use a viewAction that would test the param and force a redirect to that list.