[Catalyst] about req.param
code as follows:
sub test : Local {
my ($self, $c) = @_;
my $test = {
a = $c-req-param('a'),
b = $c-req-param('b'),
c = $c-req-param('c'),
};
$c-res-body(Dumper(\$test));
}
when visit as test?b=1
it shows
$VAR1 = \{
'1' = 'c',
'a' = 'b'
};
hmm, a trap I think. need use $c-req-param('a') || ''. something not
so good.
--
Fayland Lam // http://www.fayland.org/
Foorum based on Catalyst // http://www.foorumbbs.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] about req.param
Yes, because it's evaluated in a list context.
I prefer doing $c-req-params-{a} for that reason.
On 4/11/08, Fayland Lam [EMAIL PROTECTED] wrote:
code as follows:
sub test : Local {
my ($self, $c) = @_;
my $test = {
a = $c-req-param('a'),
b = $c-req-param('b'),
c = $c-req-param('c'),
};
$c-res-body(Dumper(\$test));
}
when visit as test?b=1
it shows
$VAR1 = \{
'1' = 'c',
'a' = 'b'
};
hmm, a trap I think. need use $c-req-param('a') || ''. something not so
good.
--
Fayland Lam // http://www.fayland.org/ Foorum based on Catalyst //
http://www.foorumbbs.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo:
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
--
Tatsuhiko Miyagawa
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] about req.param
On 11/04/2008, Fayland Lam [EMAIL PROTECTED] wrote:
code as follows:
sub test : Local {
my ($self, $c) = @_;
my $test = {
a = $c-req-param('a'),
b = $c-req-param('b'),
c = $c-req-param('c'),
};
$c-res-body(Dumper(\$test));
}
when visit as test?b=1
it shows
$VAR1 = \{
'1' = 'c',
'a' = 'b'
};
hmm, a trap I think. need use $c-req-param('a') || ''. something not so
good.
I recall in an earlier thread (or maybe on irc) mst said param()
should be deprecated for methods with guaranteed return types - that
was why I added param_value(), param_array() and param_list() to
FormFu.
If this were added to Catalyst, you could do this with no problems...
my $test = {
a = $c-req-param_value('a'),
b = $c-req-param_value('b'),
c = $c-req-param_value('c'),
};
Carl
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Catalyst::Controller::SOAP + Pod::WSDL?
I'm just getting started on implementing SOAP services in my Catalyst app so I figured I would try and make sure I'm using the best tools before I start coding. Catalyst::Controller::SOAP looks perfect as I'm not doing anything too complicated yet, really just exposing data via SOAP. However, I was also looking to automate the process of generating (and more importantly, maintaining) the WSDL file describing those services. It looks like Pod::WSDL does a good job of this, so I was wondering whether anyone was already working on getting Pod::WSDL to generate the WSDL file directly from the docs in the Controller at startup? Cheers, Ian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Sending email safely with Catalyst
On Fri, Apr 11, 2008 at 11:42 AM, Paul Makepeace [EMAIL PROTECTED] wrote: I see there's an Email plugin and wondered if this is enough to send email from a form safely securely or whether something more involved like a port of NMS CGI exists? http://search.cpan.org/~mramberg/Catalyst-Plugin-Email-0.08/Email.pm http://nms-cgi.sourceforge.net/ It's terribly easy to get this wrong so wanted some feedback from people who'd previously implemented something like this live before inadvertently turning my site into a spam conduit :-) I've got a related question - does anyone send bulk emails with that plugin? Is the delay reasonable when sending let's say a hundred emails or do I need a background mechanism for that? I have now a forking solution - but it is a bit complex (and for mod_perl they recommend to do it in a 'cleanup' handler instead of a forked process). -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
http://www.catalystsites.org/ Thanks, this looks useful, and can probably replace the sites running catalyst pages on the wiki. That would be a great idea. I've been editing http://catwiki.toeat.com/meta/tracpagestoport/liveapplications lately and I was surprised to see only Kieren's mention of it here (and no mention of http://www.catalystsites.org there). 1) Stephen, feel free to grab the links from catwiki and move them to catalystsites.org 2) Is the wiki still the intended repository for documentation? I found that scarcely any new content got added over the last few weeks. Dan ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: STDERR noise on Perl 5.10
Catalyst (C3 NEXT) noise STDERR on perl 5.10. What should i do to shut them up? Useless localization of subroutine entry at /usr/local/lib/perl5/site_perl/5.10.0/Catalyst/Action.pm line 41. Subroutine initialize redefined at /usr/local/lib/perl5/site_perl/5.10.0/Class/C3.pm line 70. Subroutine uninitialize redefined at /usr/local/lib/perl5/site_perl/5.10.0/Class/C3.pm line 88. Subroutine reinitialize redefined at /usr/local/lib/perl5/site_perl/5.10.0/Class/C3.pm line 101. Name MailRu::Catalyst::Plugin::Authentication::setup used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name MailRu::Catalyst::Plugin::Authentication::post_setup used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name MailRu::Catalyst::Plugin::ConfigLoader::post_setup used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name Catalyst::post_setup used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name Catalyst::AttrContainer::setup_actions used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name Catalyst::AttrContainer::setup_plugins used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name Catalyst::AttrContainer::setup used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name Catalyst::AttrContainer::post_setup used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name Catalyst::Controller::setup_actions used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name Catalyst::Controller::post_setup used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name Catalyst::Controller::setup_plugins used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name Catalyst::Controller::setup used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Name Class::Accessor::Grouped::setup_plugins used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Sending email safely with Catalyst
I see there's an Email plugin and wondered if this is enough to send email from a form safely securely or whether something more involved like a port of NMS CGI exists? http://search.cpan.org/~mramberg/Catalyst-Plugin-Email-0.08/Email.pm http://nms-cgi.sourceforge.net/ It's terribly easy to get this wrong so wanted some feedback from people who'd previously implemented something like this live before inadvertently turning my site into a spam conduit :-) Thanks, Paul ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
On 11 Apr 2008, at 20:35, Dan Dascalescu wrote:
http://www.catalystsites.org/
Thanks, this looks useful, and can probably replace the sites running
catalyst pages on the wiki.
That would be a great idea. I've been editing
http://catwiki.toeat.com/meta/tracpagestoport/liveapplications lately
and I was surprised to see only Kieren's mention of it here (and no
mention of http://www.catalystsites.org there).
1) Stephen, feel free to grab the links from catwiki and move them to
catalystsites.org
2) Is the wiki still the intended repository for documentation? I
found that scarcely any new content got added over the last few weeks.
Oops, sorry :-º
I think the priority for catalystsites.org should be for rss support
- one rss feed on the root should be sufficient initially. I didn't
see an announce to the list, so I assume that there's still no public
svn repos, although I've noticed that *someone* has been fixing the
code.
Once rss support is done I would strongly recommend that
catalystsites.org becomes the official site for sites running catalyst
Here's a moderately naive rss implementation, but apparently it's one
of the few more reliable parts of wiab:
sub rss : Local {
my ($self, $c)= @_;
my $path = $c-req-args;
my $base = Path::Class::Dir-new($c-config-{content});
my $rss_data = $c-model('Content')-get_rss_data($base, $path);
# this is view code which is in the controller really. It could
# be in the model, but then we would have to mess around with
# ACCEPT_CONTEXT or uglier.
my $feed = XML::Feed-new('RSS');
if (@$path) {
my $subpage = join '/', @$path;
$feed-title( $c-config-{name} . ' for ' . $subpage .'
page RSS Feed' );
}
else {
$feed-title( $c-config-{name} . ' RSS Feed' );
}
$feed-link( $c-uri_for(/content/) );
$feed-description( $c-config-{site_descr} );
foreach my $entry ( @$rss_data ) {
my $feed_entry = XML::Feed::Entry-new('RSS');
$feed_entry-title( $entry-{title} );
$feed_entry-link( $c-uri_for(/content/ . $entry-{link}));
$feed_entry-summary($entry-{summary});
$feed_entry-issued( DateTime-from_epoch(epoch = $entry-
{issued} ) );
$feed-add_entry($feed_entry);
}
$c-res-content_type('application/rss+xml');
$c-res-body( $feed-as_xml );
}
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
On Fri, Apr 11, 2008 at 12:08 PM, Kieren Diment [EMAIL PROTECTED] wrote:
On 11 Apr 2008, at 20:35, Dan Dascalescu wrote:
http://www.catalystsites.org/
Thanks, this looks useful, and can probably replace the sites running
catalyst pages on the wiki.
That would be a great idea. I've been editing
http://catwiki.toeat.com/meta/tracpagestoport/liveapplications lately
and I was surprised to see only Kieren's mention of it here (and no
mention of http://www.catalystsites.org there).
1) Stephen, feel free to grab the links from catwiki and move them to
catalystsites.org
2) Is the wiki still the intended repository for documentation? I
found that scarcely any new content got added over the last few weeks.
Oops, sorry :-º
I think the priority for catalystsites.org should be for rss support - one
rss feed on the root should be sufficient initially. I didn't see an
announce to the list, so I assume that there's still no public svn repos,
although I've noticed that *someone* has been fixing the code.
Once rss support is done I would strongly recommend that catalystsites.org
becomes the official site for sites running catalyst
Here's a moderately naive rss implementation, but apparently it's one of
the few more reliable parts of wiab:
sub rss : Local {
my ($self, $c)= @_;
my $path = $c-req-args;
my $base = Path::Class::Dir-new($c-config-{content});
my $rss_data = $c-model('Content')-get_rss_data($base, $path);
# this is view code which is in the controller really. It could
# be in the model, but then we would have to mess around with
# ACCEPT_CONTEXT or uglier.
my $feed = XML::Feed-new('RSS');
if (@$path) {
my $subpage = join '/', @$path;
$feed-title( $c-config-{name} . ' for ' . $subpage .' page RSS
Feed' );
}
else {
$feed-title( $c-config-{name} . ' RSS Feed' );
}
$feed-link( $c-uri_for(/content/) );
$feed-description( $c-config-{site_descr} );
foreach my $entry ( @$rss_data ) {
my $feed_entry = XML::Feed::Entry-new('RSS');
$feed_entry-title( $entry-{title} );
$feed_entry-link( $c-uri_for(/content/ . $entry-{link}));
$feed_entry-summary($entry-{summary});
$feed_entry-issued( DateTime-from_epoch(epoch =
$entry-{issued} ) );
$feed-add_entry($feed_entry);
}
$c-res-content_type('application/rss+xml');
$c-res-body( $feed-as_xml );
}
I'm curious, is there a compelling reason you're using one of the
nine(!) RSS standards versus Atom?
sub atom : Path('atom.xml') {
my ($self, $c) = @_;
my @tags = $c-req-param('tags');
my @news : Stashed = $c-model('DBIC::Story')-tagged_news([EMAIL PROTECTED]);
my $feed = XML::Feed-new('Atom');
$feed-title('Our Org Atom Feed');
$feed-link($c-req-base); # link to the site.
$feed-description(Our Org presents @tags news);
foreach my $entry (@news) {
my $feed_entry = XML::Feed::Entry-new('Atom');
$feed_entry-title($entry-headline);
$feed_entry-link($c-uri_for($entry-hyperlink));
$feed_entry-content($entry-body_text);
$feed_entry-category($_-tag) for $entry-tags;
#$feed_entry-author($entry-...author...);
$feed_entry-issued($entry-date_time);
$feed-add_entry($feed_entry);
}
$c-res-content_type('application/atom+xml');
$c-res-body($feed-as_xml);
}
P
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: STDERR noise on Perl 5.10
I mean, could you please shut them up? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
On 11 Apr 2008, at 12:41, Paul Makepeace wrote:
I'm curious, is there a compelling reason you're using one of the
nine(!) RSS standards versus Atom?
...
my $feed = XML::Feed-new('Atom');
Going somewhat off-topic, when I was trying this I found XML::Feed was
producing Atom feeds that caused apoplexy to the feed validators I
tried, so I changed to XML::Atom::SimpleFeed (which has other issues
but was at least producing output that the checker was happy with).
Are you generating valid Atom with XML::Feed or did I hold the wrong
end of the chainsaw?
Nigel.
--
[ Nigel Metheringham [EMAIL PROTECTED] ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Sending email safely with Catalyst
On 04/11/2008 04:42 AM, Paul Makepeace wrote: It's terribly easy to get this wrong so wanted some feedback from people who'd previously implemented something like this live before inadvertently turning my site into a spam conduit :-) I use the View::Email instead of the Plugin. I find that the View better fits my architecture philosophy and allows for easy email template management similar to my other HTML view templates. The same kind of security safeguards apply to sending email as for protecting against SQL injection and other taint issues. I don't try sending large numbers of email (see other replies on this thread for suggestions on that). Usually it's a confirmation email for some action the requester has made. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RIA on Catalyst
On Thu, Apr 10, 2008 at 06:25:56PM +0100, Peter Edwards wrote: I've been thinking about how to implement a Rich Internet Application type interface using WSDL and REST data sources including some from a Catalyst base in an SOA style environment. I like Extjs but I've also been looking at Tibo General Interface http://www.tibco.com/devnet/gi/default.jsp which has a good open source tool for generating RIAs http://gi.tibco.com/ Last time we did this we used dojo; while the widgets are maybe not quite as good as ext's the class system and XHR wrappers are far, far more powerful so it made modeling the system as half object + protocol (the protocol being a JSON transport) much easier. I am not, however, a JS expert; I spent most of my time beating Cat + DBIC with a stick, as usual :) -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Sending email safely with Catalyst
On Fri, Apr 11, 2008 at 4:49 PM, J. Shirley [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 3:51 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 11:42 AM, Paul Makepeace [EMAIL PROTECTED] wrote: I see there's an Email plugin and wondered if this is enough to send email from a form safely securely or whether something more involved like a port of NMS CGI exists? http://search.cpan.org/~mramberg/Catalyst-Plugin-Email-0.08/Email.pm http://nms-cgi.sourceforge.net/ It's terribly easy to get this wrong so wanted some feedback from people who'd previously implemented something like this live before inadvertently turning my site into a spam conduit :-) I've got a related question - does anyone send bulk emails with that plugin? Is the delay reasonable when sending let's say a hundred emails or do I need a background mechanism for that? I have now a forking solution - but it is a bit complex (and for mod_perl they recommend to do it in a 'cleanup' handler instead of a forked process). I've been dying to play with http://search.cpan.org/~btrott/Email-Send-TheSchwartz-0.01/lib/Email/Send/TheSchwartz.pm I like TheSchwartz because it's fairly simple, easy to get going and... has this module ready. I'm hoping to have a reason to play with it in the next couple of months. This is interesting - but the documentation unfortunately does not answer following questions: - The worker looks like a polling daemon - how often does it poll the database? Would it be feasible solution on an SQLite database (which does not work very well with many concurrent connections). - How should I run the worker process so that it does not die unexpectedly? Should I put it into inittab or perhaps should I run it in a pair of processes that would fork another one if one of them dies? -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Memory leak under FastCGI?
-Original Message- From: Matt S Trout [mailto:[EMAIL PROTECTED] Sent: Friday, April 11, 2008 10:35 AM To: The elegant MVC web framework Subject: Re: [Catalyst] Memory leak under FastCGI? On Thu, Apr 10, 2008 at 03:11:56PM -0400, Matt Pitts wrote: -Original Message- From: Matt S Trout [mailto:[EMAIL PROTECTED] Sent: Thursday, April 10, 2008 12:33 PM To: The elegant MVC web framework Subject: Re: [Catalyst] Memory leak under FastCGI? On Mon, Apr 07, 2008 at 10:52:54AM -0400, Matt Pitts wrote: As of now, I'm trying to hack up a better ProcManager based on FCGI::Engine::ProcManager that actually recycles its children using options like MaxRequestPerChild. Hopefully, I'll be able to get it done and cleaned up enough to release. Please don't; there's work being done on an app plugin that implements this generically, which is a much better approach. Contact John I see generic from two directions: Catalyst and FastCGI. Implementing this as a subclass of FCGI::Engine::ProcManager makes it available to anyone using FastCGI and is, therefore, more generic to FastCGI. However, implementing this as a Cat plugin makes it generic (or abstract) to all the C::Engine:: modules, so that all Cat apps can enjoy the benefits. I'm not sure that either is the better approach they just have different scopes. Napiorkowski for his current prototype and help get that finished. Once you use something like that, the child exits and ProcManager just spawns another one. I don't like this approach because the dying of children isn't being managed in a single place. If it's done like this and the children don't coordinate their deaths then you could run into a situation where many or all of the children die at the same time - this is bad for obvious reasons, especially in an external FastCGI app. My plan was do all child TERM signaling from within the manager app and use some simple heuristics to prevent a mass-child death situation. Obviously, if it's written as a plugin, then I can choose to use or not to use - that's be beauty of Catalyst - I guess I'm just trying to defend my position that I like the idea of having a MaxRequestsPerChild feature implemented in the manager of my FastCGI processes not within the children themselves. The accept() happens in the child in normal situations though, so the parent can't know how many requests a given child has handled without additional complication. Yeap. My version of the additional complication is a lite IPC messaging system using DBM::Deep. I override post_dispatch in the children to send a message to the queue that says I just finished handling a request and then the manager iterates the message queue during each daemon loop and keeps track of each child's request count. This obviously introduces some overhead to the post_dispatch call, but I'm thinking that since MyApp-handle_request has already been called that all data has been sent to the client (buffering?), the only thing that might not have happened yet is the closing of the FastCGI connection with the socket. Am I wrong? Can anyone elaborate on the effects of doing this in post_dispatch? Basically, you -can't- manage it in a single place. A don't die for a bit, somebody else just did mechanism would be good as a co-ordination between manager and children and IMO should be implemented separately. My plan is to build it as a subclass of FCGI::Engine::ProcManager so folks can use it at their own discretion. v/r -matt ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: STDERR noise on Perl 5.10
On Fri, Apr 11, 2008 at 02:13:21PM +0400, Oleg Pronin wrote: Catalyst (C3 NEXT) noise STDERR on perl 5.10. What should i do to shut them up? Useless localization of subroutine entry at /usr/local/lib/perl5/site_perl/5.10.0/Catalyst/Action.pm line 41. Fixed in trunk. Subroutine initialize redefined at /usr/local/lib/perl5/site_perl/5.10.0/Class/C3.pm line 70. Send patches to Class::C3 Name MailRu::Catalyst::Plugin::Authentication::setup used only once: possible typo at /usr/local/lib/perl5/5.10.0/NEXT.pm line 58. Send patches to NEXT -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Sending email safely with Catalyst
Hi, On Apr 11, 2008, at 4:15 PM, Zbigniew Lukasiak wrote: On Fri, Apr 11, 2008 at 4:49 PM, J. Shirley [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 3:51 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 11:42 AM, Paul Makepeace [EMAIL PROTECTED] wrote: I see there's an Email plugin and wondered if this is enough to send email from a form safely securely or whether something more involved like a port of NMS CGI exists? http://search.cpan.org/~mramberg/Catalyst-Plugin-Email-0.08/ Email.pm http://nms-cgi.sourceforge.net/ It's terribly easy to get this wrong so wanted some feedback from people who'd previously implemented something like this live before inadvertently turning my site into a spam conduit :-) I've got a related question - does anyone send bulk emails with that plugin? Is the delay reasonable when sending let's say a hundred emails or do I need a background mechanism for that? I have now a forking solution - but it is a bit complex (and for mod_perl they recommend to do it in a 'cleanup' handler instead of a forked process). I've been dying to play with http://search.cpan.org/~btrott/Email-Send-TheSchwartz-0.01/lib/ Email/Send/TheSchwartz.pm I use this exactly to send email. My worker gets the MX of the destination domain and sends the email directly to the remote server. This allows me to react more quickly to invalid email addresses (for those servers that check RCPT TO's). This is interesting - but the documentation unfortunately does not answer following questions: - The worker looks like a polling daemon - how often does it poll the database? Would it be feasible solution on an SQLite database (which does not work very well with many concurrent connections). 5 seconds by default. You can override it in the call to work(). It's documented btw. - How should I run the worker process so that it does not die unexpectedly? Should I put it into inittab or perhaps should I run it in a pair of processes that would fork another one if one of them dies? Some people use daemontools, other initab, or ruinit There are several systems to do that. Alternatively you could just run from cron and use the work_once() call, or the work_until_done(), more difficult to predict the load though. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP! ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] RFC: Catalyst::View::Feed (Atom/RSS)
As I sat around last night refactoring the
View::Feed/View::Feed::(Atom|RSS) code in Mango because critic told me
process() was too complex (and it was), a little voice popped into my
head and told me I should just release it as a new dist. Most of this is
code from helpful others who have embarked down the same path.
It's been mentioned a few times, and there are some variations on the
code. In a nutshell, it supports creating a feed from:
## just hashed data
{
xml_feed_attribute = 'value',
xml_feed_attribute = 'value',
xml_feed_attribute = 'value',
entries = [
xml_feed_item_attribute = 'value',
xml_feed_item_attribute = 'value',
xml_feed_item_attribute = 'value',
],
}
## objects with as_feed returning XML::Feed
$someobj-as_feed;
## objects with as_feed returning a hash
$someobj-as_feed( return {
xml_feed_attribute = 'value',
xml_feed_attribute = 'value',
xml_feed_attribute = 'value',
entries = [
xml_feed_item_attribute = 'value',
xml_feed_item_attribute = 'value',
xml_feed_item_attribute = 'value',
],
})
The entries key can also be an array of XML::Feed::Item objects, an
array of objects that return hashes or XML::Feed::Item from as_feed_item
methods.
View::Feed::Atom and View::Feed::RSS simply use View::Feed and set the
appropriate content-type.
Nothing fancy, but enough code to share an not have to rewrite again
somewhere else.
If anyone thinks it's worth the effort, I'll kick out a dist this weekend.
-=Chris
signature.asc
Description: OpenPGP digital signature
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Memory leak under FastCGI?
-Original Message- From: Matt S Trout [mailto:[EMAIL PROTECTED] Sent: Friday, April 11, 2008 1:23 PM To: The elegant MVC web framework Subject: Re: [Catalyst] Memory leak under FastCGI? On Fri, Apr 11, 2008 at 11:20:53AM -0400, Matt Pitts wrote: The accept() happens in the child in normal situations though, so the parent can't know how many requests a given child has handled without additional complication. Yeap. My version of the additional complication is a lite IPC messaging system using DBM::Deep. I override post_dispatch in the children to send a message to the queue that says I just finished handling a request and then the manager iterates the message queue during each daemon loop and keeps track of each child's request count. Yuck. Seems much simpler to me to do something like: Child1 hits request count, sends SIGUSR1 to proc manager, starts exiting Manager sends SIGUSR1 to all other children (child may take a while to clean up, exit happens somewhen) Other children go into must not die mode Manager spawns new child once it gets SIGCHLD New child sends SIGUSR2 to proc manager once it's starting its accept() loop Proc manager sends SIGUSR2 to all children to indicate they're allowed to die now if they want to Seems a lot more unixy to me, and likely much less overhead as well. Neat. I like this approach, especially if the only process limitation is MaxRequestsPerChild. My original motivation behind a message queue was to make it easier to add additional management facilities, but as of now MaxRequestsPerChild is the main one I'm interested in. Although I had thought about using SIGUSR1 or 2 to implement a simple ping to make sure that a child is still there. I'll definitely keep your approach in mind if I decide to only implement MaxRequestsPerChild. Going the SIGUSR approach I think I'd still want the manager to be the one sending SIGTERM to the children and have the children trap SIGTERM and set a flag to exit(0) at the end of the current request during post_dispatch. This way if the manager wants to kill multiple children in a short time period it can. Thanks for the input! v/r -matt pitts ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: about req.param
* On Fri, Apr 11 2008, Fayland Lam wrote:
Fayland Lam wrote:
code as follows:
sub test : Local {
my ($self, $c) = @_;
my $test = {
a = $c-req-param('a'),
b = $c-req-param('b'),
c = $c-req-param('c'),
};
$c-res-body(Dumper(\$test));
}
well, this is OK
sub test : Local {
my ($self, $c) = @_;
my $test = {
a = $c-req-params-{'a'},
b = $c-req-params-{'b'},
c = $c-req-params-{'c'},
};
$c-res-body(Dumper(\$test));
}
Yes, param only exists so you can pass $c-req to a function expecting a
CGI object. (It's for compatibility, not for use in new applications.)
If you really want to use a function call instead of a hash lookup,
apply this role to the request class:
http://git.jrock.us/?p=MooseX-Param-Safe.git;a=blob;f=lib/MooseX/Param/Safe.pm;hb=HEAD
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Sending email safely with Catalyst
* On Fri, Apr 11 2008, Zbigniew Lukasiak wrote: I've got a related question - does anyone send bulk emails with that plugin? Is the delay reasonable when sending let's say a hundred emails or do I need a background mechanism for that? I have now a forking solution - but it is a bit complex (and for mod_perl they recommend to do it in a 'cleanup' handler instead of a forked process). In an ideal world, you should be able to dump the messages into your mail system's queue as quickly as you can dump them into a database table (adding to the mail queue is a disk write, adding to a database is a disk write, unless you've turned off data integrity). I could see how calculating the text of 1 mail messages during a request would be slow, but why would you want to do that? Usually you'll just want to say Your account was created, [% name %]! and queue that. The template rendering and the mail system's queue should be more than fast enough to handle that during a request. As for bulk emails, you probably have a process that calculates those outside of your Catalyst app anyway (running from cron), so calculate them, dump them into the mail queue, and let your mailer daemon figure out what to do. Much better than putting a queue in front of a queue, IMHO. This is UNIX after all. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
Kieren Diment wrote:
On 11 Apr 2008, at 20:35, Dan Dascalescu wrote:
http://www.catalystsites.org/
Thanks, this looks useful, and can probably replace the sites running
catalyst pages on the wiki.
That would be a great idea. I've been editing
http://catwiki.toeat.com/meta/tracpagestoport/liveapplications lately
and I was surprised to see only Kieren's mention of it here (and no
mention of http://www.catalystsites.org there).
1) Stephen, feel free to grab the links from catwiki and move them to
catalystsites.org
2) Is the wiki still the intended repository for documentation? I
found that scarcely any new content got added over the last few weeks.
Oops, sorry :-º
I think the priority for catalystsites.org should be for rss support -
one rss feed on the root should be sufficient initially. I didn't see
an announce to the list, so I assume that there's still no public svn
repos, although I've noticed that *someone* has been fixing the code.
Once rss support is done I would strongly recommend that
catalystsites.org becomes the official site for sites running catalyst
Here's a moderately naive rss implementation, but apparently it's one
of the few more reliable parts of wiab:
sub rss : Local {
my ($self, $c)= @_;
my $path = $c-req-args;
my $base = Path::Class::Dir-new($c-config-{content});
my $rss_data = $c-model('Content')-get_rss_data($base, $path);
# this is view code which is in the controller really. It could
# be in the model, but then we would have to mess around with
# ACCEPT_CONTEXT or uglier.
my $feed = XML::Feed-new('RSS');
if (@$path) {
my $subpage = join '/', @$path;
$feed-title( $c-config-{name} . ' for ' . $subpage .' page
RSS Feed' );
}
else {
$feed-title( $c-config-{name} . ' RSS Feed' );
}
$feed-link( $c-uri_for(/content/) );
$feed-description( $c-config-{site_descr} );
foreach my $entry ( @$rss_data ) {
my $feed_entry = XML::Feed::Entry-new('RSS');
$feed_entry-title( $entry-{title} );
$feed_entry-link( $c-uri_for(/content/ . $entry-{link}));
$feed_entry-summary($entry-{summary});
$feed_entry-issued( DateTime-from_epoch(epoch =
$entry-{issued} ) );
$feed-add_entry($feed_entry);
}
$c-res-content_type('application/rss+xml');
$c-res-body( $feed-as_xml );
}
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
That would be me. I *promise* to setup public svn repo soon, and then
you can add in RSS to the code base if you want.
Chisel - What is so odd in passing the tag id to the controller for the
by_tag feature?
[stephen]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does $c-stats require -Debug flag?
Jon Schutz wrote: From the perldoc for 5.7012 - Stats collection is enabled when the '-Stats' options is set, debug is on or when the MYAPP_STATS environment variable is set. So, if you want stats but not debug, use -Stats instead of -Debug. Yeah I tried -Stats already - something must have changed in a recent version of Catalyst::Stats, as now I get: [error] Caught exception in MyApp::Controller::Root-end Can't locate object method accept via package Catalyst::Stats at .. etc So it's now finding the stats method but apparently not accept. accept is a method of Tree::Simple I think. I didn't specifically load anything from Tree::Simple previously, it just worked using $c-stats-accept(). -- Richard Jones ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
On Apr 11, 2008, at 11:55 AM, Stephen Sykes wrote: Chisel - What is so odd in passing the tag id to the controller for the by_tag feature? I think this is the issue: Other users also tagged this 27. The tag is the human readable part of the record. :) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
Ashley wrote: On Apr 11, 2008, at 11:55 AM, Stephen Sykes wrote: Chisel - What is so odd in passing the tag id to the controller for the by_tag feature? I think this is the issue: Other users also tagged this 27. The tag is the human readable part of the record. :) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ I'm still not getting this. :-\ Once a new tag is added to the database the tag id will never change, only the tag weight. Tag id is unique and is primary. I suppose the tag description could be used with an index on that column for performance. That would make sense, if that is your concern. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
On Apr 11, 2008, at 1:10 PM, Stephen Sykes wrote: Ashley wrote: On Apr 11, 2008, at 11:55 AM, Stephen Sykes wrote: Chisel - What is so odd in passing the tag id to the controller for the by_tag feature? I think this is the issue: Other users also tagged this 27. The tag is the human readable part of the record. :) I'm still not getting this. :-\ Once a new tag is added to the database the tag id will never change, only the tag weight. Tag id is unique and is primary. I suppose the tag description could be used with an index on that column for performance. That would make sense, if that is your concern. It's that http://mysite.com/tag/1232 is meaningless to the user. Not that it's programatically incorrect; which, as you know, it's not. http://mysite.com/tag/pangolins is better UI. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
On Apr 11, 2008, at 1:33 PM, Christopher H. Laco wrote: /tag/name/name /tag/id/id The greatness of future possibilities is expanded to much happiness. Chained/sub instance() make all the code behind either option JustWork. claco (I just like writing it) ++. This is mostly how I do it and for admin functions I redirect to the id version. /tag/name/name going to its id at /tag/id/id/edit as only the id is immutable for the record. Well, tags are a bad example for this but an article name can certainly change. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CatalystSites.org
Ashley wrote: On Apr 11, 2008, at 1:10 PM, Stephen Sykes wrote: Ashley wrote: On Apr 11, 2008, at 11:55 AM, Stephen Sykes wrote: Chisel - What is so odd in passing the tag id to the controller for the by_tag feature? I think this is the issue: Other users also tagged this 27. The tag is the human readable part of the record. :) I'm still not getting this. :-\ Once a new tag is added to the database the tag id will never change, only the tag weight. Tag id is unique and is primary. I suppose the tag description could be used with an index on that column for performance. That would make sense, if that is your concern. It's that http://mysite.com/tag/1232 is meaningless to the user. Not that it's programatically incorrect; which, as you know, it's not. http://mysite.com/tag/pangolins is better UI. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ Changed, committed and deployed; for the satisfaction of those affected. :-P ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Sending email safely with Catalyst
On Fri, 11 Apr 2008, Jonathan Rockway wrote: In an ideal world, you should be able to dump the messages into your mail system's queue as quickly as you can dump them into a database table (adding to the mail queue is a disk write, adding to a database is a disk write, unless you've turned off data integrity). I could see how calculating the text of 1 mail messages during a request would be slow, but why would you want to do that? Usually you'll just want to say Your account was created, [% name %]! and queue that. The template rendering and the mail system's queue should be more than fast enough to handle that during a request. As for bulk emails, you probably have a process that calculates those outside of your Catalyst app anyway (running from cron), so calculate them, dump them into the mail queue, and let your mailer daemon figure out what to do. Much better than putting a queue in front of a queue, IMHO. This is UNIX after all. The big problem I've run into when sending lots of emails from a web app (just hundreds, in this case), is that it can be slow enough the browser times out. Presumably you could have a similar problem with a work queue as well. Ultimately, I suspect a solution that forks _immediately_ and then does its thing (whatever that thing may be) is going to be necessary past a certain scale. Then the trick becomes monitoring that forked process. Another solution might be to come up with a way to queue up the job with a single write and do the full email generation via cron. Either way, you have to add complexity to your app if you want to provide feedback on the job status to the user. I'll be working on this soon for an app I'm creating, and I suspect I'll go the route of doing a single insert and processing via a cron job. The upside of this is that for a multi-user app, I won't end up forking a whole bunch of email sending processes and I can exercise some control over the rate that email is generated. -dave /*== VegGuide.Org Your guide to all that's veg ==*/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: Best way to implement an RSS|Atom feed with perl/Catalyst?
* Kieren Diment [EMAIL PROTECTED] [2008-04-11 14:40]: I must say I have no idea what the best solution would be, any ideas? I would say XML::Atom::SimpleFeed, but I may be biased. ;-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
