Re: [cgiapp] CGI::Application status update from the maintainer
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 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
Re: [cgiapp] CGI::Application status update from the maintainer
> Hi Bill, > > This is fascinating, but I think you're abusing CGI.pm for something > it was never intended for. *** Which is one of the glories of open source. Things keep getting used for stuff that the original writers never envisioned. - Jerry Kaidor # 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/ ## ####
Re: [cgiapp] CGI::Application status update from the maintainer
On Sep 13, 2012, at 12:02 PM, Jerry Kaidor wrote: >> Hi Bill, >> >> This is fascinating, but I think you're abusing CGI.pm for something >> it was never intended for. > > *** Which is one of the glories of open source. Things keep getting used > for stuff that the original writers never envisioned. I know that you're right according to common practice, so I have to admit it made me laugh reading that this morning for that very reason. But... in my (weak) defense, in chapter three, page 119, of Lincoln's book, "The official guide to programming with CGI.pm" is the "Advanced Trick" that explains "Saving State to Files", and that's all I'm really doing here, and nothing more, so I think it's not really accurate to say that how I'm using CGI.pm was never envisioned or intended, or if that's truly the case, I've already explained why it may work now when it may not have when the book was written. I'd like to offer a few more things to consider... The OS's native file system is really a database too, and a pretty powerful one, so it seems logical to me that before you start looking to add another layer on top of the OS to manage data you should ask if you have a good reason. I think it's fair to say that this is a question that most frameworks forget to ask when they build their foundation. They assume you're going to want and need a SQL database. I think an option to use a very simple data format is a worthy one. I think that out of the box, a framework should provide a means to do what I did with that demo. I should not have to use SQL to create an app. (of course, that's entirely selfish, and I don't expect anyone to feel at all compelled to accommodate that.) If we look at web apps designed to run on mobile devices, that are by design pretty simple and tightly focused, than this simple and basic approach to handling data might be a very valuable option. The data format CGI.pm uses is already supported by most web clients, so a way to take advantage of that compatibility make sense to me. If we consider that we're now at a point where we can include a computer with the software we create (as opposed to the other way around that it's always been) then using the native OS file system offers opportunities that we shouldn't overlook. Your software owns that entire file system now, it's the only thing that will be using it. The big buzz right now is all about cloud computing, but web app builders have been doing that for a long time now and we know the downsides. The future, as far as I can see forward, looks to me like one where users can have a computer dedicated on site that runs the same app as one they have on a cloud (our web apps) and the user can choose where their data resides, on site, on a cloud, or a combination of both. It has to go this way because we all know that clouds can burst and computers that will run our web apps are getting incredibly cheap and small, so using them both together is the future (well, according to me anyway ) If that's where we're going than we need something to make it easy for the end user to customize their own software. Something so simple that most anyone can do it, or hire someone to do it. This also provides a market for software we make because if our software is simple enough for the end user to modify they have good reason to buy it. Complexity from the start shoots that model in both feet, but as an option it extends the value greatly. These are a few of the things I ponder when I think about and explore frameworks. # 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/ ## ####
[cgiapp] new CGI::Application::Dispatch version released
> So the fix isn't good enough. I think line 422 should be
>unless ( ref $e && $e->isa('Exception::Class::Base') ) {
Thanks Michael.
I've now released 3.12 which incorporates this fix from you, as well as
a test fix from Graham TerMarsch.
Mark
# 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/ ##
####
[cgiapp] CGI::App telecommute job opening for Senior Perl Developer in the EU
This job posting from Energy Fundamentals is specifically looking for a Senior Perl Developer with experience with CGI::Application. The position is Zurich, but telecommuting is an option for candidates in the EU. Details here: http://jobs.perl.org/job/16384 Mark # 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/ ## ####
