Robert Liguori wrote:Simply put, I would like to load default filters into a PrimeFaces datatable.
Note that I do change/set the filters in the backing bean, though all my attempts to get the datatable to refresh with the new filters against a (commandButton press) or futile.
--> dataTable.setFilters(filters); // New HashMap < String, Object >
Any suggestions or working code samples to share?
Default filter values for datatable
How to load a Primefaces datatable with default filters?
How is a p:datatable updated from a managed bean?
oncomplete="PF('facilityRecordsTable').filter();" not working
setting default value in primefaces datatable Filter
Rob Spoor wrote:Do you need to have getTags and setTags as Lists and not as Strings?
The value that's set by the UI is a String (or some other version of CharSequence), and your setTag method only accepts a List. I'd either change the two methods to return/accept String, or overload setTag to also take a String:
Tim Holloway wrote:IDE code generators are dangerous things. They allow people who don't know what they're doing to create stuff that's limited to just what the generator knows how to do. In the real world, sooner or later someone is going to say, "but could you just add this one small thing...?" and it all goes to perdition. So much for being able to hire cheap untrained monkeys because the IDE generates their code for them.
While we're nitpicking: You - or the code generator - don't write Controllers in JSF. In JSF Controllers are supplied pre-written, pre-debugged as part of JSF itself. Or, for PrimeFaces elements, as part of PrimeFaces. Backing beans are not Controllers, they are Models.
There is a time and a place for an actionListener, but it's so rare that in nearly a decade of working with JSF, I cannot recall any apps I've got that use them. A regular (POJO) action method is far preferable to an actionListener.
The way JSF works is that the View Template (xhtml) is rendered by JSF to produce and present an HTML web page containing one or more HTML FORMs loaded with JSF context data as well as the rendered template controls and the values that those controls reference in the backing bean(s). When a FORM is submitted, it goes through the JSF lifecycle under the control of the JSF Master Controller (FacesServlet), which causes the form data to be validated (and rejected, if invalid), the backing bean property values to be updated (using the sub-Controllers defined by JSF or PrimeFaces for the individual input controls), and then the action method is called from the FacesServlet. You do not move data to/from the Model to the View via user-written (or IDE-generated) logic. As I said, JSF's Controllers do that automatically. That's what Controllers do. Nothing more, nothing less.
The action method is a simple POJO method. It can then invoke any database code it wishes. JSF is not in the database business, so any database logic or constructs are strictly the business of the backing bean, which is a POJO.
In my webapps, there are generally 2 levels of persistence. The high-level persistence that allows me to combine inter-related table objects into a working transaction and the low-level persistence that does table-at-a-time persistence (DAO). The high-level persistence ("service") methods are equivalent to EJB Session EJBs, but I'm commonly using JPA, so that's the closest equivalent.
The actual GUI Model object (backing bean) may or may not contain the business logic in its action methods. For complex apps, I separate out the business logic into a layer of its own between the GUI Model layer and the Persistence Service layer. In that case, the action methods invoke methods in the business layer and there's typically no persistence logic in the backing bean itself.
Akaine Harga wrote:Ok. I didn't understand you the first time because I did not see two inputs, just one.
The problem you have is related to how JSF works. The command button by default submits only the form it resides in. So to be able to update the "view model" submitting both values, both inputs have to be inside the form where the command button is. Once you have the managed bean's variables updated the rest is trivial. The correct xhtml code would be:
I see you use Primefaces namespace. In this case you can specify the input fields or the wrapper element that contains the input fields you want to submit by specifying the partialSubmit="true" and process="listOfIdsOfTheElementsToSubmit" (http://www.primefaces.org/showcase/ui/ajax/partialSubmit.xhtml). This ca help you minimize the data sent to the server in case you have more input fields in the same form.
On the other hand it sounds pretty strange to me you want to submit a "hardcoded" value in the first place. By looking at your example I can see it comes from the managed bean. Why don't you just use it as a local variable inside the managed bean itself instead of submitting it, since the hardcoded value won't change anyway.
Btw, what are you trying to do in general? Is this some kind of combo field simulation?
Tim Holloway wrote:Just a bit of nit-picking. You do not write Controllers in JSF. The primary Controller in JSF is the FacesServlet and the sub-controllers are pre-supplied in the JSF tag implementations. You only code View Templates and Models. Action methods and such within Models are not Controller code (they don't do the Controller's function of transferring values between Model and View), but are instead additional code outside of the MVC domain.
Also, it's bad practice to use underscores in Java names, even though it's legal. The general convention - for better or worse - is camelCase, and some tools may malfunction if they have to deal with unconventional names.
JSF entities are exactly the same thing as J2EE entities, except that JSF automatically constructs them if they don't exist when needed. So you can inject a servlet-created Session object into a Managed Bean, no problem, and no need to rummage around in JSF internal data structures to locate it.
Other than that, my technical term for user-designed login systems is "hacked", based on experience with many, many systems over the years. Most user-designed security is, in fact, so flimsy that an unskilled person can often bypass them in under 15 minutes. J2EE comes with a professionally-designed security subsystem and associated APIs that can repel a lot of attacks before they can even get near the webapp itself. It has been around for probably over 15 years and thus is well-proven. I recommend using it.