RE: templating system opinions (axkit?)
> You missed it: > http://search.cpan.org/author/SAMTREGAR/HTML-Template-2.6/Temp late.pm#NOTES Ah. When the section begins "If you're a fanatic about valid HTML" it becomes more clear why I missed that. :-) Thanks, Fran
RE: templating system opinions (axkit?)
> Change that to: > > You mean don't you? Or did I miss the secret stealth hide-your-tags-in-html-comments feature? :-) -Fran
RE: templating system opinions
> In a good OO system with objects > representing the > data model, I found it exhausting to use H::T when I could > just to this > in TT: > > [% user.name %] > > > Am I just being stupid, or are there better ways of doing > these things > in H::T? I'm a little late to the dance but I generally unplug over the weekend. We use H::T here and I too got annoyed with the need to flatten all of my objects. However, with so much invested in H::T by that time, we just wrote a toHash() method which is inherited by all of our objects. It predictably takes the object attributes and churns out a hash (and is smart enough to do a recursive descent if need be). It also take an optional "prefix" so that you could pass in a prefix of "user." and then be able to if you wanted. It was an easy way to reduce the pain of H::T and yet not reinvent the wheel. A simple $tmpl->param($myObj->toHash(prefix => 'user.')) works fairly well in most cases. I'm sure there's a better/more robust way to do it (yeah, switch to TT ;-) but we found that this was sufficient to reduce the annoyance factor enough to allow us to get on with it. Also, we use HTML::Template::Expr to cheat liberally where appropriate. :-) Separation of HTML and logic is a good thing, but like most good things, there are exceptions. Since our controllers were starting to get really cluttered with a lot of "if this simple thing is true then pass this boolean to the template since the template itself can't ask whether this simple thing is true" code, which HTML::Template::Expr helps ease. Hope that helps. I really like H::T for it's simplicity and ease of understanding and picking up for new folks, and didn't want to toss that away unless I had to. -Fran
RE: Basic Auth logout
The only way to expire a basic auth login is to close all instances of the browser. This is not a mod_perl limitation; it's just the way basic auth works. It's pretty easy to spin a mod_perl authentication handler to take the place of basic auth, though. There's some recipes in the cookbook. -Fran > -Original Message- > From: Francesc Guasch [mailto:[EMAIL PROTECTED] > Sent: Friday, March 07, 2003 12:35 PM > To: modperl > Subject: Basic Auth logout > > > this has been asked before, and I've found in the archives > there is no way I could have a logout page for the Basic > Auth in apache. > > Is there nothing I can do ? This is required only for the > development team, so we need to let mozilla or IE forget > about the username and password. > > This is a site built with HTML::Mason. So I tried > <%init> > $m->clear_buffer(); > $m->abort(401); > > with no luck at all > > And would this be possible with mod_perl2 ? > > -- > frankie >
RE: Serving two pages consecutively
IIRC, we just had a thread on this a week or two back. We discussed a couple of solutions Randal had turned into columns in addition to some other suggestions. Maybe peek through the archives? The thread title I believe was 'Please wait Handler' but talked about ways to serve the data piecemeal too. -Fran > -Original Message- > From: Jim Morrison [Mailing-Lists] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 05, 2003 11:07 AM > To: [EMAIL PROTECTED] > Subject: Serving two pages consecutively > > > Hi, > > Anyone got a good/simple way of serving two pages > consecutively with the > minimum of load/hassle etc? Preferably just serving two pages from the > same process. > > The reason being that I need to go off and get quite a bit of > date from > various places and I wanted to feed it back into the page > piecemeal, so > the user gets the impression something's happening... When > all the data > is collected I'd like to move them onto a properly published page.. > > There is an example of the effect I'm after if you run a couple of > domains through: > > http://www.marketleap.com/siteindex/default.htm > > > Thanks, > > > Jimbo > > > _ > Jim Morrison > Technology & Development Partner > Isotope Communications > 9 Green Park Station > Bath, BA1 1JB, UK > +44 (0) 1225 444 674 > > >
RE: Browser doesn't stop loading a page
We had this same problem a while back. One of our developers pecked at it for a couple of weeks off and on, and in our case it turned out to be Javascript. We had some links to the pages that would spin infinitely that looked like: Link we changed them to this: Link and the problems went away. Just thought I'd toss that out there. It's almost definitely not a mod_perl-related problem. -Fran > -Original Message- > From: Chris Winters [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 26, 2003 8:22 AM > To: Martin Moss > Cc: Apache mod_perl > Subject: Re: Browser doesn't stop loading a page > > > Martin Moss wrote: > > Not much to go on I know, but has anybody ever had this problem? > > When I load one of my webpages the browser never stops > loading, e.g. the > > page loads ok and I can see and interact with it, but the > ie spinning globe > > still keeps spinning and the status bar at the bottom of > the page still > > shows the page is loading something.. > > > > The process does seem to run and exit normally in my logs. > I'm at a loss as > > to what is causing it. This only happens on one specific > page on my server. > > Any ideas would be appreciated. > > IME this means you have an external resource (e.g., image, script, > etc.) in the page that's not being loaded because the site is > inaccessible or it's overloaded. Generally nothing to do with > mod_perl :-) > > Chris > > -- > Chris Winters ([EMAIL PROTECTED]) > Building enterprise-capable snack solutions since 1988. >
Anyone ever have Apache::Session::File files getting corrupted?
This is going to be a somewhat preliminary "feeler" post because we are not yet able to fully describe or recreate the bug we're seeing, but I'm hoping some of you have seen something similar. We use Apache::Session::File as the storage module for our Apache::Session sessions. I have written an object (RMS::Session where RMS is our app) that basically is just a wrapper class for the Apache::Sessions. When I instantiate a new RMS::Session, it goes and ties to the actual Apache::Session, gets a hold of the session hash, populates it's member variables with values from the session hash, and unties/undefs the session hash. Thus we end up with a perl object representing our session with a friendly OO interface for our developers that they are used to, and the real session is freed for use by other requests. Everytime I instantiate a new RMS::Session, I timestamp the Apache::Session and I increment a 'retrievals' variable. Pretty much every request into our app needs to look at the session for something, so the end result is that sessions are being tied and written a lot. In some cases, a user will click into an area of our application that has say three frames, and the content of all three frames will go and look at the session, so three requests for the same session could come in at the same time, so it's probably exercising the locking mechanism fairly well. Here's the basic problem we're seeing...our sessions have a very well defined set of variables in them so the size of the session file is very predictable - in our case, they all are between 320-360 bytes at all times. What seems to be happening is that sometimes (more on this later) the files get written out in a corrupted state, and I've noticed it's a well-defined "corruption" to where the session file will shrink to a size of either 150 bytes or 63 bytes. Once this happens, the session is corrupted, in that I can no longer successfully retrieve any information from it. The session is still there, but the contents have been completely garbled. Unfortunately, it's neither predictable nor easy to reproduce. First, it only happens occasionally. we haven't yet found one set of actions that we can take and cause it to happen every time. One test we use to demonstrate it is to simply log in and out several times. Sometimes, 7 or 8 logins will go by without incident, and then the 9th will cause a corrupted session. Other times, 10 logins in a row will lead to a corrupted session. Secondly, it happens far more frequently on our production server than our development server (same exact code and versions of perl and all modules). I've begun to suspect that perhaps it only happens after a certain period of latency. Since our production server has a lot more data in it's database, operations tend to take much longer than they would during development. Perhaps this means that there's more opportunity in production for a request to ask for a session that's still held/locked by another child request. Like I said, it's still very preliminary. Anyway, my question for now is whether anyone has seen corruption like this with Apache::Session::File in your typical multi-user mod_perl web app environment? We're just trying to narrow down the possibilities since it's been two days of four engineers trying to come up with any sort of recipe for reliable reproduction or pattern to the bug with no luck so far. Thanks, Fran
RE: development techniques
> Do you develop with an xterm tailing the logs, an emacs
> window (or other
> editor) to edit the script and/or the packages (and on some occassions
> httpd.conf), and a web browser (on an alternate virtual
> desktop)?
Bingo. :-)
Do you
> pepper code with :
>
> print "option:" . $option{$foo . "" if $debug;
If it's a longer-term debugging option that I might want again later then I
might make a debug() method where I'll do
debug('this worked ok') and the debug() method might examine a flag to see
whether it should do anything with that message.
Or a log() method that recognizes various levels of messages and obeys a
debug_level setting or something. I once used a Java package (the name
escapes me but it was probably something simple like jLog) that worked sort
of this way, though it also had some xml config files and such... anyways,
I'm sure there are plenty of perl modules to do something similar, but the
debug() is a fairly effective 2 minute alternative. If's it just a quick
one-time debug, I'll typically just use a warn or similar.
>
> Fairly low tech, huh.
>
> At apachecon, a speaker (who neither bragged nor rambled)
> mentioned lwp
> use instead of (or to complement) the web browser portion.
>
> Will the use of lwp instead of a browser improve my coding
> ability (either
> in terms of speed or just improving my perl coding)? Seems
> like I'd have
> to spend too much time with the lwp script (tell it to first
> request the
> page then choose option A and B then hit the "submit" button ... )
This sounds more like a testing suite than regular old
debugging-while-you-go. Probably a place for both.
>
> Is there some way to improve this cycle : edit code ->
> refresh browser ->
> possibly look at the error log -> edit code -> ...
Honestly, this method has always been very efficient for us and most of the
time we don't need anything more sophisticated for devel/debug. Now for
more formal testing, that gets trickier for us and we're currently looking
for a good way to build some automated tests of our code and our web
interface without it getting too unwieldy. This will probably be where we
spend a lot of time in the first part of the year. Maybe LWP will be handy
here.
-Fran
RE: OSCON ideas
> I wonder if telecommuting plus occasional travel for > face-to-face would > sell better than pure telecommuting. Is this done very often > in telecommute > situations? This is exactly what I hope to propose if the need arises in my situation. Would love to hear from others who have had success doing this (maybe offline if people feel this is straying too far). -Fran
RE: OSCON ideas
> I suspect that there are actually quite a few people on this > list that would > _love_ to do mod_perl full time. > > open up to telecommuting and I suspect you would soon find > yourself fully > staffed. Definitely. Put me in this category. I'm faced with having to relocate at some point in the not so distant future, and the worst part of it is I'd have to leave my current job where I get to do mod_perl most every day. My preliminary searches aren't looking too fruitful, and I think my first option would be to telecommute to my current job anyway. I'm planning on pitching that idea to them when the time comes that I have to move, but I dunno that they would agree to do it, which would be a shame for both parties. -Fran
RE: OSCON ideas
> 1) Database Objects in Perl > > This talk would focus on the database mapping options for Perl, > including modules like Tangram, Class::DBI, SPOPS, etc. It would > examine the differences in features, ease of use, and performance and > include a set of hand-coded classes using straight DBI for comparison. This would be excellent. I know I personally have struggled mightily with Tangram (I still to this day don't know how to select only records where column A is not null - tore MUCH hair out of head over that one) and would like to know about options that are easier to use. > > 2) The Perl Pet Store > > This would be a discussion of porting the J2EE Pet Store reference > application to Perl. It would cover Perl equivalents for > various J2EE > features, and talk about what was easier or harder to do in Perl. > Because of the size of the Pet Store codebase and the > complexity of the > environment required to run it (multiple databases, etc.), it > may not be > possible to do a good performance benchmark. However comparisons on > other fronts (amount of code, ease of maintenance, etc.) > would be made. I'd be curious on this if only to have some ammunition to show people who say Perl isn't as good as Java and that sort of thing. Also, a reference application on par with the pet store would be a valuable tool in the toolbox for all of us Perl folks and people new to Perl but familiar with Java would probably love this. If I had to pick, though, the first proposal would have more of an impact on my day-to-day perl duties. -Fran
RE: Double execution of PerlRequire statement
Though I have not encountered this problem personally, it's been discussed here a few times before, and a google search of "PerlRequire running twice" turned up a page full of promising leads, so I suggest peeking at the archives and google. -Fran > -Original Message- > From: Andreas Rieke [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, December 18, 2002 4:41 AM > To: [EMAIL PROTECTED] > Subject: Double execution of PerlRequire statement > > > Hi, > > working with apache 1.3.26, mod_perl/1.27 and perl 5.6.0 on a Redhat > Linux 7.2 with kernel 2.4.7-10, I have serious problems with a > PerlRequire statement in the httpd.conf apache configuration > file since > the script is executed twice with the same pid. > > The PerlRequire statement is the first statement concerning > mod_perl in > the configuration file, and there is no other PerlRequire. Any help is > very much appreciated, > > Andreas > >
RE: partial page display
Thanks, finally found the right combination...
{
local $| = 1;
$r->content_type('text/html');
$r->send_http_header;
print "Testing...\n";
}
-Fran
-Original Message-
From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 26, 2002 4:28 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: partial page display
Add a tag. That's what I throw in to force the browser to flush
whatever I fed it onto the screen...
Issac
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, November 26, 2002 9:25 PM
Subject: RE: partial page display
>
> That doesn't work for us. It seems that the browser also maintains a
> buffer, because if I loop the please wait message 1 times, it does
show
> up immediately. I suspect possibly there's some massaging we can do to
the
> header?
>
> Thanks,
> Fran
>
> -Original Message-
> From: Issac Goldstand [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 26, 2002 2:13 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: partial page display
>
>
> local $|=1;
>
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, November 26, 2002 9:11 PM
> Subject: partial page display
>
>
> >
> > I would like to have some of the page display while the rest of the data
> for
> > the page is still being retrieved (i.e. a "Please wait, this operation
> takes
> > several seconds..." kind of message). I thought (perhaps naively) that
a
> > print "Please wait.\n"; at the beginning of my handler would
> accomplish
> > this, but mod_perl seems to cache all output until the entire handler
has
> > returned. Is this possible without the use of a module like CGI::Push?
> > Perhaps I need to modify the header?
> >
> > Thanks,
> > Fran
> >
>
RE: partial page display
That doesn't work for us. It seems that the browser also maintains a buffer, because if I loop the please wait message 1 times, it does show up immediately. I suspect possibly there's some massaging we can do to the header? Thanks, Fran -Original Message- From: Issac Goldstand [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 26, 2002 2:13 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: partial page display local $|=1; - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 26, 2002 9:11 PM Subject: partial page display > > I would like to have some of the page display while the rest of the data for > the page is still being retrieved (i.e. a "Please wait, this operation takes > several seconds..." kind of message). I thought (perhaps naively) that a > print "Please wait.\n"; at the beginning of my handler would accomplish > this, but mod_perl seems to cache all output until the entire handler has > returned. Is this possible without the use of a module like CGI::Push? > Perhaps I need to modify the header? > > Thanks, > Fran >
partial page display
I would like to have some of the page display while the rest of the data for the page is still being retrieved (i.e. a "Please wait, this operation takes several seconds..." kind of message). I thought (perhaps naively) that a print "Please wait.\n"; at the beginning of my handler would accomplish this, but mod_perl seems to cache all output until the entire handler has returned. Is this possible without the use of a module like CGI::Push? Perhaps I need to modify the header? Thanks, Fran
AuthCookie & Frames
I'm having a slight problem using AuthCookie in our app because our app
(unfortunately) is a frames-based interface. To summarize the problem and
efforts I've made to date, my goal is to be able to display a message on the
login page telling them why they are seeing the login page. Options are:
'Login Incorrect', 'Previous Session Timed Out', 'Session Deactivated Due To
Login From Another Location', etc...
My first attempt was to try to just set values in the subprocess_env, and
since AuthCookie works by removing a user's cookie and then doing redirects
to the login page if a user is not validly logged in, I could always just
look at $r->prev->subprocess_env('login_error_msg') for the cause. However,
since I am using frames, this doesn't work in all cases.
If for example a user is currently at a part of the site that has three
frames, and then walks to his co-workers office and uses that computer to
log in, we have invalidated his old session back at his desk. If he goes
back to his own desk and tries to navigate in the app, we want to redirect
to a login page with the message 'Session Deactivated Due To Login From
Another Location'. However, what happens is that he goes to click on
something, javascript gets called that changes the contents of all three
frames, so all three frames try to load new content. This means 3 new
requests, and 3 passes through AuthCookie. Well the first pass through
works exactly like I would expect and
$r->prev->subprocess_env('login_error_msg') has the proper error message.
The problem is that the other two requests also go through AuthCookie, and
since the first one already removed the cookie, the other two just see that
the user doesn't have a cookie and also redirect to the login page. So what
the user is seeing is really the third redirect to the login page, which no
longer has any useful info in $r->prev->subprocess_env.
So my next thought was that we need some sort of global "login messages"
object that could be shared across children and requests and could hold
login failure messages. Since I'm already using Apache::Session, I thought
following the cookbook's recipe on how to use A::S for global data would be
good. So I set up a session with a known key ("_loginmsgs") but then
realized there's no piece of info I can use to uniquely identify a
particular user/browser so that I can store a message for him. I can't use
the session key since by the time it comes to look up if there are any
messages I should be displaying on the login page, there's no longer a
session key to reference (the cookie has been removed). I then thought I
could just try the IP address but firewalls could make multiple users look
to be coming from the same IP. I never really came up with something I
thought would work and was clean. So, finally, the question is has anyone
solved this same problem, or does anyone have any ideas of what I should
try?
Thanks,
Fran
RE: Easy internal redirect question
After further review, the problem was CGI.pm. CGI.pm doesn't appear to get
'reset' on an internal_redirect (I'm not familiar with CGI's support for
mod_perl, so maybe this should have been obvious!) so it was still holding
the old parameter values. A quick install of Apache::Request and a call to
$r->param('task') give much better results. CGI was a remnant from our
pre-mod_perl days and I've been meaning to get rid of it for a while.
Thanks,
Fran
RE: Easy internal redirect question
I've got a bit of a better grasp on the problem nowI think it's an
interaction with POST data...
I have a form in foo.html
...other form fields...
I submit this form, and in /rms/admin, it gets handled like this
# suck in form values, stick them in objects, blah blah, then get to the
redirect...
$r->internal_redirect('/rms/status?task=display');
and what happens is that /rms/status complains that it doesn't know how to
handle task=process_config. So, somehow the value for 'task' that was
POSTed in the first request from the form gets passed onto the second
request, apparently overriding the
'task' value of 'display' which I am trying to set in the url string I'm
giving to internal_redirect().
I don't want any of the POST data to get passed onto that redirect. Any
thoughts? I saw a note in the API docs that $r->args() can be used to set
the query string and that this is useful when redirecting POST requests. I
tried doing a $r->args('task=display') right before the call to
internal_redirect, but no luck.
Thanks,
Fran
-Original Message-
From: Geoffrey Young [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 02, 2002 1:06 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Easy internal redirect question
[EMAIL PROTECTED] wrote:
> I call a page, /my/script1?task=foo which does some things and then needs
to
> redirect to /my/script2?task=bar. However, putting
>
> $r->internal_redirect('/my/script2?task=bar');
>
> doesn't seem to work as script2 is seeing task=foo rather than task=bar.
> Looks like the internal_redirect is also passing along the form params to
> the second request. How is this avoided? I'm looking through the
cookbook
> recipe on internal redirects but nothing is jumping out at me at the
moment.
that's pretty odd.
given two scripts, one.pl:
shift->internal_redirect('/perl-bin/two.pl?internal=redirect');
return Apache::OK;
and two.pl:
my $r = shift;
$r->send_http_header('text/plain');
print "args is ", scalar $r->args, "\n";
I get the right results:
$ GET localhost/perl-bin/one.pl?main=request
args is internal=redirect
are you returning OK right after your internal redirect? does setting
$r->args() before calling the internal redirect to a third value
change anything?
--Geoff
Easy internal redirect question
I call a page, /my/script1?task=foo which does some things and then needs to
redirect to /my/script2?task=bar. However, putting
$r->internal_redirect('/my/script2?task=bar');
doesn't seem to work as script2 is seeing task=foo rather than task=bar.
Looks like the internal_redirect is also passing along the form params to
the second request. How is this avoided? I'm looking through the cookbook
recipe on internal redirects but nothing is jumping out at me at the moment.
Thanks,
Fran
RE: mod perl and apache with ssl and openssl
> Can anyone advise me on how to build >apache server with ssl and openssl and >using mod perl. It's right there in the user's guide. http://perl.apache.org/docs/1.0/guide/install.html#mod_perl_and_mod_ssl___op enssl_ -Fran
