Re: [cgiapp] Good practices: how many run modes in an app
Jesse,
Af few weeks ago, I asked a question about a snazzy way to do a fill
in form in one line
return
$self-fill_form($self-tt_process({}),$self-dbh-selectrow_hashref(SELECT
* from menus WHERE id = ?,{},$id));
Since this uses dbh directly, in Krang to do something similar does
that mean you would make a method in a Krang module that was simply a
wrapper to this call ? I guess the advantage to that would be that
many other places could call this method with common results, instead
of having to change many sql statements and risking errrors.
Jeff.
On 12/18/05, Jesse Erlbaum [EMAIL PROTECTED] wrote:
Hi Rob --
I would break each of them up into functional areas. My rule of thumb
is never more than 12, rarely more than 6, preferably 4 or less.
Anything more and I'm trying to do too much in the controller and
should be offloading into business objects.
Just regarding the last part, business objects --
At the moment you do so, it is rarely clear that you've crossed the line
into too much territory. (You know when you're deep into wrong path,
but by then it's too late.) On the Krang CMS project we were able to
define a hard rule about what was appropriate in CGI-App modules, and
what was not. That rule:
CGI::Application modules are prohibited from having or using DBI
database handles.
This rule was simple because no subjective judgment was needed. You
either did or did not have a $dbh. As the primary side effect, this
rule provided a natural separation between object/business modules and
front-end CGI/UI modules. If you needed to access or modify data, you
had to go through another module. This had the effect of orienting all
the developers towards the philosophy of separation. The project
benefited greatly as a result.
TTYL,
-Jesse-
--
Jesse Erlbaum
The Erlbaum Group
[EMAIL PROTECTED]
Phone: 212-684-6161
Fax: 212-684-6226
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jeff MacDonald
http://www.halifaxbudolife.ca
http://www.nintai.ca
-
Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/
http://marc.theaimsgroup.com/?l=cgiappr=1w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Good practices: how many run modes in an app
On Sun, 18 Dec 2005 09:19:18 -0500, Cees Hek wrote: Hi Cees That is the rule I follow as well. The only time the CGI::App Same here. object sees a DBI handle is when it needs to pass one to a plugin (like the session plugin). It never ever uses it directly. Right. -- Cheers Ron Savage, [EMAIL PROTECTED] on 19/12/2005 http://savage.net.au/index.html Let the record show: Microsoft is not an Australian company - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[cgiapp] Good practices: how many run modes in an app
I'm writing a medium-sized web-based financial application that will have up to 50 run modes between presenting empty forms, saving, editing, updating, and deleting from them. Run modes *could* be broken down into groups, e.g., these 4 deal with managing users, these 6 deal with managing project specifications, etc. Being new to C::A I'm curious if there are any general rules of thumb as to the number of run modes (subs) that are run in any given Appl.pm. Besides the long list under setup, there might be performance issues, and places where trying to use a common sub might get messy. In my pre-C::A days I would have been more inclined to break it down into various scripts, maybe by function. But I'm not sure of how this fleshes out in a C::A world. Comments? Thanks, Brad - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Good practices: how many run modes in an app
Brad Cathey wrote: I'm writing a medium-sized web-based financial application that will have up to 50 run modes between presenting empty forms, saving, editing, updating, and deleting from them. Run modes *could* be broken down into groups, e.g., these 4 deal with managing users, these 6 deal with managing project specifications, etc. 50 is definitely too much. There isn't a hard rule to follow for what is too much, but I think there can never be too few. I usually split them up by functionality or user authentication level. And remember that base classes are your friend here. For instance, if I have admin and normal users and each can view reports. Some reports are the same, but some are different, I would split them up into the following structure: MyApp::Base - base class for all my app classes that might have classes to deal with configuration, database, sessions, templates, etc that they all have in common. MyApp::Report- base class for reports that contains those reports that everyone can see as well as common methods used to generate reports, graphs, etc MyApp::Report::Admin - app class containing admin reports MyApp::Report::User - normal user reports Most of it is personal perference, but you really need to break it into structures. Being new to C::A I'm curious if there are any general rules of thumb as to the number of run modes (subs) that are run in any given Appl.pm. Besides the long list under setup, there might be performance issues, and places where trying to use a common sub might get messy. I think the keyword here is 'messy'. OO programming in general is not about speed. It's almost always slower to use an OO approach, but it's very useful for organization. No matter what you write, you are always going to be making changes and adding new stuff. The better organized and cleaner it is, the happier you (and the person after you) will be. In my pre-C::A days I would have been more inclined to break it down into various scripts, maybe by function. But I'm not sure of how this fleshes out in a C::A world. I'd follow the same kind of approach that you used to have. The advantage of the C::A world over using multiple scripts is inheritance. Break common functionality and common run modes out into base classes and you will be much happier. -- Michael Peters Developer Plus Three, LP - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Good practices: how many run modes in an app
Thank you Michael, that was very helpful. Unfortunately it uncovered areas I'm unfamiliar with, that a good study of OO will help. Brad Cathey wrote: I'm writing a medium-sized web-based financial application that will have up to 50 run modes between presenting empty forms, saving, editing, updating, and deleting from them. Run modes *could* be broken down into groups, e.g., these 4 deal with managing users, these 6 deal with managing project specifications, etc. 50 is definitely too much. There isn't a hard rule to follow for what is too much, but I think there can never be too few. I usually split them up by functionality or user authentication level. And remember that base classes are your friend here. For instance, if I have admin and normal users and each can view reports. Some reports are the same, but some are different, I would split them up into the following structure: MyApp::Base - base class for all my app classes that might have classes to deal with configuration, database, sessions, templates, etc that they all have in common. MyApp::Report - base class for reports that contains those reports that everyone can see as well as common methods used to generate reports, graphs, etc MyApp::Report::Admin - app class containing admin reports MyApp::Report::User - normal user reports Most of it is personal perference, but you really need to break it into structures. Being new to C::A I'm curious if there are any general rules of thumb as to the number of run modes (subs) that are run in any given Appl.pm. Besides the long list under setup, there might be performance issues, and places where trying to use a common sub might get messy. I think the keyword here is 'messy'. OO programming in general is not about speed. It's almost always slower to use an OO approach, but it's very useful for organization. No matter what you write, you are always going to be making changes and adding new stuff. The better organized and cleaner it is, the happier you (and the person after you) will be. In my pre-C::A days I would have been more inclined to break it down into various scripts, maybe by function. But I'm not sure of how this fleshes out in a C::A world. I'd follow the same kind of approach that you used to have. The advantage of the C::A world over using multiple scripts is inheritance. Break common functionality and common run modes out into base classes and you will be much happier. - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [cgiapp] Good practices: how many run modes in an app
On 12/17/05, Brad Cathey [EMAIL PROTECTED] wrote: I'm writing a medium-sized web-based financial application that will have up to 50 run modes between presenting empty forms, saving, editing, updating, and deleting from them. Run modes *could* be broken down into groups, e.g., these 4 deal with managing users, these 6 deal with managing project specifications, etc. I would break each of them up into functional areas. My rule of thumb is never more than 12, rarely more than 6, preferably 4 or less. Anything more and I'm trying to do too much in the controller and should be offloading into business objects. Rob - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiappr=1w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
