Information for RPM perl-CGI-Prototype-0.9054-17.fc27.noarch.rpm
| ID | 73583 | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Name | perl-CGI-Prototype | |||||||||||||
| Version | 0.9054 | |||||||||||||
| Release | 17.fc27 | |||||||||||||
| Epoch | ||||||||||||||
| Arch | noarch | |||||||||||||
| Summary | Create a CGI application by subclassing | |||||||||||||
| Description | The core of every CGI application seems to be roughly the same: * Analyze the incoming parameters, cookies, and URLs to determine the state of the application (let's call this "dispatch"). * Based on the current state, analyze the incoming parameters to respond to any form submitted ("respond"). * From there, decide what response page should be generated, and produce it ("render"). CGI::Prototype creates a "Class::Prototyped" engine for doing all this, with the right amount of callback hooks to customize the process. Because I'm biased toward Template Toolkit for rendering HTML, I've also integrated that as my rendering engine of choice. And, being a fan of clean MVC designs, the classes become the controllers, and the templates become the views, with clean separation of responsibilities, and "CGI::Prototype" a sort of "archetypal" controller. | |||||||||||||
| Build Time | 2017-07-28 05:37:24 GMT | |||||||||||||
| Size | 37.37 KB | |||||||||||||
| e0499d448fe6ed3e99b3cc417b68894e | ||||||||||||||
| License | GPL+ or Artistic | |||||||||||||
| Provides |
|
|||||||||||||
| Obsoletes | No Obsoletes | |||||||||||||
| Conflicts | No Conflicts | |||||||||||||
| Requires |
|
|||||||||||||
| Recommends | No Recommends | |||||||||||||
| Suggests | No Suggests | |||||||||||||
| Supplements | No Supplements | |||||||||||||
| Enhances | No Enhances | |||||||||||||
| Files | ||||||||||||||
| Component of | No Buildroots |
