Re: [Shale] Property in ViewController Backing Bean is null
Hi again, I tried the whole weekend, but I didn't get any results other than those mentioned in the email below. Shall I send some code to illustrate the problem or is it really so unusual, what I'm trying to do? Thanks a lot for any help! Peter Good morning Craig, thank you, I think I'm making a progress with your help. I set the immediate flag to true for my commandButton, and my method gets executed as I wanted it to do. In the edit method I set an attribute of the backing bean to its correct value (the person that should be edited in the form), and this attribute is set correctly (in the prerender method I see its correct values). But the form is not being filled with the values. I read the chapter about the lifecycle of a JSF page in the J2EE tutorial, but didn't find the information where to tweak the application to set the actual form values. In my opinion this should happen in the Update Model Values phase, and that this phase has to be executed, when no errors occurs at validating the request parameters. But it seems this is not the case. Could you please help me again and push me in the right direction? Thanks a lot, I will name my first child after you, if my wife doesn't complain. :) Have a nice weekend! Peter Craig McClanahan wrote: On 2/10/06, Peter Goetz [EMAIL PROTECTED] wrote: Hello Craig, thank you very much, I didn't know that the action method is not executed when a validation error occurs. That seems to be the problem, because all of my form input fields are required fields and the messages get filled. Is there a way to skip validation on some actions? I would like to validate the form when submitting it, but not when I select one item in a list to fill the form with. Or is it standard behaviour to extract such data tables to an extra form in the .jsp? Thank you very much, what I wrote so far in this group is really excellent! The standard approach to doing this is to mark the commands you want to work this way with immediate=true. This causes the corresponding action to fire immediately :-) ... during the Apply Request Values phase of the request processing lifecycle, which comes *before* Process Validations. The most common use case for this is a Cancel button ... you don't want to have your validations executed if you're cancelling the input. But the same principle applies to your scenario. Good night! Peter Craig Craig McClanahan wrote: One thing to double check is whether some validation rules are failing, which would cause the action method call to get bypassed. The simplest way to verify this is to add an h:messages component to your page, which will display any validation messages that exist, or nothing if there were no messages. It's also possible that an exception is getting eaten somewhere along the way ... check the log file of your servlet container as well for any stack traces. Craig On 2/10/06, Peter Goetz [EMAIL PROTECTED] wrote: Hi there! I'm new to Struts, to Shale and to this list, so excuse if I'm asking dumb questions. I have a simple .jsp (personmaintenance.jsp), backed by a backing bean (PersonMaintenance.class. In the jsp I have buttons with actions save, edit, delete, create, for which I defined the corresponding methods in the backing bean. The backing bean has two attributes, a person (for the form to edit) and a persons Collection for an overview table. When calling the jsp (personmaintenance.faces), everything is fine. The Collection gets filled from the database, the person attribute is null. Unfortunately if I hit one of the buttons edit or delete, the corresponding method is not being called. If the person attribute is filled from the start, everything works fine. Can somebody tell me what to do to get the methods executed when I hit the button and the argument is null? Or am I missing something elementary? Thanks a lot! Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Property in ViewController Backing Bean is null
From: Peter Goetz [EMAIL PROTECTED] Hi again, I tried the whole weekend, but I didn't get any results other than those mentioned in the email below. Shall I send some code to illustrate the problem or is it really so unusual, what I'm trying to do? Make sure that you have a navigation rule setup to handle the immediate command button. Try adding a rule that directs you to the target viewid (sounds like the page you are submitting from). If you don't have a navigation case, I think the veiw is just restored using the submitted values. navigation-rule from-view-id/somepage.jsp/from-view-id navigation-case from-outcomeedit/from-outcome to-view-id/somepage.jsp/to-view-id /navigation-case /navigation-rule Thanks a lot for any help! Peter Gary
Re: [Shale] Property in ViewController Backing Bean is null
I think you may running into a simular problem that I ran into. I have the following scenario: page 1 has the user choose from a list of options. On page 2, the form saves the selected option of page 1 in a hidden field in its form. In addition the selected value from page 1 is used to populate a pull down on page 2. So the user hits the submit button on page 2 to save the changes and KA-BLAMMO, I get a NPE. What was happening was the JSF was attempting to Validate the pulldown values in the Validation phase. This was before any of the hidden fields were set. So because the hidden fields weren't set, the retrieve of the pulldown was failing. I saw 1 of 2 solutions: 1) Turn off the validation of the pulldown. Because, hey... why would I need to validate a pulldown? - it isn't like a user can mistype something. OR 2) somehow get the hidden fields to be set before any retrieval of the pulldown is made. The JSF mailing list from Sun gave no help for turning off the validator for the pulldown. So I had to do the following, for which I give myself a big Capital H for HACK. In the contructor of the backing bean, I grabbed the request parameters myself and called the setters from there for the values that were needed to get through the validation of the pulldown. Perhaps someone here can help turn off the need to retrieve the pulldown values in the validation phase. I hope this will help your situation, as well. Cheers, Jason On 2/14/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Peter Goetz [EMAIL PROTECTED] Hi again, I tried the whole weekend, but I didn't get any results other than those mentioned in the email below. Shall I send some code to illustrate the problem or is it really so unusual, what I'm trying to do? Make sure that you have a navigation rule setup to handle the immediate command button. Try adding a rule that directs you to the target viewid (sounds like the page you are submitting from). If you don't have a navigation case, I think the veiw is just restored using the submitted values. navigation-rule from-view-id/somepage.jsp/from-view-id navigation-case from-outcomeedit/from-outcome to-view-id/somepage.jsp/to-view-id /navigation-case /navigation-rule Thanks a lot for any help! Peter Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Re: [Shale] Property in ViewController Backing Bean is null
Hi Jason, I'm a real newbie to JSF and Shale, but maybe the tip that Craig gave me about setting the immediate flag in the commandbutton could help you. Then validation is skipped, as far as I understood it. This helped me with my first problem. Maybe you can use it, too. Then you could remove the H. :) Greetings, Peter I think you may running into a simular problem that I ran into. I have the following scenario: page 1 has the user choose from a list of options. On page 2, the form saves the selected option of page 1 in a hidden field in its form. In addition the selected value from page 1 is used to populate a pull down on page 2. So the user hits the submit button on page 2 to save the changes and KA-BLAMMO, I get a NPE. What was happening was the JSF was attempting to Validate the pulldown values in the Validation phase. This was before any of the hidden fields were set. So because the hidden fields weren't set, the retrieve of the pulldown was failing. I saw 1 of 2 solutions: 1) Turn off the validation of the pulldown. Because, hey... why would I need to validate a pulldown? - it isn't like a user can mistype something. OR 2) somehow get the hidden fields to be set before any retrieval of the pulldown is made. The JSF mailing list from Sun gave no help for turning off the validator for the pulldown. So I had to do the following, for which I give myself a big Capital H for HACK. In the contructor of the backing bean, I grabbed the request parameters myself and called the setters from there for the values that were needed to get through the validation of the pulldown. Perhaps someone here can help turn off the need to retrieve the pulldown values in the validation phase. I hope this will help your situation, as well. Cheers, Jason On 2/14/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Peter Goetz [EMAIL PROTECTED] Hi again, I tried the whole weekend, but I didn't get any results other than those mentioned in the email below. Shall I send some code to illustrate the problem or is it really so unusual, what I'm trying to do? Make sure that you have a navigation rule setup to handle the immediate command button. Try adding a rule that directs you to the target viewid (sounds like the page you are submitting from). If you don't have a navigation case, I think the veiw is just restored using the submitted values. navigation-rule from-view-id/somepage.jsp/from-view-id navigation-case from-outcomeedit/from-outcome to-view-id/somepage.jsp/to-view-id /navigation-case /navigation-rule Thanks a lot for any help! Peter Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Re: [Shale] Property in ViewController Backing Bean is null
Hello Gary! [...] Make sure that you have a navigation rule setup to handle the immediate command button. Try adding a rule that directs you to the target viewid (sounds like the page you are submitting from). If you don't have a navigation case, I think the veiw is just restored using the submitted values. navigation-rule from-view-id/somepage.jsp/from-view-id navigation-case from-outcomeedit/from-outcome to-view-id/somepage.jsp/to-view-id /navigation-case /navigation-rule I tried your tip yesterday and it seems to do the trick. Thank you very much! Until then my action methods were void, because I didn't know that you have to have navigation to get the jsf reloaded complete. I thought Well, it's being reloaded, so everythings all right. I will try this further tonight at home, but I think that was the missing link for me to get really startet with Shale. Thanks a lot and keep up the good work here, I really start to like Shale. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Property in ViewController Backing Bean is null
Good morning Craig, thank you, I think I'm making a progress with your help. I set the immediate flag to true for my commandButton, and my method gets executed as I wanted it to do. In the edit method I set an attribute of the backing bean to its correct value (the person that should be edited in the form), and this attribute is set correctly (in the prerender method I see its correct values). But the form is not being filled with the values. I read the chapter about the lifecycle of a JSF page in the J2EE tutorial, but didn't find the information where to tweak the application to set the actual form values. In my opinion this should happen in the Update Model Values phase, and that this phase has to be executed, when no errors occurs at validating the request parameters. But it seems this is not the case. Could you please help me again and push me in the right direction? Thanks a lot, I will name my first child after you, if my wife doesn't complain. :) Have a nice weekend! Peter Craig McClanahan wrote: On 2/10/06, Peter Goetz [EMAIL PROTECTED] wrote: Hello Craig, thank you very much, I didn't know that the action method is not executed when a validation error occurs. That seems to be the problem, because all of my form input fields are required fields and the messages get filled. Is there a way to skip validation on some actions? I would like to validate the form when submitting it, but not when I select one item in a list to fill the form with. Or is it standard behaviour to extract such data tables to an extra form in the .jsp? Thank you very much, what I wrote so far in this group is really excellent! The standard approach to doing this is to mark the commands you want to work this way with immediate=true. This causes the corresponding action to fire immediately :-) ... during the Apply Request Values phase of the request processing lifecycle, which comes *before* Process Validations. The most common use case for this is a Cancel button ... you don't want to have your validations executed if you're cancelling the input. But the same principle applies to your scenario. Good night! Peter Craig Craig McClanahan wrote: One thing to double check is whether some validation rules are failing, which would cause the action method call to get bypassed. The simplest way to verify this is to add an h:messages component to your page, which will display any validation messages that exist, or nothing if there were no messages. It's also possible that an exception is getting eaten somewhere along the way ... check the log file of your servlet container as well for any stack traces. Craig On 2/10/06, Peter Goetz [EMAIL PROTECTED] wrote: Hi there! I'm new to Struts, to Shale and to this list, so excuse if I'm asking dumb questions. I have a simple .jsp (personmaintenance.jsp), backed by a backing bean (PersonMaintenance.class. In the jsp I have buttons with actions save, edit, delete, create, for which I defined the corresponding methods in the backing bean. The backing bean has two attributes, a person (for the form to edit) and a persons Collection for an overview table. When calling the jsp (personmaintenance.faces), everything is fine. The Collection gets filled from the database, the person attribute is null. Unfortunately if I hit one of the buttons edit or delete, the corresponding method is not being called. If the person attribute is filled from the start, everything works fine. Can somebody tell me what to do to get the methods executed when I hit the button and the argument is null? Or am I missing something elementary? Thanks a lot! Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Property in ViewController Backing Bean is null
Hello Craig, thank you very much, I didn't know that the action method is not executed when a validation error occurs. That seems to be the problem, because all of my form input fields are required fields and the messages get filled. Is there a way to skip validation on some actions? I would like to validate the form when submitting it, but not when I select one item in a list to fill the form with. Or is it standard behaviour to extract such data tables to an extra form in the .jsp? Thank you very much, what I wrote so far in this group is really excellent! Good night! Peter Craig McClanahan wrote: One thing to double check is whether some validation rules are failing, which would cause the action method call to get bypassed. The simplest way to verify this is to add an h:messages component to your page, which will display any validation messages that exist, or nothing if there were no messages. It's also possible that an exception is getting eaten somewhere along the way ... check the log file of your servlet container as well for any stack traces. Craig On 2/10/06, Peter Goetz [EMAIL PROTECTED] wrote: Hi there! I'm new to Struts, to Shale and to this list, so excuse if I'm asking dumb questions. I have a simple .jsp (personmaintenance.jsp), backed by a backing bean (PersonMaintenance.class. In the jsp I have buttons with actions save, edit, delete, create, for which I defined the corresponding methods in the backing bean. The backing bean has two attributes, a person (for the form to edit) and a persons Collection for an overview table. When calling the jsp (personmaintenance.faces), everything is fine. The Collection gets filled from the database, the person attribute is null. Unfortunately if I hit one of the buttons edit or delete, the corresponding method is not being called. If the person attribute is filled from the start, everything works fine. Can somebody tell me what to do to get the methods executed when I hit the button and the argument is null? Or am I missing something elementary? Thanks a lot! Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Shale] Property in ViewController Backing Bean is null
On 2/10/06, Peter Goetz [EMAIL PROTECTED] wrote: Hello Craig, thank you very much, I didn't know that the action method is not executed when a validation error occurs. That seems to be the problem, because all of my form input fields are required fields and the messages get filled. Is there a way to skip validation on some actions? I would like to validate the form when submitting it, but not when I select one item in a list to fill the form with. Or is it standard behaviour to extract such data tables to an extra form in the .jsp? Thank you very much, what I wrote so far in this group is really excellent! The standard approach to doing this is to mark the commands you want to work this way with immediate=true. This causes the corresponding action to fire immediately :-) ... during the Apply Request Values phase of the request processing lifecycle, which comes *before* Process Validations. The most common use case for this is a Cancel button ... you don't want to have your validations executed if you're cancelling the input. But the same principle applies to your scenario. Good night! Peter Craig Craig McClanahan wrote: One thing to double check is whether some validation rules are failing, which would cause the action method call to get bypassed. The simplest way to verify this is to add an h:messages component to your page, which will display any validation messages that exist, or nothing if there were no messages. It's also possible that an exception is getting eaten somewhere along the way ... check the log file of your servlet container as well for any stack traces. Craig On 2/10/06, Peter Goetz [EMAIL PROTECTED] wrote: Hi there! I'm new to Struts, to Shale and to this list, so excuse if I'm asking dumb questions. I have a simple .jsp (personmaintenance.jsp), backed by a backing bean (PersonMaintenance.class. In the jsp I have buttons with actions save, edit, delete, create, for which I defined the corresponding methods in the backing bean. The backing bean has two attributes, a person (for the form to edit) and a persons Collection for an overview table. When calling the jsp (personmaintenance.faces), everything is fine. The Collection gets filled from the database, the person attribute is null. Unfortunately if I hit one of the buttons edit or delete, the corresponding method is not being called. If the person attribute is filled from the start, everything works fine. Can somebody tell me what to do to get the methods executed when I hit the button and the argument is null? Or am I missing something elementary? Thanks a lot! Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
