-- Mark Stosberg <[EMAIL PROTECTED]> wrote (on Tuesday, 05 October 2004, 07:37 PM +0000): > On 2004-10-05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > 1. A purely orthogonal module > > > > > > Here, the helper module has no dependency or relation to > > > CGI::Application. Most other modules you might employ from CPAN would > > > fall into this category. For example, using CGI::Simple, SQL::Abstract > > > or Data::Grouper. > > > > > > In many ways, this is the ideal setup, because the lack of > > > interdependence reduces the overall complexity of your application. > > > > > > Unfortunately, writing this of module for a custom solution can tedious > > > if there /are/ a lot of interdependencies you want to consider, such as > > > sharing configuration data, a database handle, session information or > > > CGI query parameters. > > > > This is the way I write my applications. > > It sounds like you have a very clean MVC paradigm that you've > standardized on. Do you have any specific coding tips to share > about to make that clean separation between the model and controller?
The first thing I force myself to do is to figure out how I will need to interact with my data: what will need to be pulled, how often it will need to be pulled (i.e., should I cache it), etc. This information will give me the skeleton for my API. The next thing I do is remember: never validate at the API level (I got this nugget from The Pragmatic Programmer). You can always return an error if something goes wrong, but the assumption should be that the request passed to the API is clean. This means that validation and sanity checks occur at the controller level -- which, with CGI::Application, means running in taint mode and using something like ValidateRM or hand-made regexps to validate input. Oh -- lest I forget, TEST your API. Write tests, and run them. I'm not excellent at this, but I can catch 90% of my bugs right here, before I ever display data on a page. If I were to put more effort into this, I'd likely catch many more. Next, when creating your controller class, if a form can be used in more than one situation, re-use the code for displaying and validating it -- you should have a validate method that can validate differently based on the form role (an add or an update form) and a display method that can optionally fill in the form elements. Your individual run modes can then simply call or return these. Finally, always remember that *display* *logic* is not an oxymoron; simple logic and loop structures are okay in templates, and any time you can use such structures instead of performing them in the controller, do it. I think of the controller as simply returning a whole bunch of information from the model to the view, based on a request; the view can then choose what it wants to display and how to do it. > Do you use Class::DBI to manage the database integration? Actually, I'm so often working on many tables at once that I write the SQL myself (with help from my DBA... :-) and go for straight DBI. Often I'm having to use temporary tables and/or multiple joings to get at my data, so Class::DBI won't work. (The joy and bane of relational dbs is the relational element.) > For your model classes, how do you handle access to configuration > variables? Funny you should mention that... I often will pass the name of a config file or... I've stripped out the param() interface from CGI::Application to handle parameters in a similar fashion and inherit from a class that uses it. That way, if need be, I can store them as a hash within the params I send to my CGI::Application-based class, and from there pass them to the model. Typically, however, my models are very self sufficient and only need a database handle or connection string. > Has your workflow produced any kind of re-usable framework (beyond > CGI::Application), or is more of a philosophy in action? No framework as of yet -- most of the projects have been individualized enough that I haven't been able to co-opt previous projects or abstract more. > As far as book recommendations go: One of my favorite has been "Code > Complete". It gave me new and valuable ways to think about how to > effectively structure code. I'll add it to my reading list! > I don't think it's contains a line of Perl, but at this level of > design, it hardly matters. I personally feel that if you know a programming language well enough, books that discuss patterns and methodologies can be valuable regardless of the language they use in examples. -- Matthew Weier O'Phinney http://weierophinney.net/matthew/ --------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
