Anyone else want to chime in?
Applications like MailForm and PhotoGallery are realeased to CPAN as entire apps not components. This I believe is the wrong way to go. Unfortunately CGI::App does not support a plugin style approach. CGI::App currently is intended for use in the develoment of a complete application, not as a framework for which to glue together plugins, producing a complete application.
Tim O`reilly in a recent interview speaks on this very concept and how it plays a role in sucess of failure of buisnesses and projects.
At my job I am responsible for a performance metrics web site for one of our customers systems. I have extended CGI::App to a framework in which I can easily plugin new modules to provide new content. This extention is still a prototype and needs to evolve into something greater than it is currently before it would become universaly useful. I fear it is too specialized to my needs, as well as it has sprung from only my perception.
I believe MailForm and PhotoGallery would be much more useful as plugins to be integrated into an application than as applications themselves.
CGI::App needs more than a plugin extension for modules providing content. For this shift in use to succeed there will need to be uniform ways of handling state, authentication, authorization, logging, error handling... and the list goes on. Many of these content plugins will expect state management and other services from the framework. If the framework does not provide these services content plugins will end up stepping on each others resources, not to mention all the duplicated effort
These services provided by the framework already exist on CPAN and are used by many developers, they only need to be rolled into CGI::App in a cohesive way.
I am sure that I am not the only person to have these thoughts. On one of the CGI::App Wikies plugins are discussed.
I am working to finish some UML and code examples to post on one of the CGI::App Wikies to show how I have extended the framework to help supply these services. I doubt it is the best design but I hope it will at least spur a community movement in that direction.
I had learned how to make OOP programs. I thought I knew how to use it. I continued to still encounter many problems with maintenance, enhancements and new features. I was differently missing something important. I was following all rules, I had read many books and was following there examples, so what was the problem.
Design Patterns have started to shown me what I didn't and things I maybe still don't know (I hope, I love a better way). I think itâ€™s much like the difference between me and a painter. We both know how to use a brush, but the painter know how and why to use the brush differently for different situations.
I am reading "Design Patterns Explained, A New Perspective on Object Oriented Design" by Alan Shalloway and James R. Trott. This is a great book for learning Design Patterns, it's not a collection of design patterns. This book is all about epiphanies, showing you how to think about OOP. After a few ahhas I began see a better way. I wish I had known this book existed when I was learning OOP.
"It begins with an 'S' and ends with a 'T,' it comes out of you and it comes out of me, I know what you're thinking, but don't say that, 'cause to be scientific we call it scat."
Man it's good to be Perl programmer!!!
Well open source testing recently got there forum up and running. All you guys that have written or use test releated software should take a look. Its a great place to find new stuff and submit your own to the community.
They have a wide varity of categories of testing software:
So I am on to adding in support for black box testing. The idea is to provide a switch, when on would record all requests and responses. Net::WWWServer could then provide a CGI interface to let you review the reqs and resps. You could then group them into transactions and label the test. Later when you needed to perform a regression test you can select from the test you have already defined and run them. After the tests are complete a report will be generated. Besides what you think the report would contain it would let you compare the output of the tests against the correct response, both in rendered and un-rendered HTML, if applicable.
I have yet to think through how CGI that requires authentication can be tricked, stubbed, or something else. So there may be a few other things I have not thought of yet as well.
The main reason I think this approach to black box testing a CGI script or app is better than LWP:
If while reviewing the test report you see that a test has failed you can repeat the test in the debugger. This would be initiated by a form button on the report. You need not spend more time setting up your CGI to debug a particular request, or even more time if it is a series of requests.
This is also where I think that my previous work on CGI and CGI::Carp (which I still owe L. Stein the diffs for) will come in handy. I added the option to save fatal errors in the same format as the black box testing would save requests. So any fatal errors encountered on a production site could easily fit in to this testing.
Well that is enough for now, I am sure some of you are napping by now.
I finaly finished version 0.01 of Net::WWWServer. I had several problems with IPC::Open3 in Win32. I could not figure out what the heck was going wrong so I switched to Win32::Job.
I wish I had a *nix box at home I could only test this weekends modification on Win32 machines.
I need to update one of my boxes to Perl 5.8 and make this a multi-threaded server.
So I am close to finishing a first cut of my CGI::Application debugging web server, newly added CGI::Carp functionality to store request info of fatal errors, and a CGI::Application for viewing the errors and initiating them in the debugger.
Before anything is submitted to CPAN I would like a few people to test it out and tell what’s good, bad, or just didn’t work. I am working on the Makefile.PL right now, I should be done with that by the weekend, bummer I can do this at my job. Please email me and I will send you a copy (jay_flowers at chcsii.com).
I have always hated how difficult debugging CGI is, so I decided to do something about it. I grabbed a copy of Perl Web Server form Source Forge and went to work.
After a coupla days a hack'n I had a web server that would eval my CGI scripts and CGI::Applications. I could now set a break point in my CGI script and start the web server in the debugger. Then open a browser to port the web server is listening. This allowed me to interact with my CGI script through the browser. I find this easier than setting every thing up on the command line, especially for queries with 20 or more name value pairs.
After getting the debugging down I saw that was just the tip of the ice burg for making CGI development and debugging easier.
I modified CGI and CGI::Carp to provide the option to save all state and request information from a fatal error with Storable to a file. I added a new page to my CGI script so I could view the detailed information in the error files. As well as the ability to execute the offending request. You say why would I want to execute the falling request again? You would want to do that from the debugging web site, in the Perl Web Server debugger. Then you can quickly track down where the error is and fix it.
No more sifting through logs, or having to guess what the user did to get the error they are reporting. Get right to it, and fix it.
I have plans to add a test harness to it so in development you can create the same files the CGI::Carp creates for fatal errors and use them as the test case input. Then save and associate the output from those successful for future tests. When an error occurs on your production system you can grab the error file that CGI::Carp generated and fix the problem. After fixing the problem you make a new output file and associate it with the error file generated by CGI::Carp and run the test harness with the old and new test case to see if you broke anything while fixing the bug.
So I have some questions for anyone that is reading this. Is this so specialized a solution to my needs that others would not find much use in it? If not how do I give this to the Perl community, is it a tool, a set of libs, a hack or some combination of those choices? Do I need to contact the authors of the modules I needed to modify before I submit it to the Perl community? I just don't know what etiquette is in this situation.