Re: [Catalyst] CatalystSites.org
/tag/name/name /tag/id/id NOT name ! - transcription, because tag names might be in different languages. 2008/4/12, Christopher H. Laco [EMAIL PROTECTED]: 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. Well, I'm going to channel for the black part of my heart that mst is responsible for :-) This is much like the quandry: /users/146 for admin purposes vs. /users/claco for humans on a browse choosing one or the other always seems to lead to problems.. so taking a tip from RHOX, do both... /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. -=Chris ___ 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/
Re: [Catalyst] Sending email safely with Catalyst
On Sat, Apr 12, 2008 at 1:06 AM, Dave Rolsky [EMAIL PROTECTED] wrote: 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. My first approach was to do the sending in a cron job - but then came the requirement that the emails should be sent as soon as possible. Now I have a forking model, but I don't know if I implemented it correctly (the mod_perl guide recommends against forking http://modperlbook.org/html/10-2-Forking-and-Executing-Subprocessesfrom-mod_perl.html). I am also contemplating a compromise of sending the first few emails immediately and the rest from a cron job. -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/ -- 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] Why does $c-stats require -Debug flag?
Jon Schutz wrote: On Fri, 2008-04-11 at 19:53 +0100, Richard Jones wrote: 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(). I think you probably want $c-stats-report, but can't think why you're calling this directly as it is invoked in finalize() if -Debug or -Stats is set. See perldoc Catalyst::Stats. Because I never got round to delving into Catalyst::Stats or Tree::Simple inner workings. I copy/pasted the example from http://www.onemogin.com/blog/559-adding-action-timings-to-your-output.html into my Root::end() method and it just worked. At least it did until I removed the -Debug flag. And then tried to recover functionality by updating Catalyst::Stats to the latest version, which also updated Catalyst itself (I was using an earlier 5.70x). So I've no idea in which module(s) the change occurred to stop the process working. Maybe someone more familiar with these modules could offer a clue? -- 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] Why does $c-stats require -Debug flag?
On Sat, 2008-04-12 at 10:45 +0100, Richard Jones wrote:
I think you probably want $c-stats-report, but can't think why you're
calling this directly as it is invoked in finalize() if -Debug or -Stats
is set. See perldoc Catalyst::Stats.
Because I never got round to delving into Catalyst::Stats or
Tree::Simple inner workings. I copy/pasted the example from
http://www.onemogin.com/blog/559-adding-action-timings-to-your-output.html
into my Root::end() method and it just worked.
At least it did until I removed the -Debug flag. And then tried to
recover functionality by updating Catalyst::Stats to the latest version,
which also updated Catalyst itself (I was using an earlier 5.70x). So
I've no idea in which module(s) the change occurred to stop the process
working. Maybe someone more familiar with these modules could offer a clue?
Following the example in the blog post, the solution is to set -Stats
and change your Root::end() method to something like:
@report = $stats-report;
$c-stash-{'action_stats'} = [EMAIL PROTECTED];
and then adjust your template as now you're getting an array of arrays
rather than an array of hashrefs.
Prior to 5.7012, $c-stats was an internal object (in so far as it was
not documented as part of the API) so anyone manipulating it directly
does so at their own risk. Catalyst::Stats was introduced to define an
interface for the stats object so that one could safely override the
default implementation if they wished; the default implementation also
introduced profiling methods that were not there before.
--
Jon SchutzMy tech notes http://notes.jschutz.net
Chief Technology Officerhttp://www.youramigo.com
YourAmigo
___
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 1:21 PM, Nigel Metheringham
[EMAIL PROTECTED] wrote:
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?
Hi Nigel,
The only non-validation I'm finding is that this module is producing dates
that don't appear to include the timezone info which is triggering a 'date
not RFC3339 compliant' error.
DateTime::Format::W3CDTF 90
/usr/local/share/perl/5.8.8/DateTime/Format/W3CDTF.pm
86: # $dt-hour, $dt-minute, $dt-second ) :
87: # sprintf( '%04d-%02d-%02d', $dt-year, $dt-month, $dt-day )
88: #);
89:
* 90: my $base = sprintf( '%04d-%02d-%02dT%02d:%02d:%02d',
* 91: $dt-year, $dt-month, $dt-day,
92: $dt-hour, $dt-minute, $dt-second );
93:
94:
Incidentally this has shown up a bug in my code where if the author isn't
set the validation will complain about that too.
if (my @authors = $entry-authors) {
foreach my $author (@authors) {
$feed_entry-author($author);
}
} else {
$feed_entry-author('Unknown');
}
Paul (apols to anyone that cares about the HTML)
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/
___
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] CC::FormBuilder woes - I don't get it
My problem with FormBuilder and Template Toolkit : [% form.render %] works [% FOREACH f IN form.fields %] [% f.label %] [% f.field %] [% END %] works [% form.field.fieldname.field %] does not work The same problem was signaled a year ago under de subject CC::Formbuilder woes. A solution was posted : Actually, it _was_ a stash issue, but all down to my misuse of it! Once I used the correct term for it (default = formbuilder), or over-rode it with the Controller::FormBuilder config entry stash_name = something_else, it worked fine. Thanks for the pointer. My problem : I just don't get it. the default for stash_name is formbuilder. Does this mean that [% formbuilder.field.fieldname.field %] ought to work ? It doesn't. Or else, what should I override it with ? with 'form' ? No luck either. Maybe someone more knowledgeable than me might be able to help me. -- Piet Ruyssinck ___ 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/
