Wanna install linux on a vacuum cleaner. Could anyone tell me which distro sucks better?
willCodeForFood("Java,PHP,C#,XML,VBS,XHTML,CSS,JavaScript,SQL"); //always looking for job opportunities in AU/NZ/US/CA/Europe :P
Wanna install linux on a vacuum cleaner. Could anyone tell me which distro sucks better?
willCodeForFood("Java,PHP,C#,XML,VBS,XHTML,CSS,JavaScript,SQL"); //always looking for job opportunities in AU/NZ/US/CA/Europe :P
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
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: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.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Don't get me started about those stupid light bulbs. |