Re: [Catalyst] User timezones
* Ian Wells i...@cack.org.uk [090625 12:52]: Hi Everybody, first of all, thanks for all your input. I would make use of user's timezone as part of the view/controller layers, and use a fixed timezone (say UTC) for the DB layers. OK, as said before, I already had the feeling that it does not fit into the model, however, there it would have been the most convenient. That said, I will now bite the bullet and do it the hard way, but won't have the feeling to make it more complicated than necessary, anymore. Christian -- http://www.inviCRO.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/
[Catalyst] how to set CATALYST_DEBUG
Hi All
I removed -Debug, and set $ENV{CATALYST_DEBUG} =1 using PerlSetEnv
CATALYST_DEBUG 1.
But it doesn't work. I can't see the debug info in the apache log file.
--
Jack Malloy
___
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] how to set CATALYST_DEBUG
err that switches it off in the app and switches it off in the env
var. Just remove -Debug and all should be fine
On 29/06/2009, at 5:21 PM, Malloy wrote:
Hi All
I removed -Debug, and set $ENV{CATALYST_DEBUG} =1 using PerlSetEnv
CATALYST_DEBUG 1.
But it doesn't work. I can't see the debug info in the apache log
file.
--
Jack Malloy
___
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] Re: Warnings when upgrading Catalyst
Tomas Doran wrote:
On 26 Jun 2009, at 21:41, George Nistorica wrote:
Hi,
(my reply might be garbled, sorry)
Makes perfect sense here.
my email was garbled as I wasn't subscribed to the list when the
original emails have been sent :P
I've got the same problem generated from a Controller that uses
Controller::REST as a base class.
And the warning being generated when I -forward() to another Controller
(doing some data validation).
Hmm, I can't replicate this in a simple case, from that description..
Here: http://www.depechemode.ro/MyApp-0.1.tar.gz
a simple TestApp using Catalyst::Controller::REST to replicate the
problem, having Catalyst 5.80005 installed.
Please have a look at the included README.
I've got around this warning by editing Catalyst.pm and adding this
piece of code
if ( not exists $c-counter-{$parent}
or not defined $c-counter-{$parent} )
{
$c-counter-{$parent} = 0;
}
right before the undefined value is used:
$c-stats-profile(
begin = $action,
parent = $parent . $c-counter-{$parent},
uid= $uid,
);
that worked for me, and now the debug output shows the profiling for the
methods I -forward() to as well:
the methods from another Controller to which I forward to, where missing
from the profiling output, getting that warning instead.
That looks like a prefect fix to me, but I'd _really_ like to get to the
bottom of what is causing the issue, so that we can write tests of some
form, and also because this could be hiding a bug at another layer which
should be fixed :/
that makes sense, what I did was just to shut off the warning, didn't
had the guts to look forward to search for the root of the problem.
Are you forwarding to a private path string, or an action object?
I guess extracting _just_ the structure of your controllers (without any
of the code, just the sub/attribute declerations), and ensuring your
doing the appropriate forwards that your app would be doing would
replicate the issue in a TestApp.
Don't suppose you could attempt that, so that we can find the root
cause, and get this fix integrated?
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/
--
#!/usr/bin/perl -w ###
use strict;###
( $_ = qq{0912 3c1217 709073043p2it//,
'70kc1H 270P 70htonA t3uJ tni7p'8;})
=~tr/42179038/(larves)/;eval#uate;
##
___
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] how to set CATALYST_DEBUG
On 29/06/2009, at 6:17 PM, Malloy wrote:
Thanks. But I want to control it using CATALYST_DEBUG or
MyApp_DEBUG, not
just switch it off.
So uncomment PerlSetEnv CATALYST_DEBUG=1 in you config when you want
debugging on.
On Mon, Jun 29, 2009 at 3:35 PM, Kieren Diment dim...@gmail.com
wrote:
err that switches it off in the app and switches it off in the env
var.
Just remove -Debug and all should be fine
On 29/06/2009, at 5:21 PM, Malloy wrote:
Hi All
I removed -Debug, and set $ENV{CATALYST_DEBUG} =1 using PerlSetEnv
CATALYST_DEBUG 1.
But it doesn't work. I can't see the debug info in the apache log
file.
--
Jack Malloy
___
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/
--
Jack Malloy
___
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] how to set CATALYST_DEBUG
2009/6/29 Kieren Diment dim...@gmail.com:
So uncomment PerlSetEnv CATALYST_DEBUG=1 in you config when you want
debugging on.
Where did he say he'd commented it out?
I removed -Debug, and set $ENV{CATALYST_DEBUG} =1 using PerlSetEnv
CATALYST_DEBUG 1.
Malloy, try dumping $ENV{CATALYST_DEBUG} in your app code and seeing
if it's actually set. Ideally, do that in lib/{App}.pm .
--
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] User timezones
2009/6/29 Christian Lackas christ...@lackas.net: OK, as said before, I already had the feeling that it does not fit into the model, however, there it would have been the most convenient. As I say, you'll need a formatting function or functions to turn dates-as-objects into dates in your page, regardless of timezones. You can set up your formatter that that it's initailised withh a timezone, and then your translation from DB-zone to view-zone comes for free as you would have to do the formatting call anyway. So: Once, somewhere once you've discovered the user and know their timezone: my $user=... DateFormatter-output_tz($user-timezone); In your view, and I assume TT here and that you've set up DateFormatter as a plugin or similar: [% DateFormatter.as_datetime(my_row.birthday) %] About as simple as it's ever likely to be, with the added advantage that you have a date formatter with a number of functions to output dates in one of a limited number of formats, so that your app has a consistent appearance. -- 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] Scalable Catalyst
Hi! Sorry for the lethargy, I've buried in a project and just recently
saw the light of day :-)
Yes, you are correct [Tomas], BUT it all depends on the type of
application. Web concurrency is often misinterpreted. The application
I was referring to needs the ability to have many, many concurrent
processes waiting for a response from another service which has a long
response time. So in this case, having many, many threads sitting
there waiting for a response is the way to go.
Web concurrency is usually a balance between:
1) The available RAM which limits the number of processes/threads you can load.
2) The time it takes for you to process a given request, and the CPU
power required to do it.
Concurrency tests with HTTPerf and AB will give you a good idea on
requests/per second on a number of given processes/threads and
monitoring CPU usage with top or similar, it's empirical but it works.
This way you can estimate the limits on the actual number of parallel
processes (be it processes or threads) that your machine is actually
able to crank.
Multi-threaded mod_perl (with Apache mod_worker) will only be an
advantage if you actually have the CPU power to process the threads in
parallel. If not, it just becomes sequential on the available CPU time
per thread. On the other hand, the usual case is that the CPU load is
low with respect to RAM usage in the traditional process-only model
(pre-fork), because each process being so large, your RAM fills up
with very few processes, so your not taking full advantage of your CPU
power. By using mod_perl under mod_worker you can use considerably
less RAM and put more actual work on the CPUs, but that comes back to
my original comment at the top: it all dependes on the application.
There are always too many things to consider, such as static content,
file uploads, streaming content and other stuff wich are most surely
managed better outside of your application.
Also, as you state, today's large applications should run behind
reverse proxies/balancers that can also pickup the tab on static
serving and other optimizations.
This is a very interesting diverse and complex subject, but the main
idea of my post was to state that Catalyst works well under
multi-threaded Apache with mod_perl, allowing, _in some cases_ better
usage of the available resources. It does not apply, of course, to all
cases, and your insight explains this very well.
BTW, Ashley suggested I write a how-to on the WIki or something like
that. Could some suggest exactly where, and I may have time to that
this week.
Best,
Alejandro Imass
On Fri, May 1, 2009 at 8:01 AM, Tomas Doranbobtf...@bobtfish.net wrote:
Alejandro Imass wrote:
Anyway, the message is that with mod_worker/mod_perl you can spawn
_thousands_ of threads, getting impressive concurrency (without
counting the mutex). We have tested Catalyst applications that handle
_thousands_ of concurrent requests using off the shelf AMD 64Bit HW
and 12Gb RAM, with a Catalyst app of about 20MB RSS.
There is a big difference between having thousands of requests in-flight at
once, and serving thousands of new requests a second.
You're saying that mod_worker can do the former well, without mentioning the
latter.
I'd very much guess that in your configuration, most of your workers (and
requests) are just pushing bytes to the user, which isn't really a hard
job.. :_)
The reason that normal mod_perl fails at this is you have one process per
request, and so having many many requests in flight at once hurts.
However, if you have thousands of requests all trying to generate pages at
once, you're going to fail and die - full stop...
perl -e'system(perl -e\while (1) {}\ \) for (1..1000)'
will convince you of this if you aren't already :)
You can trivially get round this by having a _small_ number of mod_perl
processes behind a proxy, so that your (expensive/large) mod_perl process
generates a page, then throws it at network speed (1Gb/s or higher if you're
on localhost) to the proxy, which then streams it to the user much much
slower. This frees up your mod_perl processes as quickly as possible to be
getting on with useful work.
I'd also note that having more threads/processes generating pages than you
have CPU cores is fairly inefficient, as the more processes you have, the
greater the penalty you're going to incur due to increased context switching
overhead. (
Quite often you block on the database in most apps, which means that 1
process per CPU core doesn't hold totally true for best throughput, so
YMMV..
For the record, one of my apps can trivially do 200 requests a second, with
3000+ concurrent requests in-flight, using a single 4Gb dual core x64 box
with one disk, running both the application _and_ the mysql server..
It flattens the 100Mb pipe to the internet I have in the office waaay before
the system actually starts to struggle from a load perspective..
That's nginx / fastcgi with 3 fcgi worker
Re: [Catalyst] how to set CATALYST_DEBUG
On 29 Jun 2009, at 14:34, Ian Wells wrote:
I removed -Debug, and set $ENV{CATALYST_DEBUG} =1 using PerlSetEnv
CATALYST_DEBUG 1.
Malloy, try dumping $ENV{CATALYST_DEBUG} in your app code and seeing
if it's actually set. Ideally, do that in lib/{App}.pm .
This behavior sounds like you may be running 5.80001.
If that's the case, please upgrade - you're hitting a bug which was
fixed.
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] Re: ajax character encoding issue solved, but WHY?
On Tue, Jun 23, 2009 at 1:28 AM, Aristotle Pagaltzis pagalt...@gmx.dewrote: * seasproc...@gmail.com seasproc...@gmail.com [2009-06-23 03:00]: Thanks for your suggestion, but I'm pretty sure that the data is not getting encoded twice. C::V::JSON tests the data before it encodes ( Encode::is_utf8() ) and only encodes if this test is true. This test only passes if the data is decoded. Augh! Augh! Why do people keep reading stuff into the UTF8 flag that it doesn’t mean. (Yeah, I know why, because it’s called the UTF8 flag when it should’ve been the UOK flag or something.) You can have decoded data with the UTF8 flag off, and you can have encoded data with the UTF8 flag on. (Sorry to be so slow to reply. I wanted to find time to fully investigate this, but haven't.) The Encode docs state: # When you encode, the resulting UTF8 flag is always off. # When you decode, the resulting UTF8 flag is on unless you can unambiguously represent data [as ASCII]. I was interpreting this to apply to all encoding/decoding -- but I now realize that it may only apply to the Encode package. Which really just leaves me more confused .. :) My suspicion is that I don't really understand what's happening inside sqlite -- I assume it's storing as UTF-8, but I don't really know what it's doing. Try Devel::Peek to examine the strings that come out of it? I used Devel::StringInfo and found: [info] string: Madrid Alarcón is_utf8: 0 octet_length: 15 valid_utf8: 1 decoded_is_same: 0 decoded: octet_length: 15 downgradable: 1 char_length: 14 string: Madrid Alarc is_utf8: 1 raw = Madrid Alarcón I did not draw any brilliant conclusions from this, although I'm curious why the decoded version has the non-ASCII char cut off. At this point, obviously, I need to find the time to dig in further. Thanks for your thoughts! 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/ -- == http://www.bikewise.org 2People citizen's network for climate action: http://www.2people.org Greater Seattle Climate Dialogues: http://www.climatedialogues.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] Scalable Catalyst
On 30 Jun 2009, at 11:58, Alejandro Imass wrote: Hi! Sorry for the lethargy, I've buried in a project and just recently saw the light of day :-) Yes, you are correct [Tomas], BUT it all depends on the type of application. Web concurrency is often misinterpreted. The application I was referring to needs the ability to have many, many concurrent processes waiting for a response from another service which has a long response time. So in this case, having many, many threads sitting there waiting for a response is the way to go. You're doing it wrong. Don't block app server threads on a remote service if you have a slow remote service, the only thing that lies down that route is doom and fail. Use a job queue or something so that your application servers don't sit waiting for slow remote services. If you really actually need to block architecturally, then a heavy weight application server is just the wrong solution, full stop. I'm sure that the worker mpm will give you more headroom if you have loads of mod_perl processes blocking than prefork, but I very much consider this to be an optimisation, not a solution. That said, I'm not trying to be disparaging, and I'm happy this works for you, and is a viable option :) The one thing that worries me about this is that it uses threads, and threads and perl don't get on.. For example, Moose's string style type constraints are a bad world (because the regex used makes various versions of at least perl 5.8 core dump). I don't think that this is an issue for anything in the Catalyst stack, as we're either type-constraint free, or use exclusively MooseX::Types stuff (which doesn't use those regular expressions, and therefore is safe, I think) - but may be a problem for other code.. I can certainly remember an un-fun world of apache puking it's guts on a coworker's machine as he was using the worker mpm.. So YMMV, depending on what portion of CPAN you use, and/or what your codebase looks like... :-/ This is a very interesting diverse and complex subject, but the main idea of my post was to state that Catalyst works well under multi-threaded Apache with mod_perl, allowing, _in some cases_ better usage of the available resources. It does not apply, of course, to all cases, and your insight explains this very well. Indeed - it all very much depends on the application load profile etc - so all of this is just painting the bike shed, unless we're discussing a specific application on a real (i.e. something like production) set of hardware, and have actual performance metrics we want to ensure it fulfill. :) BTW, Ashley suggested I write a how-to on the WIki or something like that. Could some suggest exactly where, and I may have time to that this week. http://dev.catalyst.perl.org/wiki/deployment Making a section linked from 'Apache' in there, briefly outlining your config and what benefits you get from doing mod_perl this way would be great :) 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] Scalable Catalyst
On Tue, Jun 30, 2009 at 2:42 PM, Tomas Doranbobtf...@bobtfish.net wrote: You're doing it wrong. Don't block app server threads on a remote service if you have a slow remote service, the only thing that lies down that route is doom and fail. I don't see the problem. In fact, this was the _main and central_ point of our application: to handle as many concurrent requests acting like a dam to the slower service. At first, it seems like a perfect application for EDA, but any attempt in this sense failed miserably... Use a job queue or something so that your application servers don't sit waiting for slow remote services. I tried POE, AnyEvent and several other EDA patterns, tests, etc. making an external Job Manager, and our customer even resorted to hire someone to hack the Catalyst Engine making it even-based and it got really ugly in the actual tests. Threads with mod_worker worked fine and proved to be far more stable/scalable than any other option we tried. Incredible as it sounds, multi-threaded was way more stable than the other paths we tried. The way I see it LWP was exactly the solution we needed for this. If you really actually need to block architecturally, then a heavy weight application server is just the wrong solution, full stop. In this case, practical proved better than theory. We heavily tested in FreeBSD 6 and 7 and LInux 2.6.20+. The only thing we found was that Linux's VM still needs a lot of work once you start heavily using swap, it usually doesn't recover; it's usually faster switching than FreeBSD 6, and even 7 but a lot less stable. FreeBSD recovered in every case. I'm sure that the worker mpm will give you more headroom if you have loads of mod_perl processes blocking than prefork, but I very much consider this to be an optimisation, not a solution. Ok. What would you have done? - not meant as a defensive question but really, we would like to hear options for this application! believe me, we tried almost everything. The event-based Catalyst engine was a great idea, but the actual tests proved that it really had no real advantages over process/thread with mod_worker. Besides, it proved very problematic, unstable and hard to maintain in the long run. I remembered my previous experiences while working on Enterprise Service Bus technology and our results were very similar to Welsh's final conclusions on SEDA: It is also worth noting that a number of recent research papers have demonstrated that the SEDA prototype (in Java) performs poorly compared to threaded or event-based systems implemented in C. This would seem to contradict the findings in my work. (For more information I invite you to read recent papers by Vivek Pai's group at Princeton and the Capriccio work from UC Berkeley Actually, no further work after SEDA has ever proved that Event-Based is actually better than process/thread. I confirmed this with people at Priceton (Vivek Pai himself) about a year ago. As stated, we tried AnyEvent and POE and fiddled with the idea of implementing some kind of Async mechanism to/from the client. It's a B2B server so the syncing problems could have gotten very messy. We needed to block anywhere from 1 to 7 seconds and we expected several thousand hits per app server to make it cost effective. This is what we came up with Catalyst: 50 Apache processes with 64 threads each for a total of 3200 threads using about 10GB of RAM (12GB is actually on each server, for the OS, the mutex and to avoid swapping at all costs). The 3200 blocking load can be handled with 2 dual core AMD 64 Bit processors (4 are actually used). not a bad deal cost-wise and it works. Each 64 thread process grows to about 200MB RSS ( 750MB VSZ), plus a base Apache root process of about 115MB. So we have 3200 actual blocking requests + the Apache mutex, so the overall capacity of each app server is quite decent for the price. At the moment we reset each process every 1 requests with no observable or serious leaks or otherwise any sort of problems. We take about 65ms per request in our whole processing but sadly we have to block for the amount stated above. The app does have some complexity because it does considerable XML processing with LibXML 2 (DTD validations, XSL transformatiosn, XPath queries and such), database interaction with MySQL and talks to another server via LWP::UserAgent (this is where each thread blocks). We chose Catalyst precisely because of the flexibility to adapt to different scenarios (mod_perl, FastCGI, etc.) with little or no code change. That said, I'm not trying to be disparaging, and I'm happy this works for you, and is a viable option :) It did and it works fine. This is why I wouldn't discourage people to use mod_worker, although as we have both agreed it all depends on the actual application. The one thing that worries me about this is that it uses threads, and threads and perl don't get on.. For example, Moose's string style type I've done many
Re: [Catalyst] REST and text/html not supported
You can override the default serializers:
__PACKAGE__-config(
'default' = 'application/json',
'stash_key' = 'rest',
'map' = {
'text/html' = [ 'View', 'TT', ],
'text/xml' = [ 'View', 'TT', ],
},
);
On Tue, Jun 30, 2009 at 4:07 PM, Angel Kolevanko...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all
i have controller Myapp::Controller::Offers with use parent
'Catalyst::Controller::REST' where all RESTed requests works fine, but
then i have Myapp::Controller::Offers::Create where i dont want
C::C::REST to work, because when i send common form with content type
'application/x-www-form-urlencoded' to /offers/create/done i recieve 415
Content-Type text/html is not supported. The done method is:
sub done: Local: ActionClass('RenderView')
I dont want this controller to be RESTish or atleast how i can enable
text/html content types here?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpJJekACgkQlAw25U6UlpCgsQCfWamzBWlE/tU2eMHbnb9HHv6s
KRQAnRMAnF6Sjf2RO6gGH9gaEJpzSTqa
=wwA/
-END PGP 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/
___
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] REST and text/html not supported
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks! Now it works.
Alejandro Imass wrote:
You can override the default serializers:
__PACKAGE__-config(
'default' = 'application/json',
'stash_key' = 'rest',
'map' = {
'text/html' = [ 'View', 'TT', ],
'text/xml' = [ 'View', 'TT', ],
},
);
On Tue, Jun 30, 2009 at 4:07 PM, Angel Kolevanko...@gmail.com wrote:
Hi all
i have controller Myapp::Controller::Offers with use parent
'Catalyst::Controller::REST' where all RESTed requests works fine, but
then i have Myapp::Controller::Offers::Create where i dont want
C::C::REST to work, because when i send common form with content type
'application/x-www-form-urlencoded' to /offers/create/done i recieve 415
Content-Type text/html is not supported. The done method is:
sub done: Local: ActionClass('RenderView')
I dont want this controller to be RESTish or atleast how i can enable
text/html content types here?
___
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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpJKvsACgkQlAw25U6UlpDefACgpRwH5cuOQAKFSNLM4Ha8HKT3
2xAAn3x+1IoEXq8NW009kf9ABk0xpFsU
=DxEk
-END PGP 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] REST and text/html not supported
Yeah, nowadays it's confusing between XHTML and HTML so just use TT
both and you're covered, unless you have special XML needs and have to
discriminate. In any case you can forward to a private sub like so:
sub collection :Local :ActionClass('REST') {
my ( $self, $c ) = @_;
unless($c-forward('check_headers')){
$self-status_bad_request(
$c,
message = 'BAD HEADERS',
);
return;
}
}
sub check_headers : Private {
my ( $self, $c ) = @_;
my $accept = $c-req-header('accept');
return undef unless $accept;
if($accept =~ m/html/){
$c-req-header('accept' = 'text/html');
}
elsif($accept =~ m/xml/){
$c-req-header('accept' = 'text/xml');
$c-stash-{template} = $c-action.'.xml';
}
return 1;
}
YMMV,
Alex
On Tue, Jun 30, 2009 at 4:28 PM, Angel Kolevanko...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks! Now it works.
Alejandro Imass wrote:
You can override the default serializers:
__PACKAGE__-config(
'default' = 'application/json',
'stash_key' = 'rest',
'map' = {
'text/html' = [ 'View', 'TT', ],
'text/xml' = [ 'View', 'TT', ],
},
);
On Tue, Jun 30, 2009 at 4:07 PM, Angel Kolevanko...@gmail.com wrote:
Hi all
i have controller Myapp::Controller::Offers with use parent
'Catalyst::Controller::REST' where all RESTed requests works fine, but
then i have Myapp::Controller::Offers::Create where i dont want
C::C::REST to work, because when i send common form with content type
'application/x-www-form-urlencoded' to /offers/create/done i recieve 415
Content-Type text/html is not supported. The done method is:
sub done: Local: ActionClass('RenderView')
I dont want this controller to be RESTish or atleast how i can enable
text/html content types here?
___
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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpJKvsACgkQlAw25U6UlpDefACgpRwH5cuOQAKFSNLM4Ha8HKT3
2xAAn3x+1IoEXq8NW009kf9ABk0xpFsU
=DxEk
-END PGP 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/
___
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: uri_for() corrupts query parameters hash for caller
On 26 Jun 2009, at 23:19, Byron Young wrote: Alrighty, here you go, patch + test are attached. There are based off the 5.71001 svn head because that's what I have currently. 5.8's uri_for() looks the same, so it should apply there as well, but let me know if you need another one from 5.8. http://dev.catalyst.perl.org/svnweb/Catalyst/revision/?rev=10736 Thanks very much for the patch, applied ok to 5.80 trunk. I rewrote your fix to just not mangle $_, which fixes the same issue with less code, and avoids the unsafe each.. Unfortunately, this just missed the Catalyst 5.80006 release, so you'll have to wait for the next one to see it in released code, sorry! 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] RE: uri_for() corrupts query parameters hash for caller
Tomas Doran wrote on 2009-06-29: On 26 Jun 2009, at 23:19, Byron Young wrote: Alrighty, here you go, patch + test are attached. There are based off the 5.71001 svn head because that's what I have currently. 5.8's uri_for() looks the same, so it should apply there as well, but let me know if you need another one from 5.8. http://dev.catalyst.perl.org/svnweb/Catalyst/revision/?rev=10736 Thanks very much for the patch, applied ok to 5.80 trunk. I rewrote your fix to just not mangle $_, which fixes the same issue with less code, and avoids the unsafe each.. Unfortunately, this just missed the Catalyst 5.80006 release, so you'll have to wait for the next one to see it in released code, sorry! Cheers t0m Oh, nice, that's a much better solution. If you don't mind, though, can you explain what you mean about the 'unsafe each'? Thanks! Byron ___ 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: uri_for() corrupts query parameters hash for caller
On 30 Jun 2009, at 00:31, Byron Young wrote: If you don't mind, though, can you explain what you mean about the 'unsafe each'? If your application code half iterates through the params hash with each before calling uri_for, then the param copy would only copy the second half of the hash (as each has an internal iterator). 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] RE: uri_for() corrupts query parameters hash for caller
Tomas Doran wrote on 2009-06-29: On 30 Jun 2009, at 00:31, Byron Young wrote: If you don't mind, though, can you explain what you mean about the 'unsafe each'? If your application code half iterates through the params hash with each before calling uri_for, then the param copy would only copy the second half of the hash (as each has an internal iterator). Cheers t0m Ah, makes sense. Learn something new every day! Thanks! Byron ___ 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] how to set CATALYST_DEBUG
I can get $ENV{CATALYST_DEBUG} in my templates. But can't get it in
lib/{App}.pm.
#Use of uninitialized value $ENV{CATALYST_DEBUG} in print at
/path/lib/{app}.pm line 38.
And Catalyst is up to date.
cpan install Catalyst
Catalyst is up to date (5.80005).
On Tue, Jun 30, 2009 at 2:45 AM, Tomas Doran bobtf...@bobtfish.net wrote:
On 29 Jun 2009, at 14:34, Ian Wells wrote:
I removed -Debug, and set $ENV{CATALYST_DEBUG} =1 using PerlSetEnv
CATALYST_DEBUG 1.
Malloy, try dumping $ENV{CATALYST_DEBUG} in your app code and seeing
if it's actually set. Ideally, do that in lib/{App}.pm .
This behavior sounds like you may be running 5.80001.
If that's the case, please upgrade - you're hitting a bug which was fixed.
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/
--
Jack Malloy
___
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] Cat Model DBIC Schema fails test if *optional* prereq isn't installed
Hi, Catalyst::Model::DBIC::Schema lists Catalyst::Devel as an *optional* dependency. However if you do not have Catalyst::Helper installed (via Catalyst::Devel) then C-M-DBIC-Schema fails its unit tests and won't install via CPAN. -Toby ___ 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: uri_for() corrupts query parameters hash for caller
* Tomas Doran bobtf...@bobtfish.net [2009-06-30 02:35]: If your application code half iterates through the params hash with each before calling uri_for, then the param copy would only copy the second half of the hash (as each has an internal iterator). FWIW you can reset the iterator using `keys`, which is cheap to call in void or scalar context too. 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/
