On Wed, 5 Jan 2005 05:59:47 -0500, Sean Davis <[EMAIL PROTECTED]> wrote: > > On Jan 4, 2005, at 11:07 PM, Literatecat wrote: > > > Hi Sean, > > > > I do already have some of the books that you mention, and I have just > > recently picked up the perl medic to help convert these scripts to the > > latest version of perl. > > > > However, as I already use hidden fields and have started working on > > script generated forms, pattern matching, mysql to mention a few > > things, (although I did see some other things in a book I was flicking > > through last night that will lead to some other questions here, like > > using tk toolkit on the web, perl embed, perl sessions etc) I have > > already altered these script so far that I doubt that copyright exists > > on them anymore. > > > > I just don't understand the concept of what happens when a script > > tries to create multiple pages from one query. This makes it > > difficult to create the code. If you say perl DBI then I already have > > a book on its way, and I will just have to wait for it to come in. > > The issue here is that there is no concept of creating multiple pages > for one query. The query is used to generate only ONE page. If you > want to generate another page, you have to generate a new query with > new parameters. Consider a "paged" DBI output. You have a script that > generates a pages that asks the user what to search for. The user > presses submit. The next script (or a subroutine from the same script, > depending on your design) processes the query and returns results, but > only for the first page. On that same page, you need to have all the > information from the original database search page as well as a page > number. On a submit from this page, you submit back to the second > script (the same script), but a parameter in this query tells the > script that it is now to generate page two. Other information remains > the same. Confusing, yes, but that is the nature of the web. It > sounds like you might need to take a step back and make a toy example > that does something plain and simple like acccepting user input and > then generating output, perhaps using DBI. If this is going to be a > large undertaking, I encourage you to look seriously at web development > modules like CGI::Application, CGI::Builder, Maypole, and the like. > > Sean >
Cat, The issue here is that a cgi script executes anew every time it is called. Unless you do something to save state--cgi for making the script remember something--it will simply repeat what it's done before. Simple data can be passed as hidden values, more complex data structures may require client-side cookies. In your cgi books, you'll want to look at saving state, and session management. How exactly you go about that will depend on what is important to you with regard to your data, and how you want your user to interact with it. The simplest way to appraoch this is by modifying a combination of perl and SQL. Put in a hidden field with either a "page" number or the last row viewed, and then modify the query subroutine to add a limit clause to the query. On the first page, you'll use "limit 25", on the second "limit 25,25" on the third "limit 25,50", etc. Look up limit in a mysql reference. Note, though, that this appraoch will re-run the query each time. If a row is added before the current page, the first item on the page will be a repeat of something the user has already seen. Probably, this won't be an issue for you. If you need to make sure the user sees the info as it was at the time they made the request, you'll need to save the results somewhere and iterate through them. You could pass them as a hidden field if they're small, but you'll probably want a temporary file somewhere. Chek out File::Temp HTH, --jay -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
