Re: separating C from V in MVC
Ray Zimmerman wrote: So how is everybody else handling URL mapping? In the filesystem. Directly requested .tt files are all sent to a default template handler: Location /tt_engine SetHandler perl-script PerlHandler UAL::TTEngine /Location AddType text/tt .tt Action text/tt /tt_engine The default template handler provides a list of controllers via the Stash, allowing the layout people to place a link to a controller anywhere. Controllers may be re-used with modified behavior: % cat admin/proj-edit.tt [% Ctrl.DBEdit.run(ObjectType = 'Project') %] % cat admin/task-edit.tt [% Ctrl.DBEdit.run(ObjectType = 'Task') %] % cat admin/usermanager.tt [% Ctrl.UserManager.run() %] % cat admin/mailclient.tt [% Ctrl.MailClient.run() %] % cat user/mailclient.tt [% Ctrl.MailClient.run(AllowPOP3 = 0, AllowIMAP = 0, AllowMIME = 0) %] -jh
Re: separating C from V in MVC
Perrin Harkins wrote: On Mon, 10 Jun 2002, I wrote: In the filesystem. Directly requested .tt files are all sent to a default template handler: Those are both interesting and may be the most appropriate solution for the problems you're working on, but I wouldn't call either of them MVC. You are going straight to a view (template) and letting it drive all the decisions. In an MVC application, you would go to a controller that would do some work and then decide which view to show. I have three kinds of templates: controller entry stubs - called directly to invoke a controller view pages - called by controllers to display results stand-alone dynamic pages - called directly, may not invoke controller I would agree with you if my entry stubs did more than call up the controller, but those templates are simple one-liners that do nothing else. Once the controller has been called it takes over, processing request data, calling models, selecting views, etc. The only influence a stub template has on the view is that of defining the URL that the controller inherits (plus optional parameters as shown in my earlier message). Yes, a developer could make a mess of things by trying to put more stuff into a controller entry stub. We all seem to agree that any scheme can be polluted by poor discipline, and the arrangement I have described is as prone to abuse as any other. Still, I don't think that replacing this: Location /search SetHandler perl-script PerlHandler Controller::Search /Location with this: [% Ctrl.Search() %] makes Controller::Search any less a controller. I could enforce the separation of controller entry stubs from stand-alone templates and view templates by using additional file extensions and handlers, but no one has abused the system as it is so I'm erring on the side of my own laziness. Using the entry stub templates is handy because I don't need to mangle the server configuration to make controllers available from other locations (which means I can stay at the pub while others toil away). Obviously, the stand-alone dynamic pages are not MVC at all. They exist because there are often 'glue' pages that don't warrant the comlexity of MVC (those that don't need M and have very simple VC needs). It is much more convenient to code such pages in the same environment as the MVC stuff (that is, using the same globally defined variables, macros, etc.). -jh
Re: Handling the 'User pressed Stop button' case - not working
Matthew Darwin wrote: On Sat, 26 May 2001, Stas Bekman wrote: You right. It seems that mod_proxy won't abort on SIGPIPE. So how can I get it to without breaking everything else? Any ideas? I have a process that takes 2-3 minutes to run before the user gets any any output. I tell them to wait, but they get impatient. If they hit STOP I really want to know about it so I can free up CPU resources for when they hit RELOAD to try agin. Any helpful hints would be most appreciated. Run the process in the background. Have the browser loop on a reporting URL w/request ID. That will allow you to show progress: * The initial request generates a processing job. Please see previous threads regarding the wisdom of forking mod_perl processes. You may want to consider writing a lightweight daemon to take processing requests from mod_perl via a unix domain socket. * Return a starting page to the client which will refresh to a progress reporting URL, which may be the same URL as the original request (be sure to include a UUID or some other identifier for the job). * Each time the progress URL is called, check on the status of the processing job. Return the data if available, or return another refresh. Also: * The progress URL can use the UUID to generate updated status info. If you are clever, you can even offer a status bar. * If you keep the results of your processing jobs indexed by, say, the MD5 of the request parameters that created them, you can skip redundant processing runs. -jh
Re: Apache::ASP
You may also want to try
unless(UNIVERSAL::can($r, 'filename')){
...
}
which also nicely avoids having to test $r first.
-jh
At 05:05 PM 1/25/01, Joshua Chamas wrote:
Anyone see why a $r = Apache=SCALAR(0x8461790) might not
respond true to $r-can('filename') on Ilya's below FreeBSD
setup? The relevant ASP code is below.
Ilya, worst case, you can tweak that code to make it
work for you, for example does a line like
unless($r ($r =~ /^Apache/)) {
work instead ? This might be a suitable test.
--Josh
sub handler {
my($package, $r) = @_;
my $status = 200;
# allows it to be called as an object method
ref $package and $r = $package;
# rarely happens, but just in case
unless($r $r-can('filename')) {
# this could happen with a bad filtering sequence
warn(ERROR);
No valid request object ($r) passed to ASP handler; if you are getting
this error message, you likely have a broken DSO version of mod_perl
which often occurs when using RedHat RPMs. One fix reported is to
configure "PerlSendHeader On". Another fix is to compile
statically the apache + mod_perl build as RedHat RPMs have been trouble.
Please check FAQ or mod_perl archives for more information.
ERROR
;
Ilya Krel wrote:
I am running Freebsd 4.2, Summary of my perl5 (5.0 patchlevel 5 subversion
3), Apache/1.3.14, mod_perl/1.24 (from ports collection).
Apache:ASP installed from cpan says:
Bundle id = Bundle::Apache::ASP
CPAN_USERID CHAMAS (Joshua Chamas [EMAIL PROTECTED])
CPAN_VERSION 1.00
CPAN_FILEC/CH/CHAMAS/Apache-ASP-2.07.tar.gz
MANPAGE Bundle::Apache::ASP - Install Apache::ASP and related
modules
CONTAINS MLDBM Data::Dumper MD5 CGI HTML::Clean Net::SMTP
HTTP::Date
Devel::Symdump Apache::DBI Compress::Zlib Tie::Cache Time::HiRes
Apache::ASP
INST_FILE/usr/local/lib/perl5/site_perl/5.005/Bundle/Apache/ASP.pm
INST_VERSION 1.00
when i try to access the examples in site/eg I get thsi in error_log :
No valid request object (Apache=SCALAR(0x8461790)) passed to ASP
handler; if
you are getting
this error message, you likely have a broken DSO version of mod_perl
which often occurs when using RedHat RPMs. One fix reported is to
configure "PerlSendHeader On". Another fix is to compile
statically the apache + mod_perl build as RedHat RPMs have been trouble.
Please check FAQ or mod_perl archives for more information.
any suggestions how to fix it?
thx
Re: cookies cookies cookies
At 01:47 PM 12/12/00, Joshua Chamas wrote:
Greg Stark wrote:
How do I reliably remove a cookie from a browser's memory?
Then Josh said:
What about setting the cookie with an expires date in the past?
$Response-{Cookies}{YourCookie} = {
Value = '',
Expires = -86400,
};
In most cases, this will only work for a cookie that is an _exact_
match with the one you wish to expire. This is really hard to do
if your code didn't write the cookie, since most browsers will use
the 'path' and 'domain' values to evaluate exactness, but do not
send those values to you in a request, obscuring them.
While writing a cookie handling library, I found it necessary to
trash my cookies file when things got weird, since writing code
to remove cookies that were the result of bad code seemed a waste
of time. Once it was stable it worked rather well, assuming that
calls to the library were consistent about 'path' and 'domain'.
Unless you're required to use 'path', I recommend that you explicitly
set 'path' to '/' on all set cookie operations, and similarly make
use of a canonical 'domain' value. Then it will be easy to construct
'kill cookies'. Otherwise, you'll have to construct logic to determine
the right 'path' and 'domain' for a particular cookie (yech).
-jh
Re: Text::Template, PACKAGES, ModPerl
"goEbusiness.com Mail Lists" wrote:
Ok, here's the scenarious.
snip
Is there a quick easy way to reset all of those variables for
each time the script is run? I'm assuming no. I did make a
function that ran through the package, like so:
snip
From my own bag-o-tricks, this simply obliterates the contents of
the desired package. YMMV.
# Nuke the template's package namespace.
# Based on the inner workings of Safe
#
sub _kill_package {
my $package = shift;
no strict 'refs';
my $pkg = "main::$package\::"; # expand to full symbol table name
my ($stem, $leaf) = $pkg =~ m/(.*::)(\w+::)$/;
my $stem_symtab = *{$stem}{HASH};
if(my $leaf_glob = $stem_symtab-{$leaf}){
my $leaf_symtab = *{$leaf_glob}{HASH};
%$leaf_symtab = ();
return(1);
}
return();
}
-jh
Full Time Position Available
Santa Monica, CA company has immediate full time opening for advanced Perl programmer to assume maintenance and expansion of running site. Current environment is Linux/Apache/mod_perl/MySQL. Relaxed work environment. Salary and benefits commensurate with experience. Reply to me directly, please. -jh
