[cgiapp] Number of rm's best practice (more)
Reading the thread on 'Good practices: how many run modes in an app' it is obvious my current application under development is going way over the 'recommended' upper limit of rm's. I know I need to break it into smaller units based around functionality, but how? At the moment my main application module is invoked either through an instance script (eg myapp.cgi) or via an embedded Apache handler - it's designed to work with both. As soon as I think of splitting the module into smaller units I'm not sure I know how to proceed. How's this: MyApp::Base contains all the CGI::Application override methods like cgiapp_init, setup, cgiapp_prerun, template_pre_process, etc but no run-modes (except perhaps session/authentication/authorisation methods). It uses base CGI::Application. MyApp::Function_1 contains all the run-modes related to function_1 (eg edit records) and uses base MyApp::Base ie it inherits cgiapp_init, setup, etc from the MyAPpp::Base module (or should we use @ISA here?). Other MyApp:Function_ modules are setup as needed. But the question is how to call these modules - do they each have to have their own instance script pointing to them (eg myapp_function_1.cgi, myapp_function_2.cgi, etc), and an embedded Apache handler so they can run under mod_perl? One instance script per module? If so I have to change all the templates to point to any one of many mini-applications - in fact what we get is a host of mini-apps running under the umbrella of a larger whole. This seems a little complicated, almost defeating the object of breaking the application into smaller units. Or is this all completely wide of the mark? I think an example of an application broken into multiple parts would be very helpful for me at this stage. -- Richard Jones Leeds, UK mailto:[EMAIL PROTECTED] - 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] Number of rm's best practice (more)
I'm at about the same stage of figuring things out as you are, I'd recommend looking into C::A::P::Dispatch, it can basically parse your query string, to know which module handles which runmode, combine that with AutoRunmodes and you get a pretty cool setup. Jeff. On 12/18/05, RA Jones [EMAIL PROTECTED] wrote: Reading the thread on 'Good practices: how many run modes in an app' it is obvious my current application under development is going way over the 'recommended' upper limit of rm's. I know I need to break it into smaller units based around functionality, but how? At the moment my main application module is invoked either through an instance script (eg myapp.cgi) or via an embedded Apache handler - it's designed to work with both. As soon as I think of splitting the module into smaller units I'm not sure I know how to proceed. How's this: MyApp::Base contains all the CGI::Application override methods like cgiapp_init, setup, cgiapp_prerun, template_pre_process, etc but no run-modes (except perhaps session/authentication/authorisation methods). It uses base CGI::Application. MyApp::Function_1 contains all the run-modes related to function_1 (eg edit records) and uses base MyApp::Base ie it inherits cgiapp_init, setup, etc from the MyAPpp::Base module (or should we use @ISA here?). Other MyApp:Function_ modules are setup as needed. But the question is how to call these modules - do they each have to have their own instance script pointing to them (eg myapp_function_1.cgi, myapp_function_2.cgi, etc), and an embedded Apache handler so they can run under mod_perl? One instance script per module? If so I have to change all the templates to point to any one of many mini-applications - in fact what we get is a host of mini-apps running under the umbrella of a larger whole. This seems a little complicated, almost defeating the object of breaking the application into smaller units. Or is this all completely wide of the mark? I think an example of an application broken into multiple parts would be very helpful for me at this stage. -- Richard Jones Leeds, UK mailto:[EMAIL PROTECTED] - 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] Number of rm's best practice (more)
On 12/18/05, Rhesa Rozendaal [EMAIL PROTECTED] wrote:
use base qw/MyApp::Base/;
or
our @ISA = qw/MyApp::Base/;
is functionally equivalent. I personally prefer the former, since it reads
better.
Although they are very similar, there is a minor difference that can
be important in some instances. use base takes effect at compile
time, whereas @ISA takes place at run time. To make them equivalent,
you need to put the @ISA statement in a BEGIN {} block.
BEGIN { our @ISA = qw/MyApp::Base/ };
One place where this difference can bite you is loading a plugin (or
module) that does some work during the 'import' stage. For example
when you use the CAP::TT plugin, it checks to see if the module is a
CGI::Application subclass, and if it is, it registers some new hooks.
If you use @ISA but don't put it in a BEGIN block, then this will
fail, and the hooks will not be setup for you.
This is why I always use base instead of @ISA.
Cheers,
Cees
-
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] Number of rm's best practice (more)
I'm liking this thread. But I have some elementary questions:
package My::MainApp;
use base qw/My::BaseApp/; # I already have this one; it handles sessions
etc
use My::MainApp::Admin; # contains the run modes dealing with admin
functions
use My::MainApp::News; # another example package of run modes
# rest of app follows
# this app still has some runmodes of its own, but most have been moved
# into the packages use()d above.
1;
1) The above is *not* your base program, right? So what is it doing? I
understand base has all the cgiapp_ stuff and your setup. And I
understand that ::Admin and ::News are doing specific functions, but this
inbetween module is unclear.
2) Also, in your sub import {} are you only importing the run modes for
that module (I assume)? My real question is, then, do ALL the runmodes
still get listed in the base module?
3) How are these files named when they are saved to the server? Just
Admin.pm?
Thanks!
package My::MainApp::Admin;
use CGI::Application; # to get the callback functionality
use base qw/Exporter/;
sub import
{
caller()-add_callback( 'prerun' = sub {
my $self = shift;
$self-run_modes([qw/
save_user
delete_user
/]);
} );
goto Exporter::import;
}
sub save_user {} # these used to be a run mode in MainApp
sub delete_user {} # but are now in their own package
1;
Hope that helps a bit :)
Rhesa
-
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]
-
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] Number of rm's best practice (more)
[EMAIL PROTECTED] wrote:
I'm liking this thread. But I have some elementary questions:
package My::MainApp;
use base qw/My::BaseApp/; # I already have this one; it handles sessions
etc
use My::MainApp::Admin; # contains the run modes dealing with admin
functions
use My::MainApp::News; # another example package of run modes
# rest of app follows
# this app still has some runmodes of its own, but most have been moved
# into the packages use()d above.
1;
1) The above is *not* your base program, right? So what is it doing? I
understand base has all the cgiapp_ stuff and your setup. And I
understand that ::Admin and ::News are doing specific functions, but this
inbetween module is unclear.
This in-between module is my actual application: the one that the instance
script uses.
The My::BaseApp would be a direct subclass of CGI::Application. I usually have
one around to take care of generic stuff (like handling sessions and other
plugins), but it doesn't have run modes of its own.
Sorry if that was confusing.
2) Also, in your sub import {} are you only importing the run modes for
that module (I assume)? My real question is, then, do ALL the runmodes
still get listed in the base module?
The base module does no longer list run modes itself. All the run modes are
moved into the sub packages. The import() call registers them in the base
module though.
3) How are these files named when they are saved to the server? Just
Admin.pm?
They would be named as usual: My/MainApp/Admin.pm
They follow the standard package to filename mapping.
Does that clear it up?
Rhesa
-
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] Number of rm's best practice (more)
On Sun, 18 Dec 2005, Jeff MacDonald [EMAIL PROTECTED] wrote: I'm at about the same stage of figuring things out as you are, I'd recommend looking into C::A::P::Dispatch, it can basically parse your query string, to know which module handles which runmode, combine that with AutoRunmodes and you get a pretty cool setup. Did you mean CGI::Application::Dispatch? I cannot find CGI:Application::Plugin::Dispatch on CPAN. -- Richard Jones Leeds, UK mailto:[EMAIL PROTECTED] - 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] Number of rm's best practice (more)
On Sun, 18 Dec 2005, Rhesa Rozendaal [EMAIL PROTECTED] wrote:
Here's a sketch of my app structure as it is now. I show two parts, the
main, formerly monolithic CgiApp, and one package with a set of run
modes.
package My::MainApp;
use base qw/My::BaseApp/; # I already have this one; it handles sessions etc
use My::MainApp::Admin; # contains the run modes dealing with admin functions
use My::MainApp::News; # another example package of run modes
# rest of app follows
# this app still has some runmodes of its own, but most have been moved
# into the packages use()d above.
1;
package My::MainApp::Admin;
use CGI::Application; # to get the callback functionality
use base qw/Exporter/;
sub import
{
caller()-add_callback( 'prerun' = sub {
my $self = shift;
$self-run_modes([qw/
save_user
delete_user
/]);
} );
goto Exporter::import;
}
sub save_user {} # these used to be a run mode in MainApp
sub delete_user {} # but are now in their own package
1;
Hope that helps a bit :)
Thanks Rhesa, I'm sure it will help when I can get it working. I have
taken some run-modes out of the main app into a new module called
NewPatient, declared the package NewPatient in NewPatient.pm, with the
new import() method listing an arrayref of re-located run-modes, use'ing
CGI::Application and base 'Exporter', and referenced the new module in
the main app with 'use NewPatient'. So far so good. But now when I
invoke my application it says 'Error executing run mode 'new_patient':
Can't locate object method new_patient via package MyApp at
c:/usr/local/site/lib/CGI/Application.pm line 154, (yes it's a Win32
setup!), where MyApp is the main application invoked by the instance
script.
But the new_patient method *is* there and is also referenced in the
$self-run_modes arrayref. I know the app is finding the package
NewPatient because if I comment out the line 'use NewPatient' in MyApp
the AUTOLOAD = \_exception runmode gets called.
I'm not at all familiar with the add_callback() and caller() functions
of import(), and I don't think I've ever used the 'prerun' function
before. Perhaps I've missed an important step somewhere?
--
Richard Jones
Leeds, UK
mailto:[EMAIL PROTECTED]
-
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] Number of rm's best practice (more)
Hi Jesse, On Sun, 18 Dec 2005, Jesse Erlbaum [EMAIL PROTECTED] wrote: [lots of useful remarks] HTH, Yes it does - but only to muddy the already murky waters ;-) It is a counter argument to the one that suggests the fewer the better. Actually I've no real preference as yet, other than to avoid the huge rambling if-elsif-else type applications I created in the past. And to be able to re-use functions such as login authentication and session management. I'm really at the stage of trying to find what works best - or at least better than what has gone before. -- Richard Jones Leeds, UK mailto:[EMAIL PROTECTED] - 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] Number of rm's best practice (more)
yes , sorry about that. On 12/18/05, RA Jones [EMAIL PROTECTED] wrote: On Sun, 18 Dec 2005, Jeff MacDonald [EMAIL PROTECTED] wrote: I'm at about the same stage of figuring things out as you are, I'd recommend looking into C::A::P::Dispatch, it can basically parse your query string, to know which module handles which runmode, combine that with AutoRunmodes and you get a pretty cool setup. Did you mean CGI::Application::Dispatch? I cannot find CGI:Application::Plugin::Dispatch on CPAN. -- Richard Jones Leeds, UK mailto:[EMAIL PROTECTED] - 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]
