Hi Bill, This is fascinating, but I think you're abusing CGI.pm for something it was never intended for.
How about using XML::Simple to encode the data and write that into the flat files? # Grab a hashref of data from the posted form my $data = $cgi->Vars; # Dump data into file XMLout($data, OutputFile => $filename); ... # read data from file my $data = XMLin($filename); # use HTML::Template to display it $template->param(%$data); etc On 12 September 2012 19:16, Bill Stephenson <bi...@ezinvoice.com> wrote: >> There not yet specific plans for how CGI.pm will be replaced. How do you >> use the save/restore feature? > > Thank you, Mark. I appreciate your taking my concerns under consideration. > > I've sort of taken my own path to create web apps, and while it works for me, > I've gotten some blowback for it a few times over the years, but I really > don't mind that, so I'll explain it. > > I have a small demo "Note Pad" app at www.raspberryperl.com: > > app -> http://raspberryperl.com/cgi-bin/NoteApp/notes.cgi > code -> http://raspberryperl.com/NoteAppCode/ > > When a user creates a note I save the data in a file: > > open(my $NOTE, "> $note_path/$notepad_number") > or &Note_home("Error 3: That didn't work"); > $cgi->save($NOTE); > close $NOTE; > > When they want to view or edit a note I load the data into a CGI object: > > $NOTE = new CGI($FILE); # Throw out the old $NOTE, replace it with a > new one > close $FILE; > return ($NOTE); > > And use HTML:Template to display it: > > $template->param(note_subject => $cgi->param('note_subject')); > > I generally use the epoch time of creation to name the file. This gives me an > easy way to search by date for documents. > > 1344045036.txt > > Or perhaps assign a document number: > > 0001.txt > > In that case, if you know the document number, finding and loading the data > is incredibly fast because you're using the system's b-tree to locate it. The > trick (if it can be called that) is creating a unique directory for each user > so the app knows where to find their documents. Put each different document > type in a unique sub-directory and you've really narrowed down where to find > what you're looking for. > > Now, my logic for this being practical is that for the most part database > engines were designed to solve just a few problems: > > 1. Slow processors took a long time ripping through a bunch of files while > searching for a specific piece of data. > 2. RAM was expensive and a lack of enough RAM made managing large numbers of > files impractical and limited what an OS could support. > 3. Hard Drive space was expensive, so storing a bunch of files was also > expensive. > > But now, RAM and ROM is comparatively cheap, and processors and OSs are way > faster than they were 15 years ago, so this approach keeps becoming more > practical for some applications. In my case, the users of the apps I build > will never create hundreds of thousands of files. Ten thousand would be the > upper ends of what they'd ever create, so this actually works pretty good, > and it's very simple to build and maintain. > > I've done tests on ripping through 5000 files (with an app like the demo > linked above) to find a unique string in one or more files and the result > times are not that bad. I suspect they'd be faster if I used ModPerl or > FastCGI, but I deploy on a VPS so that's not been an option. My tests > resulted in the initial search being a bit slow, but a second search is > pretty fast, so I suspect Apache is cacheing some data but I really don't > know much about how that works. > > I have some apps with several thousand users, and some with over 100,000 > files in the system. They all run on a VPS and they're pretty darn fast, so > again, I'm not finding a compelling reason to move to a SQL database engine. > > I use a flexible interpretation of a MVC design approach in my apps, and it > would seem to me that if there were ever a necessity to move to a SQL > database it should be fairly easy to change the routines to get and put data, > and to load the existing data into the database. If that's the case, then my > approach might be useful for RAD (rapid application development) if nothing > else. > > For my own sake, what I am trying to do is limit complexity. Not at all > costs, but I do set a high bar for the returns. Complexity, in my opinion and > experience, gets expensive fast. I think it's fair to point out that a SQL > database engine may offer another point of entry for hackers to create > mayhem. I'm not saying that my approach is more secure, but it seems to me > that you must constantly be staying on top of issues specific to any database > engine you're using, and that may create additional expense which may be > unnecessary. > > I understand that if you must have a Relational database my approach may not > work, but again, with the apps I've created I've not come across that need. > So I believe there are some good reasons to have a simple way, like that in > CGI.pm and CGI:Session to store and load data using files. > > Kindest Regards, > > Bill Stephenson > > > ##### CGI::Application community mailing list ################ > ## ## > ## To unsubscribe, or change your message delivery options, ## > ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## > ## ## > ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## > ## Wiki: http://cgiapp.erlbaum.net/ ## > ## ## > ################################################################ > ##### CGI::Application community mailing list ################ ## ## ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ## ## ## ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ## ## ################################################################
