[cgiapp] Re: header_props after header_type (was: cgi_minimal compatible?)
On 2003-11-02, Mark Fuller [EMAIL PROTECTED] wrote: I've been using cgi::application (and html::template) for the last few days. Wow, this is the cloest thing to perfection I've seen. I believe the documentation should note that header_props should be set only *after* header_type. I was setting my cookie after creating a session tracking object. But, in some cases I would redirect the page later in the method. It took me awhile to figure out why my cookie wasn't set. I think it's ok to expect me to set the cookie later in my method. But, it would be nice if the documentation noted that the header_type must be set first. Mark, I believe your finding is incorrect. I wrote a test case to illustrate that setting header_props before header_type works fine. It's available as a patch to CGI::App 3.1 here: http://mark.stosberg.com/Tech/perl/cgiapp_header_type_test.patch If you continue to feel there is a bug here in the code or docs, I encourage you to make a modification of my test case that illustrates it. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Re: header_props after header_type (was: cgi_minimal compatible?)
From: Mark Stosberg [EMAIL PROTECTED] I believe your finding is incorrect. I think you are correct. Now I believe that I overlayed my header_props by setting one property (a cookie) and then setting it again with the redirection URL. (I thought that setting the header-type to redirect did it. But, it looks like it was setting the redirection URL that caused the cookie to be lost). I thought the header_props values could be set incrementally. It looks like they have to be set all at once? And that's probably a function of CGI.pm. (I'm actually using CGI::Simple). Thanks, Mark - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Re: header_props after header_type (was: cgi_minimal compatible?)
On 2003-11-02, Mark Fuller [EMAIL PROTECTED] wrote: I think you are correct. Now I believe that I overlayed my header_props by setting one property (a cookie) and then setting it again with the redirection URL. (I thought that setting the header-type to redirect did it. But, it looks like it was setting the redirection URL that caused the cookie to be lost). I thought the header_props values could be set incrementally. It looks like they have to be set all at once? And that's probably a function of CGI.pm. (I'm actually using CGI::Simple). I would call that a bug or missing feature in CGI::App. Someone else has already identified it and submitted a patch to the maintainer. We'll hope it appears in a new release soon-- I think the behavior you expected is the more intuitive one. If you are already sub-classing CGI::App, you could add a header_props routine to your class that behaves how you expect. Mark -- http://mark.stosberg.com/ - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] CGI Error handling
What's a good way to abort normal processing and display a simple error message? For example, let's say I insert a row into a MySQL table and it fails. I don't want to develop a lot of processing (beyond perhaps sleeping 5 seconds and trying again) to accomodate this. I just want to display a general error screen (to the effect that a fatal error occured, please try again) and accept that errors happen. I don't want my templates (and associated processing) to have to consider whether a visitor is now in an error-state and retrying. I think they can just back-arrow and try again. These errors will happen in subroutines. I'd rather not return from them with an error message and then have to make a decision, do I load this template or that template? I'd like to simply emit a header and the error-text from any subroutine that encounters such an unexpected error. But, in CGI::Application, I think I must return to the run-mode method and let it emit everything. What I'd like to have is some way to abort the run-mode method, in mid-stream, and let another one take over. Is there any way to do this? Also, similar topic. I tried using prerun_mode() to set my start-mode. Log messages began appearing in my server error-log saying the start_mode was changed. Is there a way to tell it I expected the mode to change and therefore don't want to see error-log entries about it? Thanks, Mark - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] teardown method
For session tracking, I keep the values in a hash and update the table in the teardown method. I thought this would be a faster way to update the session-tracking table because, by then, I the runmode would have emitted its output and the visitor would be receiving the page while the teardown method was updating the session-tracking table. To test my assumption, I put a 10 second sleep in teardown and the page was delayed 10 seconds. Why does it work this way? Is this the server? Does it expect the executing CGI to end before it transmits output? I was hoping to get a little parallel processing. :) Thanks, Mark - Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
