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=cgiapp&r=1&w=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
Hi Jeff --
> 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_h
> ashref("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.
We wouldn't create a wrapper to that call, as it includes a template
which would violate encapsulation the other way (object modules
shouldn't imply presentation). What we have in Krang is a very
high-level representation of our data which provides a "find()" method,
which returns objects:
# Imaginary run-mode to display story titles
sub show_stories {
my $self = shift;
# Find all published stories, sort by title
my @stories = Krang::Story->find( published => 1,
order_by => 'title' );
my $html = "\n";
$html .= "\n";
# List each story title
foreach my $s (@stories) {
$html .= "". $s->title() ."\n";
}
$html .= "\n";
my $html = "\n";
return $html;
}
These story objects ($s) have methods including new() and save(). The
find() method takes a bunch of parameters, from which SQL is generated
and issued against the database.
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=cgiapp&r=1&w=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
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=cgiapp&r=1&w=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=cgiapp&r=1&w=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/18/05, Jesse Erlbaum <[EMAIL PROTECTED]> wrote: > Just regarding the last part, "business objects" -- [snip] > CGI::Application modules are prohibited from having or using DBI > database handles. That is the rule I follow as well. The only time the CGI::App 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. As a simple extension of this rule, if you use an O-R mapper like Class::DBI (or Rose::DB::Object which I have been looking at lately), you automatically enforce this separation. Of course it is not necesary to use an O-R mapper, but it can simplify a great deal of your code while providing that clean separation for you. Cheers, Cees - Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=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
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=cgiapp&r=1&w=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=cgiapp&r=1&w=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=cgiapp&r=1&w=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=cgiapp&r=1&w=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=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
