in reply to Re: Re: CGI::Application, Templates, and CSS
in thread CGI::Application, Templates, and CSS

I guess the best advice i can give you is, if you do it more than once, make a seperate subby (or method).

For my web apps, i've extracted all my db calls into two subroutines, one for selecting and one for updating.

Do a concept model of your apps, and put all the concepts you've found into discrete buckets.

Do you have any tips on how best to structure the runmodes? I seem to have a lot of add_blah1 , edit_blah1 , delete_blah1 runmodes, is there a better way to handle that?

If that there are several methods to a concept, perhaps you could create a 'super routine' that you pass flags to inorder to perform the varous functions.

For example if you have 3 methods add, edit, delete, you could make a routine that you pass the flags to {method=>'add'} and your routine would get the approprate sql, do the varous functions et al.

This thing is kind of contentious (and subjective) as it is combining several different methods in one function, which would normall be split into the 'high-cohesion, low coupling' style.

If you build the underlying infrastructure (ie dbi calls, content aggregation et al), and parameterise is accordingly (ie build your routines in a very generic manner) you can build the business logic for the (add, update, delete) functions in one routine that would farm out the physical operations to you prebuilt infrastructure and return $output.

As I mentioned your style to abstraction is subjective, and before putting fingers to keyboard I would suggest having a good long think about your logic, with a view to code reuse, even going so far as to sketch it out on paper.

The approach i use is a three tier approach:
1st tier: the application or user input level
2nd tier: the signal box level. The input from the user is interpreted, and calls are made to the bottom layer.
3rd tier: The layer that goes and actually *does* things. ie i'll make my dbi calls, do my content aggregation etc.

I code in this manner, and it works for me.

So in your example you could do something like:

rm=mode1&method=add; rm=mode1&method=edit; rm=mode1&method=delete

Of course everything has extremes, and if you have 20 methods for a concept, perhaps this is not the best method to persue.

Update: I've just noticed youre not untainting your $q->param() variables before reassigning them. I dont know what the rest of your code looks like, so you may have done it elsewhere. If not, you must untaint all externally assigned variables before using them if you want to build a secure web applicaiton. This inclues both sides of your app, ie the user input end and the database/os end.