Re: REST Showcase 2.1.2
Scott, Annotations serve a very useful purpose, and unless you're using a JRE less than version 5 they're worth the effort. I didn't think they were worth it until I had an opportunity to write a Struts2/Hibernate app from scratch and saw how it moved a lot of the config from a dis-associated file into the relevant section of the code. Al. P.S. As for your sister... well if it's some you want to do I won't hold you making a choice between the two. Wes Wannemacher wrote: What's wrong with annotations, and more importantly - How hot is your sister?! (sorry, couldn't resist) -Wes On Mon, 2008-09-01 at 08:57 -0500, [EMAIL PROTECTED] wrote: Thanks Jeromy -- I'd rather sleep with my sister than embed annotations in my code. This notwithstanding, I understand your reluctance to add yet another permutation to that lookup scheme. I poked around in the code back in 2.0 and nearly got a nose bleed. I hope there are a ton of unit tests around that baby! I'm getting the feeling that REST is not ready for prime time. I too wondered why it was excluding edit, editNew. I'm sure there was a reason. Peace, Scott On Mon, Sep 1, 2008 at 8:09 AM, Jeromy Evans [EMAIL PROTECTED] wrote: stanlick wrote: Also, what is the naming convention for validation xml files using the Code Behind/REST plug-in? I've tried several combinations of naming, but none seem to work. The short answer is: you can't. It doesn't work. Fortunately annotation validation works correctly in 2.1, so the approach I've used is: - the action carries validation annotations on the applicable methods; - the model's use XML validation as they can be used together and it's well suited to ModelDriven. The problem is that the DefaultValidatorFileParser in Xwork that reads the XML file has no way to specify which method it should be applied to. It applies to the entire class. With wildcards in 2.0 you could get around this because the action alias included the method name. It's the same reason using method='update' spefied in struts.xml never worked properly with XML validation. The parameter was ignored by the XML validator. This had always frustrated me. Fortunately somebody fixed the annotation interceptor so it can distinguish between the methods being executed. Unfortunately that fix (validateAnnotatedMethodOnly) is not enabled by the rest plugin by default. Further compounding the problem is that rest plugin has disabled validation for the edit, editNew and other relevant methods. (I'm not sure why...there must have been a reason for that). What I've done is replace the rest default stack with one that includes the validation interceptor with better configuration: interceptor-ref name=validation param name=excludeMethodsinput,back,cancel,browse,index/param param name=validateAnnotatedMethodOnlytrue/param /interceptor-ref interceptor-ref name=restWorkflow param name=excludeMethodsinput,back,cancel,browse,index/param /interceptor-ref I've been tempted to delve in a fix this but so far I've stayed out of xwork. The rest plugin does the right thing setting up the ActionInvocation with the action name and method name; the XML validation config reader just needs to use the method name to select the file (eg. to load OrdersControler-action-method-validation.xml if it exists). But I feel it already searches for far too many combinations, so I've been reluctant to touch it. stanlinck also wrote: Would you share the interceptor stack to fold paramsPrepareParamsStack capabilities into the restDefaultStack? I haven't experimented with this much with the rest plugin as I try to avoid it . It's reasonable logical... The actionMappingParams interceptor is the one responsible for setting the id, so it needs to appear before the prepare interceptor. If you need other params, before prepare, you also need params before prepare. The actionMappingParams and params are then required after prepare again. ie. set the id, load the object, set the id and params It's different because the ActionMapper obtained the id from URI. If you use other variables in the namespace you also need this interceptor before prepare. Hope that helps, Jeromy Evans - 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] -- Al Sutton W: www.alsutton.com B: alsutton.wordpress.com T: twitter.com/alsutton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Showcase 2.1.2
Al Sutton wrote: Scott, Annotations serve a very useful purpose, and unless you're using a JRE less than version 5 they're worth the effort. Similar thoughts here. I found using validation annotations within actions and XML validation for models (visitor validation) was a good compromise. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Showcase 2.1.2
stanlick wrote: Also, what is the naming convention for validation xml files using the Code Behind/REST plug-in? I've tried several combinations of naming, but none seem to work. The short answer is: you can't. It doesn't work. Fortunately annotation validation works correctly in 2.1, so the approach I've used is: - the action carries validation annotations on the applicable methods; - the model's use XML validation as they can be used together and it's well suited to ModelDriven. The problem is that the DefaultValidatorFileParser in Xwork that reads the XML file has no way to specify which method it should be applied to. It applies to the entire class. With wildcards in 2.0 you could get around this because the action alias included the method name. It's the same reason using method='update' spefied in struts.xml never worked properly with XML validation. The parameter was ignored by the XML validator. This had always frustrated me. Fortunately somebody fixed the annotation interceptor so it can distinguish between the methods being executed. Unfortunately that fix (validateAnnotatedMethodOnly) is not enabled by the rest plugin by default. Further compounding the problem is that rest plugin has disabled validation for the edit, editNew and other relevant methods. (I'm not sure why...there must have been a reason for that). What I've done is replace the rest default stack with one that includes the validation interceptor with better configuration: interceptor-ref name=validation param name=excludeMethodsinput,back,cancel,browse,index/param param name=validateAnnotatedMethodOnlytrue/param /interceptor-ref interceptor-ref name=restWorkflow param name=excludeMethodsinput,back,cancel,browse,index/param /interceptor-ref I've been tempted to delve in a fix this but so far I've stayed out of xwork. The rest plugin does the right thing setting up the ActionInvocation with the action name and method name; the XML validation config reader just needs to use the method name to select the file (eg. to load OrdersControler-action-method-validation.xml if it exists). But I feel it already searches for far too many combinations, so I've been reluctant to touch it. stanlinck also wrote: Would you share the interceptor stack to fold paramsPrepareParamsStack capabilities into the restDefaultStack? I haven't experimented with this much with the rest plugin as I try to avoid it . It's reasonable logical... The actionMappingParams interceptor is the one responsible for setting the id, so it needs to appear before the prepare interceptor. If you need other params, before prepare, you also need params before prepare. The actionMappingParams and params are then required after prepare again. ie. set the id, load the object, set the id and params It's different because the ActionMapper obtained the id from URI. If you use other variables in the namespace you also need this interceptor before prepare. Hope that helps, Jeromy Evans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Showcase 2.1.2
Thanks Jeromy -- I'd rather sleep with my sister than embed annotations in my code. This notwithstanding, I understand your reluctance to add yet another permutation to that lookup scheme. I poked around in the code back in 2.0 and nearly got a nose bleed. I hope there are a ton of unit tests around that baby! I'm getting the feeling that REST is not ready for prime time. I too wondered why it was excluding edit, editNew. I'm sure there was a reason. Peace, Scott On Mon, Sep 1, 2008 at 8:09 AM, Jeromy Evans [EMAIL PROTECTED] wrote: stanlick wrote: Also, what is the naming convention for validation xml files using the Code Behind/REST plug-in? I've tried several combinations of naming, but none seem to work. The short answer is: you can't. It doesn't work. Fortunately annotation validation works correctly in 2.1, so the approach I've used is: - the action carries validation annotations on the applicable methods; - the model's use XML validation as they can be used together and it's well suited to ModelDriven. The problem is that the DefaultValidatorFileParser in Xwork that reads the XML file has no way to specify which method it should be applied to. It applies to the entire class. With wildcards in 2.0 you could get around this because the action alias included the method name. It's the same reason using method='update' spefied in struts.xml never worked properly with XML validation. The parameter was ignored by the XML validator. This had always frustrated me. Fortunately somebody fixed the annotation interceptor so it can distinguish between the methods being executed. Unfortunately that fix (validateAnnotatedMethodOnly) is not enabled by the rest plugin by default. Further compounding the problem is that rest plugin has disabled validation for the edit, editNew and other relevant methods. (I'm not sure why...there must have been a reason for that). What I've done is replace the rest default stack with one that includes the validation interceptor with better configuration: interceptor-ref name=validation param name=excludeMethodsinput,back,cancel,browse,index/param param name=validateAnnotatedMethodOnlytrue/param /interceptor-ref interceptor-ref name=restWorkflow param name=excludeMethodsinput,back,cancel,browse,index/param /interceptor-ref I've been tempted to delve in a fix this but so far I've stayed out of xwork. The rest plugin does the right thing setting up the ActionInvocation with the action name and method name; the XML validation config reader just needs to use the method name to select the file (eg. to load OrdersControler-action-method-validation.xml if it exists). But I feel it already searches for far too many combinations, so I've been reluctant to touch it. stanlinck also wrote: Would you share the interceptor stack to fold paramsPrepareParamsStack capabilities into the restDefaultStack? I haven't experimented with this much with the rest plugin as I try to avoid it . It's reasonable logical... The actionMappingParams interceptor is the one responsible for setting the id, so it needs to appear before the prepare interceptor. If you need other params, before prepare, you also need params before prepare. The actionMappingParams and params are then required after prepare again. ie. set the id, load the object, set the id and params It's different because the ActionMapper obtained the id from URI. If you use other variables in the namespace you also need this interceptor before prepare. Hope that helps, Jeromy Evans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Showcase 2.1.2
Someone should update the REST plug-in docs so others don't waste days trying something that WILL NOT work as designed. Validation permutations can be tricky enough without chasing a dead end. On Mon, Sep 1, 2008 at 8:57 AM, [EMAIL PROTECTED] wrote: Thanks Jeromy -- I'd rather sleep with my sister than embed annotations in my code. This notwithstanding, I understand your reluctance to add yet another permutation to that lookup scheme. I poked around in the code back in 2.0 and nearly got a nose bleed. I hope there are a ton of unit tests around that baby! I'm getting the feeling that REST is not ready for prime time. I too wondered why it was excluding edit, editNew. I'm sure there was a reason. Peace, Scott On Mon, Sep 1, 2008 at 8:09 AM, Jeromy Evans [EMAIL PROTECTED] wrote: stanlick wrote: Also, what is the naming convention for validation xml files using the Code Behind/REST plug-in? I've tried several combinations of naming, but none seem to work. The short answer is: you can't. It doesn't work. Fortunately annotation validation works correctly in 2.1, so the approach I've used is: - the action carries validation annotations on the applicable methods; - the model's use XML validation as they can be used together and it's well suited to ModelDriven. The problem is that the DefaultValidatorFileParser in Xwork that reads the XML file has no way to specify which method it should be applied to. It applies to the entire class. With wildcards in 2.0 you could get around this because the action alias included the method name. It's the same reason using method='update' spefied in struts.xml never worked properly with XML validation. The parameter was ignored by the XML validator. This had always frustrated me. Fortunately somebody fixed the annotation interceptor so it can distinguish between the methods being executed. Unfortunately that fix (validateAnnotatedMethodOnly) is not enabled by the rest plugin by default. Further compounding the problem is that rest plugin has disabled validation for the edit, editNew and other relevant methods. (I'm not sure why...there must have been a reason for that). What I've done is replace the rest default stack with one that includes the validation interceptor with better configuration: interceptor-ref name=validation param name=excludeMethodsinput,back,cancel,browse,index/param param name=validateAnnotatedMethodOnlytrue/param /interceptor-ref interceptor-ref name=restWorkflow param name=excludeMethodsinput,back,cancel,browse,index/param /interceptor-ref I've been tempted to delve in a fix this but so far I've stayed out of xwork. The rest plugin does the right thing setting up the ActionInvocation with the action name and method name; the XML validation config reader just needs to use the method name to select the file (eg. to load OrdersControler-action-method-validation.xml if it exists). But I feel it already searches for far too many combinations, so I've been reluctant to touch it. stanlinck also wrote: Would you share the interceptor stack to fold paramsPrepareParamsStack capabilities into the restDefaultStack? I haven't experimented with this much with the rest plugin as I try to avoid it . It's reasonable logical... The actionMappingParams interceptor is the one responsible for setting the id, so it needs to appear before the prepare interceptor. If you need other params, before prepare, you also need params before prepare. The actionMappingParams and params are then required after prepare again. ie. set the id, load the object, set the id and params It's different because the ActionMapper obtained the id from URI. If you use other variables in the namespace you also need this interceptor before prepare. Hope that helps, Jeromy Evans - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Showcase 2.1.2
Become the change you desire. http://struts.apache.org/helping.html#documentation Dave --- On Mon, 9/1/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: REST Showcase 2.1.2 To: Struts Users Mailing List user@struts.apache.org Date: Monday, September 1, 2008, 10:03 AM Someone should update the REST plug-in docs so others don't waste days trying something that WILL NOT work as designed. Validation permutations can be tricky enough without chasing a dead end. On Mon, Sep 1, 2008 at 8:57 AM, [EMAIL PROTECTED] wrote: Thanks Jeromy -- I'd rather sleep with my sister than embed annotations in my code. This notwithstanding, I understand your reluctance to add yet another permutation to that lookup scheme. I poked around in the code back in 2.0 and nearly got a nose bleed. I hope there are a ton of unit tests around that baby! I'm getting the feeling that REST is not ready for prime time. I too wondered why it was excluding edit, editNew. I'm sure there was a reason. Peace, Scott On Mon, Sep 1, 2008 at 8:09 AM, Jeromy Evans [EMAIL PROTECTED] wrote: stanlick wrote: Also, what is the naming convention for validation xml files using the Code Behind/REST plug-in? I've tried several combinations of naming, but none seem to work. The short answer is: you can't. It doesn't work. Fortunately annotation validation works correctly in 2.1, so the approach I've used is: - the action carries validation annotations on the applicable methods; - the model's use XML validation as they can be used together and it's well suited to ModelDriven. The problem is that the DefaultValidatorFileParser in Xwork that reads the XML file has no way to specify which method it should be applied to. It applies to the entire class. With wildcards in 2.0 you could get around this because the action alias included the method name. It's the same reason using method='update' spefied in struts.xml never worked properly with XML validation. The parameter was ignored by the XML validator. This had always frustrated me. Fortunately somebody fixed the annotation interceptor so it can distinguish between the methods being executed. Unfortunately that fix (validateAnnotatedMethodOnly) is not enabled by the rest plugin by default. Further compounding the problem is that rest plugin has disabled validation for the edit, editNew and other relevant methods. (I'm not sure why...there must have been a reason for that). What I've done is replace the rest default stack with one that includes the validation interceptor with better configuration: interceptor-ref name=validation param name=excludeMethodsinput,back,cancel,browse,index/param param name=validateAnnotatedMethodOnlytrue/param /interceptor-ref interceptor-ref name=restWorkflow param name=excludeMethodsinput,back,cancel,browse,index/param /interceptor-ref I've been tempted to delve in a fix this but so far I've stayed out of xwork. The rest plugin does the right thing setting up the ActionInvocation with the action name and method name; the XML validation config reader just needs to use the method name to select the file (eg. to load OrdersControler-action-method-validation.xml if it exists). But I feel it already searches for far too many combinations, so I've been reluctant to touch it. stanlinck also wrote: Would you share the interceptor stack to fold paramsPrepareParamsStack capabilities into the restDefaultStack? I haven't experimented with this much with the rest plugin as I try to avoid it . It's reasonable logical... The actionMappingParams interceptor is the one responsible for setting the id, so it needs to appear before the prepare interceptor. If you need other params, before prepare, you also need params before prepare. The actionMappingParams and params are then required after prepare again. ie. set the id, load the object, set the id and params It's different because the ActionMapper obtained the id from URI. If you use other variables in the namespace you also need this interceptor before prepare. Hope that helps, Jeromy Evans - 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: REST Showcase 2.1.2
Thank you Yoda. :) On Mon, Sep 1, 2008 at 9:10 AM, Dave Newton [EMAIL PROTECTED] wrote: Become the change you desire. http://struts.apache.org/helping.html#documentation Dave --- On Mon, 9/1/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: Re: REST Showcase 2.1.2 To: Struts Users Mailing List user@struts.apache.org Date: Monday, September 1, 2008, 10:03 AM Someone should update the REST plug-in docs so others don't waste days trying something that WILL NOT work as designed. Validation permutations can be tricky enough without chasing a dead end. On Mon, Sep 1, 2008 at 8:57 AM, [EMAIL PROTECTED] wrote: Thanks Jeromy -- I'd rather sleep with my sister than embed annotations in my code. This notwithstanding, I understand your reluctance to add yet another permutation to that lookup scheme. I poked around in the code back in 2.0 and nearly got a nose bleed. I hope there are a ton of unit tests around that baby! I'm getting the feeling that REST is not ready for prime time. I too wondered why it was excluding edit, editNew. I'm sure there was a reason. Peace, Scott On Mon, Sep 1, 2008 at 8:09 AM, Jeromy Evans [EMAIL PROTECTED] wrote: stanlick wrote: Also, what is the naming convention for validation xml files using the Code Behind/REST plug-in? I've tried several combinations of naming, but none seem to work. The short answer is: you can't. It doesn't work. Fortunately annotation validation works correctly in 2.1, so the approach I've used is: - the action carries validation annotations on the applicable methods; - the model's use XML validation as they can be used together and it's well suited to ModelDriven. The problem is that the DefaultValidatorFileParser in Xwork that reads the XML file has no way to specify which method it should be applied to. It applies to the entire class. With wildcards in 2.0 you could get around this because the action alias included the method name. It's the same reason using method='update' spefied in struts.xml never worked properly with XML validation. The parameter was ignored by the XML validator. This had always frustrated me. Fortunately somebody fixed the annotation interceptor so it can distinguish between the methods being executed. Unfortunately that fix (validateAnnotatedMethodOnly) is not enabled by the rest plugin by default. Further compounding the problem is that rest plugin has disabled validation for the edit, editNew and other relevant methods. (I'm not sure why...there must have been a reason for that). What I've done is replace the rest default stack with one that includes the validation interceptor with better configuration: interceptor-ref name=validation param name=excludeMethodsinput,back,cancel,browse,index/param param name=validateAnnotatedMethodOnlytrue/param /interceptor-ref interceptor-ref name=restWorkflow param name=excludeMethodsinput,back,cancel,browse,index/param /interceptor-ref I've been tempted to delve in a fix this but so far I've stayed out of xwork. The rest plugin does the right thing setting up the ActionInvocation with the action name and method name; the XML validation config reader just needs to use the method name to select the file (eg. to load OrdersControler-action-method-validation.xml if it exists). But I feel it already searches for far too many combinations, so I've been reluctant to touch it. stanlinck also wrote: Would you share the interceptor stack to fold paramsPrepareParamsStack capabilities into the restDefaultStack? I haven't experimented with this much with the rest plugin as I try to avoid it . It's reasonable logical... The actionMappingParams interceptor is the one responsible for setting the id, so it needs to appear before the prepare interceptor. If you need other params, before prepare, you also need params before prepare. The actionMappingParams and params are then required after prepare again. ie. set the id, load the object, set the id and params It's different because the ActionMapper obtained the id from URI. If you use other variables in the namespace you also need this interceptor before prepare. Hope that helps, Jeromy Evans - 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: REST Showcase 2.1.2
What's wrong with annotations, and more importantly - How hot is your sister?! (sorry, couldn't resist) -Wes On Mon, 2008-09-01 at 08:57 -0500, [EMAIL PROTECTED] wrote: Thanks Jeromy -- I'd rather sleep with my sister than embed annotations in my code. This notwithstanding, I understand your reluctance to add yet another permutation to that lookup scheme. I poked around in the code back in 2.0 and nearly got a nose bleed. I hope there are a ton of unit tests around that baby! I'm getting the feeling that REST is not ready for prime time. I too wondered why it was excluding edit, editNew. I'm sure there was a reason. Peace, Scott On Mon, Sep 1, 2008 at 8:09 AM, Jeromy Evans [EMAIL PROTECTED] wrote: stanlick wrote: Also, what is the naming convention for validation xml files using the Code Behind/REST plug-in? I've tried several combinations of naming, but none seem to work. The short answer is: you can't. It doesn't work. Fortunately annotation validation works correctly in 2.1, so the approach I've used is: - the action carries validation annotations on the applicable methods; - the model's use XML validation as they can be used together and it's well suited to ModelDriven. The problem is that the DefaultValidatorFileParser in Xwork that reads the XML file has no way to specify which method it should be applied to. It applies to the entire class. With wildcards in 2.0 you could get around this because the action alias included the method name. It's the same reason using method='update' spefied in struts.xml never worked properly with XML validation. The parameter was ignored by the XML validator. This had always frustrated me. Fortunately somebody fixed the annotation interceptor so it can distinguish between the methods being executed. Unfortunately that fix (validateAnnotatedMethodOnly) is not enabled by the rest plugin by default. Further compounding the problem is that rest plugin has disabled validation for the edit, editNew and other relevant methods. (I'm not sure why...there must have been a reason for that). What I've done is replace the rest default stack with one that includes the validation interceptor with better configuration: interceptor-ref name=validation param name=excludeMethodsinput,back,cancel,browse,index/param param name=validateAnnotatedMethodOnlytrue/param /interceptor-ref interceptor-ref name=restWorkflow param name=excludeMethodsinput,back,cancel,browse,index/param /interceptor-ref I've been tempted to delve in a fix this but so far I've stayed out of xwork. The rest plugin does the right thing setting up the ActionInvocation with the action name and method name; the XML validation config reader just needs to use the method name to select the file (eg. to load OrdersControler-action-method-validation.xml if it exists). But I feel it already searches for far too many combinations, so I've been reluctant to touch it. stanlinck also wrote: Would you share the interceptor stack to fold paramsPrepareParamsStack capabilities into the restDefaultStack? I haven't experimented with this much with the rest plugin as I try to avoid it . It's reasonable logical... The actionMappingParams interceptor is the one responsible for setting the id, so it needs to appear before the prepare interceptor. If you need other params, before prepare, you also need params before prepare. The actionMappingParams and params are then required after prepare again. ie. set the id, load the object, set the id and params It's different because the ActionMapper obtained the id from URI. If you use other variables in the namespace you also need this interceptor before prepare. Hope that helps, Jeromy Evans - 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: REST Showcase 2.1.2
I thought the framework created types that were null as a prerequisite to set parameters? The whole Google Juice 1.0 inject internals? Do you know the naming scheme for external validation? I feel like I need a secret REST 2 decoder ring or to become a member of the secret society! %-| Peace, Scott Jeromy Evans - Blue Sky Minds wrote: stanlick wrote: So any ideas why the model is being created inside the action and not injected by the framework? private Order model = new Order(); I think Don was just being lazy in the quick example ;-) I load or create the model in the appropriate prepare method. All that matters is that is exists (is non-null) prior to properties being set because it uses ModelDriven. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/REST-Showcase-2.1.2-tp19228759p19232956.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Showcase 2.1.2
Lifecycle is the same: up to you. There is no specific reason why it needs to be like that. (you know the struts style: many ways of doing the same thing) musachy On Fri, Aug 29, 2008 at 7:05 PM, stanlick [EMAIL PROTECTED] wrote: Is there a reason the lifecycle will not create the model object Order on action instantiation? I notice it is being constructed during the Action initialization and without it, fails in the create method with a NPE. How much different is the lifecycle when using the REST plug-in? -- View this message in context: http://www.nabble.com/REST-Showcase-2.1.2-tp19228759p19228759.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd
Re: REST Showcase 2.1.2
So what do you suppose is the special missing sauce? I see Spring inject my service bean into the action but not the model! Very strange indeed. Public setter method, bean wiring by autodetect... really has me scratching my head. Also, what's with the ModelDriven refreshModelBeforeResult? I haven't seen that one before! Don't see it in the http://struts.apache.org/2.x/docs/model-driven-interceptor.html guide Is this a guide/version deal? Scott Musachy Barroso wrote: Lifecycle is the same: up to you. There is no specific reason why it needs to be like that. (you know the struts style: many ways of doing the same thing) musachy On Fri, Aug 29, 2008 at 7:05 PM, stanlick [EMAIL PROTECTED] wrote: Is there a reason the lifecycle will not create the model object Order on action instantiation? I notice it is being constructed during the Action initialization and without it, fails in the create method with a NPE. How much different is the lifecycle when using the REST plug-in? -- View this message in context: http://www.nabble.com/REST-Showcase-2.1.2-tp19228759p19228759.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Hey you! Would you help me to carry the stone? Pink Floyd -- View this message in context: http://www.nabble.com/REST-Showcase-2.1.2-tp19228759p19229294.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Showcase 2.1.2
--- On Fri, 8/29/08, stanlick [EMAIL PROTECTED] wrote: Also, what's with the ModelDriven refreshModelBeforeResult? I haven't seen that one before! Don't see it in the http://struts.apache.org/2.x/docs/model-driven-interceptor.html guide Is this a guide/version deal? It hasn't been documented yet, AFAIK. It was put it due to an old JIRA issue. I think it came up originally because of the double call to getModel() in the interceptor or something? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Showcase 2.1.2
So any ideas why the model is being created inside the action and not injected by the framework? private Order model = new Order(); newton.dave wrote: --- On Fri, 8/29/08, stanlick [EMAIL PROTECTED] wrote: Also, what's with the ModelDriven refreshModelBeforeResult? I haven't seen that one before! Don't see it in the http://struts.apache.org/2.x/docs/model-driven-interceptor.html guide Is this a guide/version deal? It hasn't been documented yet, AFAIK. It was put it due to an old JIRA issue. I think it came up originally because of the double call to getModel() in the interceptor or something? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/REST-Showcase-2.1.2-tp19228759p19229834.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Showcase 2.1.2
Also, what is the naming convention for validation xml files using the Code Behind/REST plug-in? I've tried several combinations of naming, but none seem to work. -- View this message in context: http://www.nabble.com/REST-Showcase-2.1.2-tp19228759p19229925.html Sent from the Struts - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REST Showcase 2.1.2
stanlick wrote: So any ideas why the model is being created inside the action and not injected by the framework? private Order model = new Order(); I think Don was just being lazy in the quick example ;-) I load or create the model in the appropriate prepare method. All that matters is that is exists (is non-null) prior to properties being set because it uses ModelDriven. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
