Re: Need help with Struts Interceptor/session problem.
--- daveck <[EMAIL PROTECTED]> wrote: > In our situation, some products are free while others are not. There's an > interceptor stack for each. All are dynamically generated immediately as an > html page or a pdf. An order is only generated for the products that > aren't free. For those, once the page is delivered successfully, an order is > generated and the customers account (already established) is charged. The > BillingInterceptor is only used for the confirmation. Maybe I should call > it ConfirmationInterceptor. > Does an interceptor make more sense in this case? Not to me. It's just normal order processing: used in only one place (order processing), doesn't encompass any functionality needed anywhere else, and doesn't require any interceptor functionality. I'd just redirect to a confirmation action when necessary. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help with Struts Interceptor/session problem.
newton.dave wrote: > > > I can't overstate enough that I have no idea how your application is > designed--it's possible an interceptor *is* the best way to handle your > needs, but I'm having trouble coming up with a reason why it would be > better > than just using another action, which would also probably eliminate the > problem you're currently experiencing. > > In our situation, some products are free while others are not. There's an interceptor stack for each. All are dynamically generated immediately as an html page or a pdf. An order is only generated for the products that aren't free. For those, once the page is delivered successfully, an order is generated and the customers account (already established) is charged. The BillingInterceptor is only used for the confirmation. Maybe I should call it ConfirmationInterceptor. Does an interceptor make more sense in this case? You've got me thinking. Thanks. -- View this message in context: http://www.nabble.com/Need-help-with-Struts-Interceptor-session-problem.-tp15598155p15600866.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: Need help with Struts Interceptor/session problem.
--- daveck <[EMAIL PROTECTED]> wrote: > The product is a generated and delivered (as a pdf) right after the user > clicks on the Confirm button. > I thought that the use of an interceptor for this purpose was ideal, but > I'm a Struts novice and far from an expert Java programmer. Can you > explain why the use of an interceptor is not the right way to go about this? I'm definitely not saying it's *wrong*, I'm just saying I would question it. The idea behind interceptors (IMO only, of course!) is that they are best used to encapsulate broad functionality across the entire system (or portions of it). For example, large portions of a web app need validation flow control, type conversion of request parameters to action properties, etc. I don't know how your application is set up, but many webapps have a single "shopping-cart-like" action that handles checkout, which might involve confirmation, after which any deliverables would be returned to the user. I (again, this is just me) don't see any point to using an interceptor for this: I'd have a shopping cart (or whatever) action. Upon moving through that action I'd have a confirmation action that re-displays my "order". After that I'd have the action that actually delivers whatever it is (in your case a PDF, could be actual order submission, a thank you page, whatever). It's a very tightly-focused use-case, hence an interceptor is adding an additional layer of complexity and configuration that is just as easily (or, more likely, easier) handled with an "interim" action that handles confirmation and the next step in the process. I can't overstate enough that I have no idea how your application is designed--it's possible an interceptor *is* the best way to handle your needs, but I'm having trouble coming up with a reason why it would be better than just using another action, which would also probably eliminate the problem you're currently experiencing. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help with Struts Interceptor/session problem.
I've done some pretty extensive troubleshooting, but will try and expand on it. The product is a generated and delivered (as a pdf) right after the user clicks on the Confirm button. I thought that the use of an interceptor for this purpose was ideal, but I'm a Struts novice and far from an expert Java programmer. Can you explain why the use of an interceptor is not the right way to go about this? Thanks! newton.dave wrote: > > --- daveck <[EMAIL PROTECTED]> wrote: >> Sometimes "PARMS" manages to keep its value, and sometimes >> the value disappear. > > I don't see anything immediately obvious; IIRC you had already checked the > session ID to make sure you were always dealing with the same session, > correct? Have you done extensive logging / tracing / etc. to make sure the > value of "PARMS" in the session is getting set *only* when you believe it > should be (this is what I would be most suspicious of first)? > > That said, I'm pretty uncomfortable with this use of an interceptor: is > this > functionality really required across broad swaths of your application? Is > the > order not stored in some application-specific object that could be stored > in > the session (or somewhere else) then retrieved again in a confirmation > action? > > Dave > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Need-help-with-Struts-Interceptor-session-problem.-tp15598155p15599632.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: Need help with Struts Interceptor/session problem.
--- daveck <[EMAIL PROTECTED]> wrote: > Sometimes "PARMS" manages to keep its value, and sometimes > the value disappear. I don't see anything immediately obvious; IIRC you had already checked the session ID to make sure you were always dealing with the same session, correct? Have you done extensive logging / tracing / etc. to make sure the value of "PARMS" in the session is getting set *only* when you believe it should be (this is what I would be most suspicious of first)? That said, I'm pretty uncomfortable with this use of an interceptor: is this functionality really required across broad swaths of your application? Is the order not stored in some application-specific object that could be stored in the session (or somewhere else) then retrieved again in a confirmation action? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
