[Catalyst] Catalyst-Plugin-Cache-FileCache-0.6
doesn't make because the inc dir is missing. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Mojomojo installation
Hi all, I wanted to check out latest Mojomojo from CPAN, but got several failures in the installation: make fails because of missing dependency for Text::Markdown. make test failures: - t/c/page.t needs a current Catalyst::Action::RenderView. I've got errors with 0.04 that disappeared with current 0.07. - t/c/page_edit.t fails test #4 and #6 because the order of the expected HTML attributes is not the same (expects input\s+value=\s+name=parent\s+type=hidden\s+/ but gets input type=hidden name=parent value= / ) - t/schema_DBIC_Attachment.t: test defines attachment_dir as t/var/upload, but only t/var exists when test runs - t/schema_DBIC_Page.t: not ok 9 - new children returned as descendants of root # Failed test 'new children returned as descendants of root' # at t/schema_DBIC_Page.t line 55. # Structures begin differing at: # $got-[1] = 'admin' # $expected-[1] = 'child' -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] A Perl Message Queue?
J. Shirley wrote: On 8/24/07, Bernhard Graf [EMAIL PROTECTED] wrote: So either you want to do queueing overhead, dns resolving and SMTPing to the *remote* host yourself or you simply open(MAILER,|sendmail @args). -- Bernhard Graf That's not entirely true, in as much as it may be technically correct but in reality could bite you in the ass. If you send out a lot of emails, you'll likely piss off a lot of admins if you open/close a bunch of connections and send one email a piece Better to send out in a group while you have the socket open... The message was not about how to write the better mailer. The intention was about using things that are already there and probably good (enough) instead of re-inventing the wheel and wasting your own and your system's resources. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] A Perl Message Queue?
Hartmaier Alexander wrote: So TheSchwartz may be a good module to queue mails by a Catalyst app for sending them by let’s say a perl script run by cron (or running all the time)?! At the moment I’m sending the mails directly from my Cat app (SMTP to localhost mail daemon) which works flawless (as long as the local MTA runs). Don't know about TheSchwartz (btw. what a stupid name), but MTAs have their own message queues, so no need for another one. SMTPing to localhost usually doesn't make much sence - it is slow and as you mentioned already it causes trouble when the daemon is down or slow. So either you want to do queueing overhead, dns resolving and SMTPing to the *remote* host yourself or you simply open(MAILER,|sendmail @args). -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FCGI automatic restart / memory leaks
On Thursday 16 August 2007 10:40, Tobias Kremer wrote: I just deployed our quite large Catalyst app and I'm seeing a constant increase in memory usage. Here's a current snapshop from top: We're using lighttpd and handle the starting of the FCGI server manually. Is there a way to have the FCGI children restart once in a while without having to restart the whole FCGI process manager (and bringing down the application for a few seconds)? Something like Apache's MaxRequestsPerChild directive would be cool. I use daemontools similar to http://www.catalystframework.org/calendar/2006/4 . My run file looks like this: #!/bin/sh cd /srv/www/vhosts/myapp exec 21 \ setuidgid myappuser \ softlimit -m 15000 \ script/myapp_fastcgi.pl -e -l /var/tmp/myapp/fastcgi.socket -n 10 Sets uid and gid to myappuser , Spawns 10 processes and listens on the specified UNIX socket. If a process gets too big, it gets terminated and replaced by a fresh one (softlimit is part of daemontools, but you could use ulimit instead). Then it's time to go memory leak hunting :( I don't care much since softlimit restarts the FCGI processes (under normal conditions approx. every 12 hours). BTW - here are the manpages for daemontools http://smarden.sunsite.dk/pape/djb/manpages/daemontools-0.76-man.tar.gz HTH -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FCGI automatic restart / memory leaks
On Thursday 16 August 2007 13:42, Tobias Kremer wrote: Quoting Bernhard Graf [EMAIL PROTECTED]: I use daemontools similar to http://www.catalystframework.org/calendar/2006/4 . Thanks! I'll take a look at it. You should definitely do that. Not only for this case - daemontools (or similar like runit) are superior for nearly every server service on *ix OSes. Check out http://smarden.org/runit/runscripts.html and compare the scripts with typical System-V run scripts (not mentioning the supervision concept in general). For now I'm gonna try running two independent FastCGI process managers and restart them on different hours via a cronjob so that one of them will always be available to lighttpd. Other solutions are still welcome! :) Why two FCGI process managers? To compensate FCGI downtimes? Did you find a way to tell lighttpd not to talk to an FCGI process that is down? I only get a 500 error in that case. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] FCGI automatic restart / memory leaks
On Thursday 16 August 2007 14:32, Tobias Kremer wrote: Quoting Bernhard Graf [EMAIL PROTECTED]: You should definitely do that. Not only for this case - daemontools (or similar like runit) are superior for nearly every server service on *ix OSes. Check out http://smarden.org/runit/runscripts.html and compare the scripts with typical System-V run scripts (not mentioning the supervision concept in general). I suppose that the whole fcgi-pm process will be restarted instead of individual fcgi processes, correct? That'd mean a downtime of about 5 seconds which would render it useless to me :( No. The softlimit applies to each of the processes forked by the master, so each process is terminated if it gets too fat. Why two FCGI process managers? To compensate FCGI downtimes? Did you find a way to tell lighttpd not to talk to an FCGI process that is down? I only get a 500 error in that case. I just _hope_ that lighttpd will do the right thing as the error log tells me this when a backend server goes down: connect failed: Connection refused on unix:/srv/webapp.socket backend died; we'll disable it for 5 seconds and send the request to another backend instead: reconnects: 0 load: 1 Just by setting multiple socket entries in the lighttpd-conf? -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] TT2 + CP::Authentication + DBIC gotcha
apv wrote:
This does not:
[% vote = Catalyst.user.votes({word = w.id}) IF Catalyst.user_exists
%] [% IF vote %]
You rated this “[% vote.rating %]”
[% END %]
and yields for all cases (and columns): You rated this
Try
[% SET vote = Catalyst.user.votes({word = w.id}) IF Catalyst.user_exists %]
(http://search.cpan.org/~abw/Template-Toolkit-2.19/lib/Template/Manual/Syntax.pod#Capturing_Block_Output)
--
Bernhard Graf
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] debug mode
John Goulah wrote: What is the best way to deal with the -Debug flag between a production and development environment? Obviously its not desirable to go into the file and remove the flag every time the code goes to prod. I see you can start the stanalone server with -d to force debug. I think I remember about an environment variable to set debug also. Is the preferred method to take the hardcoded flag out and use one of these, or is there another way (such as a config option)? How are people dealing with this? If you start your development server from the command line, set environment variable CATALYST_DEBUG=1, e.g. CATALYST_DEBUG=1 script/myapp_server.pl -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] session issue
Gaurav Talwar wrote: I am using session to store all his details he is filling in the form. When he goes back to the previous pages, i take the information from the session and i fill them in the pages. Now the problem is that if users opens two forms together and fills some data and then I suppose you mean the same user opens two instances of the same form... goes back to previous page, the session shows him the data (he filled in the second form )in the first form. I know the problem is that they are using same session. But how to avoid this? Any help will be highly appreciated! Actually this isn't a Catalyst issue. You will always have this problem when using sessions that share the same store for multiple requests. Two options to avoid the problem: - Store already received data in hidden fields of the subsequent forms. - Use Apache::Session::Counted. This provides a new session data container for every request. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] session issue
mla wrote: Two options to avoid the problem: - Store already received data in hidden fields of the subsequent forms. This is almost always the best approach, IMO. The state of the form is kept with the form, where it belongs. There are no synchronization issues with the session. This applies to the 2nd option, Apache::Session::Counted, as well. Instead of storing everything in hidden fields, you only have to pass a session key, that is unique for every new request. With A:S:C you are able to store arbitrary complex data (all that Storable can handle). -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Redispatching actions
Matt S Trout wrote: Engage in the technical debate or be removed from this list just as quickly as a $religion extremist who refused to justify -their- position would be. This is your final warning. Cool down Tony^H^H^H^H^HMatt. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Redispatching actions
Matt S Trout wrote: On Sun, May 20, 2007 at 08:55:47PM +0200, Bernhard Graf wrote: No need for redirects and all the problems they impose. I described the problems with -not- redirecting and yet you assert their being bad without justification. See my other response. You can stay with redirects. No problem for me. ;^) I just pointed out that you don't need them. I call straw man. Defend your position or withdraw, sir. Hä?? -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Redispatching actions
Roland Lammel wrote: But then again this code has to be added to every method, that is processing form input. In case it's not there... the nightmare of reposting is back in town. What are you trying to demonstrate? If more code isn't there, even more nightmares are in town - or what? I find it far more easy to actually perform a redirect at the end of an action, that is intentional for the user and the developer. I havn't come across any problems using redirects (not even on mobile devices), so what kind of problems are you referring too? - Loosing state within one http request or maintaining additional overhead to keep it beyond the redirect - imposing additional load to the server - trouble GET after POST under mod_perl as described in http://perl.apache.org/docs/1.0/guide/snippets.html#Redirecting_POST_Requests . Well, actually I suspect Catalyst already does the right thing, but I was bitten by this issue long ago in the pre-Google era when you could hardly find anything about this on the WWW. But as usual, it's probably a matter of taste anyway. Indeed. Whenever I have to fix somebody else's web application (usually PHP), the number of HTTP redirects is inversely proportional to the quality of the code. So probably that is the main reason why I try to avoid them personally. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Redispatching actions
A. Pagaltzis wrote:
* Bernhard Graf [EMAIL PROTECTED] [2007-05-20 21:05]:
A. Pagaltzis wrote:
That, plus the re-submit when the user hits the Back button.
...
unless ($c-validate_token) { # Catalyst::Plugin::RequestToken
$c-stash(message = 'Deja vu!'); # optional verbosity
$c-detach('view');
}
So loading an extra plugin and sprinkling guards all over your
code is preferrable to you over simply issuing a redirect. Not
Yes.
only that, but your choice causes the following sequence of
events:
User: *hits Back button*
Computer: This page has POSTDATA. Resubmit it?
User: (thinks) What the?! Hmm… err…
User: *hits OK*
Computer: Ack! You tried to resubmit a form! No cookie!
User: @#$!!
Compare to the alternative, where successful submit produces a
redirect:
User: *hits Back button*
Computer: *goes back a page*
Guess which one will annoy users less.
Written very nicely. Actually both variants are designed to keep posting
data twice, right?
You said absolutely nothing to address the “wrong URL” problem
Matt mentioned, btw.
What wrong URL?
My example showed that http://example.com/data/update is virtually equal
to http://example.com/data/view if not posted from a form.
Of course, you can spend your days writing code to fight the way
HTTP works. It’s up to you to judge whether that is a worthwhile
use of your time. But I do think you’d be happier and your code
simpler and more robust if it didn’t try to cut against the web’s
grain.
I don't fight HTTP. A link is one thing, an action is a different one.
While the first always is a static route to some other place, the latter
*acts* upon (input) data and the resulting output depends on this input
data and potentially other data as well (like this RequestToken status,
that tells that the transaction has already been processed when trying
to redo the action, or the request method not being POST).
No need for redirects and all the problems they impose.
Can you explain one the problems, please?
See my other post.
Redirects are one of the greatest features of HTTP, actually.
As GOTO is one of the greatest features of Basic - and of course Perl.
--
Bernhard Graf
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Redispatching actions
A. Pagaltzis wrote:
* Matt S Trout [EMAIL PROTECTED] [2007-05-20 15:55]:
I worked on some Maypole apps a few years back that -didn't-
redirect and behaved the way you're looking at implementing and
the wrong URL problem turned out to be a usability nightmare
sub update : Local {
my ($self, $c) = @_;
$c-detach('view') unless $c-request-method eq 'POST';
...
That, plus the re-submit when the user hits the Back button.
...
unless ($c-validate_token) { # Catalyst::Plugin::RequestToken
$c-stash(message = 'Deja vu!'); # optional verbosity
$c-detach('view');
}
# do update here
...
$c-remove_token;
$c-forward('view');
}
I'd strongly, strongly recommend against it, sending a 302
really isn't that bad.
Or 303. ;-)
No need for redirects and all the problems they impose.
--
Bernhard Graf
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Tip: Serving Static Files with lighttpd
Kieren Diment wrote: On 08/05/07, Matt S Trout [EMAIL PROTECTED] wrote: On Fri, Apr 20, 2007 at 10:05:54AM +0200, Bernhard Graf wrote: Wherever I looked I only found advice how to serve static files with Apache. Here is the same for lighttpd: Fantastic. Could you POD this up for a cookbook patch please? Done :) Thank you. :-) -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Bug in Catalyst::finalize_headers()
Matt S Trout wrote: On Sun, May 06, 2007 at 12:02:51PM +0200, Bernhard Graf wrote: A patch against the svn trunk is attached. You seem to have only sent half the patch - could you try re-sending it and make sure the test is attached this time please? Of course you're right. But I'm not so familiar with the Catalyst code and esp. the tests, so writing appropriate tests is quite difficult for me. I would like to contribute more, but I simply don't have the time ATM. Andy Grundman has already applied a patch similar to mine. Lucky me. ;-) -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with RenderView
Matt S Trout wrote: On Fri, May 04, 2007 at 04:24:12PM +0200, Bernhard Graf wrote: On Friday 04 May 2007 15:58, Bogdan Lucaciu wrote: Your example is superfluous, because this is what my application looks like basically. I think you didn't read the documentation, and are being offensive as a result. See my reply to your original message for the mistake you've made. ~ # man Catalyst::Action::RenderView | grep current_view | wc -l Reformatting Catalyst::Action::RenderView(3pm), please wait... 0 -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with RenderView
Matt S Trout wrote: Why can't you just set $c-stash(current_view = 'MyCSVView') and let RenderView work its magic the normal way? With the help of some helpful people I already came to this solution. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Bug in Catalyst::finalize_headers()
Next episode from my attempts in writing a serialization view class:
After I learned that finalize_body() can read from an object (that
can('read')) or from a file handle, I implemented the idea of sending
data through a pipe.
In short the View class does:
package CatalystX::View::DBIC;
use IO::Pipe;
sub process {
my ($self, $c) = @_;
[...]
$pipe = new IO::Pipe;
if ($pid = fork()) { # here's the parent
$pipe-reader; # parent reads from child
$c-response-body($pipe);
return;
}
# here's the child
$pipe-writer; # child writes to parent
# read from the DBIC result set
while ($row = $rs-next) {
# write formatted (e.g. CSV) data into pipe
$pipe-write($self-format($row, $columns));
}
close $pipe;
exit(0);
}
The idea is that process() sets up the pipe, forks a sub process that
does the long lasting reading from db and writeing into a pipe, whereas
the parent stores the other end of the pipe handle into
$c-response-body() and returns immediatly. Then finalize_body() would
hopefully read from the pipe and write data to the browser as soon as
the child process stores the first lines into the pipe.
Unfortunately this failed. Firefox only stored about 930 bytes, then
dropped the connection whereas Konqueror didn't write anything.
Many hours later I discovered the reason: The response header had a line
Content-Length: 0
Aaargh!
This header line is automatically created by this code in
Catalyst::finalize_headers():
if ( my $stat = stat $c-response-body ) {
$c-response-content_length( $stat-size );
}
Apparently this assumes that $c-response-body is a filehandle of a
regular file, but you can stat any kind of file (remember: in UNIX
everything is a file) and for a pipe $stat-size is 0!
I fixed the code and now it works as expected, though chunked
transfer coding*) would be a nice feature in the absence of a
Content-Length header.
A patch against the svn trunk is attached.
*) http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6.1
--
Bernhard Graf
Index: lib/Catalyst.pm
===
--- lib/Catalyst.pm (Revision 6362)
+++ lib/Catalyst.pm (Arbeitskopie)
@@ -12,6 +12,7 @@
use Catalyst::Controller;
use Devel::InnerPackage ();
use File::stat;
+use Fcntl ();
use Module::Pluggable::Object ();
use NEXT;
use Text::SimpleTable ();
@@ -1428,7 +1429,8 @@
if ( blessed( $c-response-body ) $c-response-body-can('read') )
{
if ( my $stat = stat $c-response-body ) {
-$c-response-content_length( $stat-size );
+$c-response-content_length( $stat-size )
+ if Fcntl::S_ISREG($stat-mode) || Fcntl::S_ISLNK($stat-mode);
}
else {
$c-log-warn('Serving filehandle without a content-length');
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Bug in Catalyst::finalize_headers()
Andy Grundman wrote: Yeah, I'll see about applying your patch so that in your case there would be no Content-Length set. Thank you. BTW Catalyst::Plugin::Compress::Zlib also needs some work, because it generally takes $c-res-body as a scalar buffer. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Questions about $c-write
While working on my View classes (see http://lists.scsys.co.uk/pipermail/catalyst/2007-May/013120.html) I found this (sparse) description about Catalyst::Engine::write(): Writes the buffer to the client. Can only be called once for a request. Is the second phrase correct? I couldn't see why and at least finalize_body() from the same package can do many calls to write() for one request. Then I'm a little confused about Catalyst::Engine::FastCGI::write(): In the source you find *STDOUT-syswrite($buffer); Looks like IO::Handle is loaded somewhere, but this turns out as a mistake, because other than documented this syswrite() doesn't return the number of bytes written - at least not as a Perl integer value, but instead returns the size as a binary value. Because the class of this syswrite hides behind the STDOUT glob, I'm not able to track this bug up to the origin. Anybody knows what's behind the file handles in this module? -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Questions about $c-write
Bernhard Graf wrote: What bug are you seeing? I see syswrite() returning something binary - not a Perl integer as documented. This binary value can be unpack(U*, $rc)'ed to get the correct/expected value. This is especially a problem when writing is not possible (client cuts the connection) where syswrite is expected to return a false (0) value: In this case Catalyst::Engine::FastCGI::write() returns a one byte string containing a NULL which is regarded as true (the subsequent call to write() returns an empty string indicating failure if used in a boolean context). -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with RenderView
On Friday 04 May 2007 15:41, Bogdan Lucaciu wrote: On Friday 04 May 2007 13:34, Bernhard Graf wrote: For a Catalyst application I have written View classes that serialize DBIC ResultSets to common formats (CSV, XML) to be stored to disc. [...] First of all, why are you sending your response from the controller and not from the view? ??? RenderView doesn't use a default view, it uses $c-view(); You can read about it here: http://search.cpan.org/perldoc?Catalyst#%24c-%3Eview(%24name) $c-view() uses a default_view class if configured. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with RenderView
On Friday 04 May 2007 16:59, Jay K wrote:
RenderView basically forwards processing to your view object. It
has some 'outs' to avoid doing that when it is inappropriate,
as in when body is filled out or you are redirecting, etc. But there
is no 'just don't do it' flag.
That's why I added this don't do anything if finalize_headers() has
already been executed behaviour.
What Bogdan was trying to tell you is that while, yes, your code does
do the write, doing it inside your controller is somewhat against the
MVC method generally used in Catalyst. Which means, essentially,
that you are going to run into problems with the modules because they
all expect MVC behavior.
And what I'm telling since the first message in this thread is, that I
have View classes, that $c-write() instead of $c-response-body().
link: http://jayk.vox.com/library/post/picking-a-view.html
Bingo! I wasn't aware of this current_view variable.
So instead of $c-forward('MyApp::View::DBIC::CSV') I now say
$c-stash(current_view = 'MyApp::View::DBIC::CSV') and can go with the
current Catalyst::Action::RenderView.
Thank you very much.
--
Bernhard Graf
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Problem with RenderView
On Friday 04 May 2007 17:55, Bogdan Lucaciu wrote: On Friday 04 May 2007 18:24, Bernhard Graf wrote: Bingo! I wasn't aware of this current_view variable. Well I told you about it in my first mail. And my second. Ignored it , twice. Indeed, sorry. I just didn't notice, because in your answers you referred to other things. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] forwarding to chained actions
Is there a way to forward to (the end point of) a chained action and run
the whole action chain again?
Simplified example:
sub instance : PathPart('') Chained('/') CaptureArgs(1) {
my ($self, $c, $data_id) = @_;
# fetch data for $data_id and put on stash
$c-stash(data = $self-fetch_data_for_id($data_id));
}
# view data
# /data/DATA_ID
sub view : PathPart('') Chained('instance') Args(0) {
my ($self, $c) = @_;
$c-stash(template = 'view.tt');
}
# update data from form
# /data/DATA_ID/update
sub update : PathPart Chained('instance') Args(0) {
my ($self, $c) = @_;
my $data = $c-stash-{data};
$self-update_from_form($data);
$c-forward('view'); # view data
}
update() updates the data in the database but $c-stash-{data} is not
changed. Then forward('view') calls view(), but this view's the
unchanged (outdated) data from the stash.
Of course I could do a $c-stash(data = $data) before
$c-forward('view'), but as stated this is only a simple example.
In many cases it would be convenient to have something like
$c-forward_chain('view') to execute all methods of the chain.
Does such a thing exist in Catalyst?
--
Bernhard Graf
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] forwarding to chained actions
Roberto Henríquez wrote: if you end your update action with a forward, you also have another problem. The user ends up viewing the data item under a /data//update URL; I consider way more elegant to issue a redirection to the view data uri right after the update. Thus, in your case I would do $c-res-redirect( $c-uri_for( /data/$id) ); after the update is done. And the address displayed in the browser would be /data/xxx instead of an ugly update url. Well, thank you, but redirects are the things I try to avoid for several reasons. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: forwarding to chained actions
Matija Grabnar wrote: _ALL_ POSTs should be followed by a redirect, ALWAYS. I agree. Sigh. I don't want to be rude, but could you guys open your own thread when you want to discuss pros and cons of forwards and redirects? Tanks a lot. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: forwarding to chained actions
Nilson Santos Figueiredo Junior wrote: On 4/24/07, Bernhard Graf [EMAIL PROTECTED] wrote: I don't want to be rude, but could you guys open your own thread when you want to discuss pros and cons of forwards and redirects? This is the classic XY problem[1]. They're trying to show you that Y is bad for solving X. No one wants to discuss the pros or cons of forwards vs redirects (since it's an already settled debate). They're trying to show you the proper way of solving X. I've already found *my* proper way. None of the alleged problems apply to my application. That said I would like to repeat my question: Is there a way to forward to (the end point of) a chained action and run the whole action chain again? Just forget about the example. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Tip: Serving Static Files with lighttpd
Wherever I looked I only found advice how to serve static files with
Apache.
Here is the same for lighttpd:
First assign your document root (server.document-root /
simple-vhost.server-root / evhost.path-pattern)
Then, assumed your FastCGI configuration looks like this:
fastcgi.server = (
= (
MyApp = (
socket = /tmp/myapp.socket,
check-local = disable,
)
)
)
If you want everything in /static to be served by lighttpd directly
enclose the above in
$HTTP[url] !~ ^/static/ { ... }
Here is a complete example that serves favicon.ico and everything
in /img and /css by lighttpd:
$HTTP[url] !~ ^/(?:img/|css/|favicon.ico$) {
fastcgi.server = (
= (
MyApp = (
socket = /tmp/myapp.socket,
check-local = disable,
)
)
)
}
Enjoy the boost
--
Bernhard Graf
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Setting cookie_domain
On Monday 16 April 2007 18:55, Bernhard Graf wrote:
The code I posted yesterday doesn't work. NEXT::finalize_cookies() has
to be called at the end.
Here is a fixed version, that also doesn't alter the cookie domain if
it's already set:
sub finalize_cookies {
my $c = shift;
my $sc = $c-response-cookies-{$c-config-{session}-{cookie_name}};
if (defined($sc) and ref($sc) eq 'HASH') {
$sc-{domain} ||= (/(\.[^\.]+\.[^\.]+)$/)[0] || $_ for
$c-request-uri-host;
}
$c-NEXT::finalize_cookies(@_);
}
--
Bernhard Graf
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Setting cookie_domain
On Sunday 15 April 2007 21:32, Fernan Aguero wrote:
| Thank you, but this doesn't help. Because I have only one
| application that can be accessed under different domains (same
| 2nd-level domain with TLDs .de, .at and .ch im my case).
Oh, I see. -- BTW I'm in geneva now :)
Not so far from me - I'm in the lovely Ticino.
Yes I have some problems with sessions not working when I
switch to using the builtin server (instead of apache under
a registered domain) under localhost (for testing changes).
| A sane default for cookie_domain would be something as
| $cd = (/(\.[^\.]+\.[^\.]+)$/)[0] || $_ for $c-req-uri-host
| giving you
| .example.com for www.example.com and www.sub.example.com,
| example.com for example.com and of course
| mylocaltestdomain for mylocaltestdomain.
|
| But this is untested yet.
I'd be interested to know how you do that, if your tests are
successful.
I added a finalize_cookies() to my main application (MyApp.pm).
Catalyst::Manual::Internals says, that the request handlers might be
extended in plugins, so maybe doing so in the main application is bad,
but the following works:
sub finalize_cookies {
my $c = shift;
$c-NEXT::finalize_cookies(@_);
my $sc = $c-response-cookies-{$c-config-{session}-{cookie_name}};
if (defined($sc) and ref($sc) eq 'HASH') {
$sc-{domain} = (/(\.[^\.]+\.[^\.]+)$/)[0] || $_ for
$c-request-uri-host;
}
$c-NEXT::finalize_cookies(@_);
}
But of course I'd prefer if Catalyst::Plugin::Session::State::Cookie did
it right.
--
Bernhard Graf
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Setting cookie_domain
On Monday 16 April 2007 19:36, [EMAIL PROTECTED] wrote: IMHO it does do it right out of the box. The situation you are describing is an edge case and I would be uncomfortable with it tossing any apex domain willy nilly as the lock domain in default behavior. Cookies should be locked down to the host unless you have a reason to do it otherwise. In many cases the apex behavior listed above can and will cause session id bleed to unsecured sites. I wonder what you mean with edge case. IE, that doesn't accept cookies as generated by Catalyst::Plugin::Session::State::Cookie in default setup? Or having multiple domains for a site for which C:P:S:S:C doesn't have any usable option at all? IE-conformity and multiple domains is no edge case - these are two requirements that apply for most real world sites I would say. I have my workaround now, but this solution kept me from doing productive things and makes my code ugly and cryptic - things that Catalyst actually strives to eliminate. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Setting cookie_domain
On Sunday 15 April 2007 19:32, Fernan Aguero wrote: +[ Bernhard Graf [EMAIL PROTECTED] (15.Apr.2007 08:23): | Hi, | | I'm wondering how to set the cookie_domain of | Catalyst::Plugin::Session::State::Cookie when you run a site under | different domains. | | The manual only gives advice how to do this in the (static) | configuration - and from looking at the source I get the impression | that I either had to sub class and override more or less | undocumented methods or otherwise had to patch. | | Or is there a (better) third way? +] config your app using YAML. In your lib/app.pm file add 'ConfigLoader' to the list of plugins. The good thing about this setup is tat you can have a main config file and _local overrides for similar but not identical installations. Thank you, but this doesn't help. Because I have only one application that can be accessed under different domains (same 2nd-level domain with TLDs .de, .at and .ch im my case). The documentation for Catalyst::Plugin::Session::State::Cookie claims that the default value for cookie_domain is the current host, which is not true and probably would be counterproductive. A sane default for cookie_domain would be something as $cd = (/(\.[^\.]+\.[^\.]+)$/)[0] || $_ for $c-req-uri-host giving you .example.com for www.example.com and www.sub.example.com, example.com for example.com and of course mylocaltestdomain for mylocaltestdomain. But this is untested yet. -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Browser window/tab independent sessions
Perrin Harkins wrote: On Fri, 2007-01-05 at 20:44 +, Ian Docherty wrote: Does anyone try to keep different state information in different browser windows/tabs? Back in the old days, when we used to make websites with our stone knives and bear skins, we used to keep state information in hidden form fields and query strings. These techniques have none of the global state problems that cookies do. Putting things that are specific to a window/tab in a cookie-based session is a pet peeve of mine actually, since it can break things so spectacularly. If you check, you'll see that all of the major web sites like Yahoo and Amazon are careful to avoid this kind of issue (multiple tabs don't interfere with each other) and they generally seem to use the old-school techniques. Check out Apache::Session::Counted. HTH -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Forwarding to public URLs vs. private paths
Matt S Trout wrote:
Public URLs are not private paths. This doesn't work, has never
worked, and will never work, by design.
Trying to forward to a MyApp::Controller::Foo sub bar :Path('/spoon')
as /spoon won't work either, you'd need /foo/bar.
This is consistent across all dispatch types and is neither anything
to do with Chained for a bug :)
Ah, thank you for clearing this up.
Maybe this should be noted in the docs also to avoid confusion.
--
Bernhard Graf
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Advice for Catalyst::Plugin::Authent ication::Store::DBIC needed
[EMAIL PROTECTED] wrote:
What you need to do is subclass C::P::A::Credential, and override the
login() method.
The login method is where the username and password are checked, so
you probably want to do something like the following (probably
borrowing the password check form C::P::Authentication::CDBI):
It works. But is not a trivial thing, because it requires knowledge of
the - quite complex - Catalyst authentication code.
So may I place a feature request to the author(s):
Offer a possibility to add custom check code to the login() method.
Example:
$c-login($username, $password, {post_check = \check_status})
=head2 check_status
Callback function for login() to do further custom checks.
Receives context object and user object as arguments.
Checks user status field to equal active.
On success this function must return without any value.
On failure returns a string describing why login fails.
=cut
sub check_status {
my ($c, $user) = @_;
return if $user-status eq 'active';
return 'user status is not active';
}
--
Bernhard Graf
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Advice for Catalyst::Plugin::Authentication::Store::DBIC needed
In a Cat application I use C:P::Authentication::Store::DBIC and it works well. But now I need to modify authentication a little bit: A status field of the user object should also be checked, e.g. grant access only if status is set to active. Documentation of the module mentions a configuration field named catalyst_user_class: cite If using a plain model class which has username and password fields is not working for you, because you have more complex objects, or you need to do something else odd to fetch those values or your role fields, you can subclass Catalyst::Plugin::Authentication::Store::DBIC::User, and supply your class name here. /cite Is that the way I have to go? If so an example would be helpful, because documentation for C:P::Authentication::Store::DBIC::User is a little sparse. ;-) -- Bernhard Graf ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
