Re: [Catalyst] May be asynchronous communication between Catalyst applications
Hi - On Sun, Mar 3, 2013, at 08:44 PM, linuxsupport wrote: > I tried Catalyst::Plugin::RunAfterRequest, when I send request to the app, > it returns fine but it does not accept any other request after that until that > sub routine finishes. By default the test server runs a single process, so that process will complete the after-request work before accepting a new request to work on. You need to allow it to fork to run multiple processes: myapp_server.pl -f HTH, Larry ___ 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] Backlog for proposed changes in next Catalyst release
Bill, I'd be open to it, if it seems like we always just need to add this. I'm not enough an expert of unicode to understand the drawbacks, or why this was done as a plugin in the first place. Is there a drawback, for example to having it core? I can see at the beginning having stuff like this as stand alone dists, since it lets you be more agile in fixing issues with it, and all that but if this is stable then I can see just making it core. Anyone? John > > From: Bill Moseley >To: The elegant MVC web framework >Sent: Sunday, March 3, 2013 11:50 AM >Subject: Re: [Catalyst] Backlog for proposed changes in next Catalyst release > > > > > >On Fri, Mar 1, 2013 at 9:38 AM, John Napiorkowski wrote: > >Hey All, >> >> >>http://jjnapiorkowski.typepad.com/modern-perl/2013/03/catalyst-backup-for-next-release-on-play-perl.html >> >> >> >>This is over on play Perl (http://play-perl.org/player/jnap) for your >>comments and votes. Hope to see you there! > > >I think I've asked this before, but is there any talk of native encoding >support -- meaning make Catalyst::Plugin::Unicode::Encoding part of the >framework? Having it a plugin makes it appear as optional, but the correct >approach is to decoded all text requests and encode all text responses. > > >This is fresh in my mind because last week had problems with two separate >encoding issues. > > > -- >Bill Moseley >mose...@hank.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/ > > >___ 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] Backlog for proposed changes in next Catalyst release
On Mar 4, 2013, at 11:12 AM, John Napiorkowski wrote: > Bill, > > I'd be open to it, if it seems like we always just need to add this. I'm not > enough an expert of unicode to understand the drawbacks, or why this was done > as a plugin in the first place. Is there a drawback, for example to having > it core? > > I can see at the beginning having stuff like this as stand alone dists, since > it lets you be more agile in fixing issues with it, and all that but if this > is stable then I can see just making it core. Correctly understanding and handling character encodings can be tricky. It's quite common to encounter applications that behave erratically when fed non-ASCII input (with a last name that contains such characters, I would know). That say, I cannot see how including that functionality in the core would be a bad thing. Best regards -lem ___ 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] May be asynchronous communication between Catalyst applications
Yes, I know that and tried with -f option, but result was same. On Mon, Mar 4, 2013 at 9:35 PM, Larry Leszczynski wrote: > Hi - > > On Sun, Mar 3, 2013, at 08:44 PM, linuxsupport wrote: > > I tried Catalyst::Plugin::RunAfterRequest, when I send request to the > app, > > it returns fine but it does not accept any other request after that > until that > > sub routine finishes. > > By default the test server runs a single process, so that process will > complete the after-request work before accepting a new request to work > on. You need to allow it to fork to run multiple processes: > > myapp_server.pl -f > > > HTH, > Larry > > ___ > 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] Backlog for proposed changes in next Catalyst release
http://play-perl.org/quest/5134cdc18e0a96450f38 There was a discussion about this on #catalyst-dev and in general people seem to think its ok. Bill, are you up to giving the work a try? I'd be happy to mentor you. I don't think its killer work, but would really help John - Original Message - > From: ""Luis E. Muñoz"" > To: John Napiorkowski ; The elegant MVC web framework > > Cc: > Sent: Monday, March 4, 2013 11:38 AM > Subject: Re: [Catalyst] Backlog for proposed changes in next Catalyst release > > > On Mar 4, 2013, at 11:12 AM, John Napiorkowski wrote: > >> Bill, >> >> I'd be open to it, if it seems like we always just need to add this. > I'm not enough an expert of unicode to understand the drawbacks, or why this > was done as a plugin in the first place. Is there a drawback, for example to > having it core? >> >> I can see at the beginning having stuff like this as stand alone dists, > since it lets you be more agile in fixing issues with it, and all that but if > this is stable then I can see just making it core. > > Correctly understanding and handling character encodings can be tricky. It's > quite common to encounter applications that behave erratically when fed > non-ASCII input (with a last name that contains such characters, I would > know). > > That say, I cannot see how including that functionality in the core would be > a > bad thing. > > Best regards > > -lem > ___ 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] Tutorial (in VMware) keeps losing ability to authenticate
On 2 Mar 2013, at 14:54, Dan Lowe wrote: > Thanks for suggestions, everyone. This does seem to be what's happening > (despite the fact that the VM is running ntpd). Even quite a while after > un-sleeping the computer, the VM continues to have an incorrect date, so ntpd > doesn't seem to be doing a very good job here. ntpd will not adjust things if your time is too wacky, and even if it does, it tends to tend _slwly_ back towards a correct setting. This is exactly the behaviour you want in a server that's on all the time - but exactly not what you want in a VM / laptop that gets paused regularly.. Cheers t0m ___ 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] May be asynchronous communication between Catalyst applications
On 4 Mar 2013, at 17:14, linuxsupport wrote: > Yes, I know that and tried with -f option, but result was same. No other ideas. Some code you haven't shown us doesn't work as you expect - we can't really do anything other than guess at this point :) Cheers t0m ___ 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] ActionClass('RenderView') questions
In my root controller, I have this method:
sub end : ActionClass('RenderView') { ... }
I understand that this method is called after the controller for the
request has finished and just before the view is called to render any
output.
My question is: in this 'end' method, how can I determine what the response
status is going to be (i.e. 200, 302, etc.), and if the response is a
redirect how can I get at the redirection location?
Also, what does it mean if $c->stash->{template} is undef at this point?
Thanks,
ER
___
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] ActionClass('RenderView') questions
On 4 Mar 2013, at 22:59, E R wrote:
> In my root controller, I have this method:
>
> sub end : ActionClass('RenderView') { ... }
>
> I understand that this method is called after the controller for the request
> has finished and just before the view is called to render any output.
>
> My question is: in this 'end' method, how can I determine what the response
> status is going to be (i.e. 200, 302, etc.),
As you will have set that already, so you can just call $c->res->status to
retrieve it.
> and if the response is a redirect how can I get at the redirection location?
Again, you'll have set it already - i.e. it'll be retrievable from
$c->res->headers if you need it.
What's the use-case here? Generally for a 200 you need to render a template,
and for a 302 you don't want to (as there is no body), and the RenderView
action class handles these default cases automagically.
This (generally) means that you don't need to get these values back - why do
you think you need to / what are you trying to achieve?
>
> Also, what does it mean if $c->stash->{template} is undef at this point?
Maybe :)
You can explicitly set this, or you can let it default (in _some_ views) - it
depends on your app.
Cheers
t0m
___
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] Backlog for proposed changes in next Catalyst release
On Mon, Mar 4, 2013 at 9:24 AM, John Napiorkowski wrote: > http://play-perl.org/quest/5134cdc18e0a96450f38 > > There was a discussion about this on #catalyst-dev and in general people > seem to think its ok. > > Bill, are you up to giving the work a try? I'd be happy to mentor you. I > don't think its killer work, but would really help > I would like to give it a try, yes. I'm just not sure when. I guess there's no rush since there's a plugin. I was just thinking it would be wise to make it a standard part of the framework since it's something that every app probably should to, but easy to ignore or get wrong. I wonder what percent of Catalyst apps make use of that plugin. -- Bill Moseley mose...@hank.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/
