Re: [Catalyst] OT: Use the CPAN, Luke? (was: Catalyst install failure due to Mouse.pm on Debian Etch)
On Thu, Nov 27, 2008 at 3:55 AM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: * Toby Corkindale [EMAIL PROTECTED] [2008-11-27 01:55]: The problem is the dependency Mouse (0.11) fails its unit tests there. That's really the sole solid argument against a flamboyant use-the-CPAN attitude: you end up pulling in heaps of bloat because none of the stuff was written to form a coherent whole: every author uses their own favourite way of doing some common thing so you get four different OO frameworks of varying heft, two different YAML modules, every JSON module there is, etc., all loaded into the same perl process. What a waste. Case in point, Mouse is essentially Moose Light. Since Catalyst itself is becoming Moose-based, is there *any* reason to use Mouse instead? I suppose if it automatically stubs itself into a Moose loader where Moose is available, that would be not *too* bad, but it's still a pointlessly added dependency. There is also Squirrel (http://search.cpan.org/~sartak/Mouse-0.11/lib/Squirrel.pm) - it loads Mouse unless Moose is already loaded (just citing the Synopsis). At the operating system level I've seen sometimes 'virtual packages' that decouple the services from packages that provide those services. So you can have a service 'sendmail' that actually is provided by the 'postfix' package. This level of compatibility between libraries is rather exceptional - I think that Moose and Mouse are the only examples so far, but maybe it is time to start thinking about that. CatalystX::CRUD tries to work with both RDBO and DBIC - the effect is a bit too heavyweight for my liking, but it is a bold experiment. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.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] FormValidator and FV_eq_with constraint method
Answering my own question again. It appears that you have to add all fields to either the required or optional array in order that Data::FormValidator processes them correctly. -- View this message in context: http://www.nabble.com/FormValidator-and-FV_eq_with-constraint-method-tp20703984p20715702.html Sent from the Catalyst Web Framework mailing list archive at Nabble.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] Re: OT: Use the CPAN, Luke?
Maybe there should be a list of modules that should be preferred for certain purposes when writing Catalyst extensions? Of course we don't to *prescribe* any of them, since the main selling point of Catalyst is that cares more about being glue and about having an opinion. So if you want to glue something big like Template Toolkit or Mason into Catalyst you might have to accept modules which duplicate functionality that other dependencies already offer. But it might be good to say for tasks where you don't already have a really strong opinion and where it's up to you, please strongly consider using the following modules. (The Catalyst Canon maybe, if you will.) I think this is a great idea - I know the flexibility that Catalyst offers is a big selling point, however I think lots of people new to Catalyst (or just new to a different area of Catalyst) want to know best practices, e.g. which modules have been tried and tested in a production environment, which modules are well accepted, written and supported, etc. Obviously TMTOWTDI but I'm very happy to take advice from people who have lots of experience in the field - if you're developing systems for production you'd be crazy not to. I guess there's: http://dev.catalystframework.org/wiki/recommended_plugins or something like: http://search.cpan.org/~perigrin/Task-Kensho-0.0.4/lib/Task/Kensho.pm Cheers, Ian -- Ian Sillitoe CATH Team -- http://cathdb.info ___ 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] PDF upload problems (prob OT)?
Hi. Following up here after some time on another project.
--- On Fri, 11/7/08, Joel Bernstein [EMAIL PROTECTED] wrote:
From: Joel Bernstein [EMAIL PROTECTED]
Subject: Re: [Catalyst] PDF upload problems (prob OT)?
To: The elegant MVC web framework catalyst@lists.scsys.co.uk
Date: Friday, November 7, 2008, 5:01 PM
2008/11/8 Dermot [EMAIL PROTECTED]
2008/11/7 Dr. Jennifer Nussbaum
[EMAIL PROTECTED]:
Anyone willing to help me on this? :-) Im only
missing four bytes,
somewhere Or adding them rather.
Jen.
I can't test this from where I am writing but as
Adeola says.
Open a temporary FH, binmode it, pour the content in.
Then under MP2 you
would
$r-sendfile($tmpfh);
content_type is 'application/pdf'
I guess the Cat alternative would be
$res-write( $tmpfh );
but you'd want to check that :)
I'd use $c-response-body( $filehandle ) to
achieve this. I'm not sure what
you're expecting -write() to do there.
How do i do this given that im pulling the data from a database? That is, my
view' method is mostly like
my $document = $c-model-find($id);
my $contents = $document-documment;
$c-res-output($contents);
$c-res-headers-content_type($document-type);
How do i make this binary?
Also, in a separate message T0m Doran wrote, responding to my observation tht i
had been gaining 4 bytes in size:
--
I'd be prepared to bet that you're appending 4 bytes somewhere, either at
the start, or the end of the document.. So have a look, and tell us which?
Then start adding some debug, so your code becomes:
my $upload = $c-request-upload('document');
my $contents = $upload-slurp;
$c-log-debug(Uploaded file was . length($contents) . bytes);
my $document = $c-model-create({ document = $contents,
type = $upload-type,
filename = $upload-basename});
and
my $contents = $document-document;
$c-log-debug(Document contents were . length($contents) . bytes);
$c-res-output($contents);
$c-res-headers-content_type($document-type);
I did try this and discovered that this problem isnt consistent. at least riht
now, im looking at one particular file that is problematic. It concistently
looks fine with Evince on the commandline, and consistently
looks bad with Evince in the browser piped through the database.
I have added this debug code, and discovered that for this file it is always
9 bytes. Thats what it is in the filesystem before i upload it,
thats what it is when Cat reports it as T0m suggest i do above, and thats what
it is when Cat outputs it again as described above.
But the output is messed up--still visible but with errors throughout, as if
someone had written it on a blackboard and erased parts and shifted other parts.
so maybe the four byte extra is a different issue? I cant replicate it at least
for this file. So maybe its a binmode thing after all? How do i force it to
output as binary?
Thanks and sorry for the long delay!
Jen
___
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] PDF upload problems (prob OT)?
On 27 Nov 2008, at 12:51, Dr. Jennifer Nussbaum wrote: I have added this debug code, and discovered that for this file it is always 9 bytes. Thats what it is in the filesystem before i upload it, thats what it is when Cat reports it as T0m suggest i do above, and thats what it is when Cat outputs it again as described above. But the output is messed up--still visible but with errors throughout, as if someone had written it on a blackboard and erased parts and shifted other parts. so maybe the four byte extra is a different issue? I cant replicate it at least for this file. So maybe its a binmode thing after all? How do i force it to output as binary? Ok, next thing to try is to capture the HTTP request and response being made. You can then replay that HTTP request to see if it reliably creates the same problem, and also inspect the contents before it gets to the browser to check where the corruption is happening. I'd recommend using Paros (http://www.parosproxy.org/) for this - it's got nice features to trap requests and alter their contents. 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] Catalyst install failure due to Mouse.pm on Debian Etch
On Thu, Nov 27, 2008 at 1:47 AM, Toby Corkindale [EMAIL PROTECTED] wrote: Hi guys, I'm having trouble getting Catalyst to install (via CPAN) on a fresh Debian Etch install. The problem is the dependency Mouse (0.11) fails its unit tests there. (I'd guess due to the older versions of some core packages). I've raised http://rt.cpan.org/Ticket/Display.html?id=41254. Catalyst::Action::RenderView (first module which was wanting Mouse) itself seems to pass its own unit tests after Mouse is force-installed, though. Hey toby... http://search.cpan.org/src/MRAMBERG/Catalyst-Action-RenderView-0.08/Makefile.PL- I'm pretty sure RenderView does not depend on Mouse. Marcus ___ 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] Catalyst install failure due to Mouse.pm on Debian Etch
On 27 Nov 2008, at 11:40, Simon Elliott wrote: Hey toby... http://search.cpan.org/src/MRAMBERG/Catalyst-Action- RenderView-0.08/Makefile.PL - I'm pretty sure RenderView does not depend on Mouse. is does however depend on Data::Visitor which uses Squirrel, so installing Moose should solve this. No, because Squirrel is part of the Mouse package, and therefore won't help solve test fails in Mouse.. 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] PDF upload problems (prob OT)?
--- On Thu, 11/27/08, Tomas Doran [EMAIL PROTECTED] wrote: From: Tomas Doran [EMAIL PROTECTED] Subject: Re: [Catalyst] PDF upload problems (prob OT)? To: [EMAIL PROTECTED] Cc: The elegant MVC web framework catalyst@lists.scsys.co.uk, [EMAIL PROTECTED] Date: Thursday, November 27, 2008, 5:13 AM On 27 Nov 2008, at 12:51, Dr. Jennifer Nussbaum wrote: I have added this debug code, and discovered that for this file it is always 9 bytes. Thats what it is in the filesystem before i upload it, thats what it is when Cat reports it as T0m suggest i do above, and thats what it is when Cat outputs it again as described above. But the output is messed up--still visible but with errors throughout, as if someone had written it on a blackboard and erased parts and shifted other parts. so maybe the four byte extra is a different issue? I cant replicate it at least for this file. So maybe its a binmode thing after all? How do i force it to output as binary? Ok, next thing to try is to capture the HTTP request and response being made. You can then replay that HTTP request to see if it reliably creates the same problem, and also inspect the contents before it gets to the browser to check where the corruption is happening. This is really cool and i didnt know you could do this! I installed Paros and have played around with it. Unfortunatly i cant figure out what is happening, still. My reponse headers look like this: --- HTTP/1.0 200 OK Connection: close Date: Thu, 27 Nov 2008 14:36:52 GMT Content-Length: 93341 Content-Type: application/pdf Set-Cookie: session=7eccab441f14e3d142a072a231c66e51e5b91598; path=/; expires=Thu, 27-Nov-2008 15:36:52 GMT Status: 200 X-Catalyst: 5.7014 - Which seems OK to me, i guess, though the Content-Length isnt the same as what Cat is reporting for the output, which is 9, same as the file size. (I guess thats from headers) The PDF itself looks like the PDF i can view in the terminal. It begins --- %PDF-1.4 %âãÏÓ 8 0 obj /N 1 /Filter /FlateDecode /Alternate /DeviceGray /Length 631 stream --- and it ends --- 092712 0 n trailer /Info 11 0 R /Root 10 0 R /Size 12 /ID [3bf4386624f3e774819afb5b8dfa18af669eeb717392a42f4903bdf458b7f775] startxref 92936 %%EOF - both of which match what i see when i look at the thing itself. So im not really sure where to go from here. I can report that the effect is the same with Epiphany, Firefox, and Opera. Jen ___ 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 no operation `index' for portType error
Hi,
I have a SOAP controller based on WSDL. Maybe I confused something
but I understood that I need to add
# this is the endpoint from where the RPC operations will be
# dispatched. This code won't be executed at all.
# See Catalyst::Controller::SOAP::RPC.
sub index :Local SOAP('RPCEndpoint') {}
to the controller (as described in the Synopsis). And then the
client will be allowed to call the root address and be despatched to
the right action based on the SOAP message (instead of using different
addresses for each action).
But with this addition compilation fails with the error: no operation
`index' for portType {urn:calculator}SMSPortType, pick from
Strictly speaking the message is true - there is no 'index' operation
defined in the WSDL - but I thought that this RPCEndpoint action would
be treated differently.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.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] Catalyst::Controller::SOAP no operation `index' for portType error
I've been playing with this recently. What have you actually defined your
endpoint to be in the WSDL?
definition
...
service name=MyService
port name=MyServicePort binding=tns:MyServiceBinding
* soap:address location=http://example.com/service/*
/port
/service
/definition
I think the example in the synopsis shows you how to set up an endpoint for:
/service/index
Which then dispatches to, e.g.
/service/operation1
/service/operation2
Did you mean that? The usual behaviour is for the endpoint to be set to the
root path - e.g.
/service
If this is what you meant then:
sub index :Path('') SOAP('RPCEndpoint') {}
or just use one of the subclassed controllers which sets this default
behaviour for you (depending on your style of WSDL)
use base qw/C::C::SOAP::RPC/;
# or
use base qw/C::C::SOAP::DocumentLiteralWrapped/;
Cheers,
Ian
--
Ian Sillitoe
CATH Team -- http://cathdb.info
___
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] Catalyst install failure due to Mouse.pm on Debian Etch
Marcus Ramberg wrote: On Thu, Nov 27, 2008 at 1:47 AM, Toby Corkindale [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi guys, I'm having trouble getting Catalyst to install (via CPAN) on a fresh Debian Etch install. The problem is the dependency Mouse (0.11) fails its unit tests there. (I'd guess due to the older versions of some core packages). I've raised http://rt.cpan.org/Ticket/Display.html?id=41254. Catalyst::Action::RenderView (first module which was wanting Mouse) itself seems to pass its own unit tests after Mouse is force-installed, though. Hey toby... http://search.cpan.org/src/MRAMBERG/Catalyst-Action-RenderView-0.08/Makefile.PL - I'm pretty sure RenderView does not depend on Mouse. Hi Marcus, C-A-RV depends on Data::Visitor, which depends upon Mouse. I'm sure it's not the only Catalyst module which depends upon Data::Visitor though? Toby -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ 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] Catalyst install failure due to Mouse.pm on Debian Etch
Simon Elliott wrote: Hey toby... http://search.cpan.org/src/MRAMBERG/Catalyst-Action-RenderView-0.08/Makefile.PL - I'm pretty sure RenderView does not depend on Mouse. is does however depend on Data::Visitor which uses Squirrel, so installing Moose should solve this. Squirrel is bundled in the Mouse package. Mouse fails to install cleanly. .. One can force the install, but I remember MST asking for reports of instances where Catalyst didn't install cleanly, and this is one of those cases. ta, Toby -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ 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] Catalyst install failure due to Mouse.pm on Debian Etch
Toby Corkindale wrote: Hi guys, I'm having trouble getting Catalyst to install (via CPAN) on a fresh Debian Etch install. The problem is the dependency Mouse (0.11) fails its unit tests there. (I'd guess due to the older versions of some core packages). I've raised http://rt.cpan.org/Ticket/Display.html?id=41254. .. and after a speedy reaction from the maintainer of Mouse, the problem has been traced to Test::Exception. It seems the (as usual, ancient) version shipped with Debian stable is broken in some respect to handling the magic that goes on inside our four-legged squeaky friend. Upgrading Test::Exception from 0.21 to 0.27 resulted in Mouse passing all tests. Toby -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ 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: OT: Use the CPAN, Luke?
At 06:58 2008-11-27, Aristotle Pagaltzis wrote: According to the Mouse docs, Mouse supports the most commonly used features of Moose, but runs in 25% of the time. I'm happy I think that may be referring to startup time (and the Mouse POD refers to compile time actually). In the context of web apps, if you're interested in performance at all, you're obviously not going to use CGI. It's gonna be a persistent environment. So in that scenario, startup cost is irrelevant. I benchmarked a few OO/accessor modules, and Mouse was amongst the slowest ones. IIRC there's a 4:1 performance difference between Mouse and immutable Moose classes (mutable Moose classes is a disaster, a few percent slower than Mouse I think it was). So you make Moose classes immutable. The benchmark wasn't scientific or anything, basically just a new() with some of the default values overridden in the call + a getter access. I think Moose was something like 20% behind Class::Accessor::Fast and Spiffy was really fast. Like the Moose docs say, you pay for what you use. In this case, when I added type constraints they became the most expensive things beyond the basics, but still as performant as hand coding the validation. /J ___ 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] OT Apache question
A few weeks ago I asked a series of questions about caching, at the end of which discussion it was suggested that I use Apache, instead of Cat with the Static::Simple plugin, to serve my static files. I had tried this once before and ran into problems and given up, so, the question: I'd prefer to keep my current directory setup, in which I have my Cat applications, in the usual configuration, under /usr/local/www/modules. So, for example, my incomings database is at /usr/local/www/modules/Incomings, its templates are at /usr/local/www/modules/Incomings/root (so Static::Simple serves them normally), the controllers are at (for example) /usr/local/www/modules/Incomings/lib/Incomings/Controller/Search.pm, and so forth. However my document root is at /usr/local/www/data, which obviously does not include /usr/local/www/modules. So, if I try to follow the Static::Simple suggestion of adding, say, Location /Incomings/static SetHandler default-handler /Location this obviously won't work because /Incomings/static isn't in fact under my document root, it's in the filesystem at /usr/local/www/modules/Incomings/root/static/. Trying this just gives me 404's for all of the static stuff (CSS, images, JS). How do I configure Apache to serve these files, without reorganizing what is by now a rather complicated directory structure? Thanks. Jesse ___ 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] OT Apache question
Jesse Sheidlower wrote: A few weeks ago I asked a series of questions about caching, at the end of which discussion it was suggested that I use Apache, instead of Cat with the Static::Simple plugin, to serve my static files. I had tried this once before and ran into problems and given up, so, the question: I'd prefer to keep my current directory setup, in which I have my Cat applications, in the usual configuration, under /usr/local/www/modules. So, for example, my incomings database is at /usr/local/www/modules/Incomings, its templates are at /usr/local/www/modules/Incomings/root (so Static::Simple serves them normally), the controllers are at (for example) /usr/local/www/modules/Incomings/lib/Incomings/Controller/Search.pm, and so forth. However my document root is at /usr/local/www/data, which obviously does not include /usr/local/www/modules. So, if I try to follow the Static::Simple suggestion of adding, say, Location /Incomings/static SetHandler default-handler /Location this obviously won't work because /Incomings/static isn't in fact under my document root, it's in the filesystem at /usr/local/www/modules/Incomings/root/static/. Trying this just gives me 404's for all of the static stuff (CSS, images, JS). How do I configure Apache to serve these files, without reorganizing what is by now a rather complicated directory structure? Could you use the apache Alias directive? Alias /Incomings/static/ /usr/local/www/modules/Incomings/root/static/ -tjc -- Strategic Data Pty Ltd Ph: 03 9340 9000 ___ 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] OT Apache question
On Thursday 27 November 2008 08:45:16 pm Jesse Sheidlower wrote: However my document root is at /usr/local/www/data, which obviously does not include /usr/local/www/modules. So, if I try to follow the Static::Simple suggestion of adding, say, Location /Incomings/static SetHandler default-handler /Location this obviously won't work because /Incomings/static isn't in fact under my document root, it's in the filesystem at /usr/local/www/modules/Incomings/root/static/. Trying this just gives me 404's for all of the static stuff (CSS, images, JS). How do I configure Apache to serve these files, without reorganizing what is by now a rather complicated directory structure? Alias /incomings/static /yada/yada/root/static Location /incomings/static SetHandler default-handler /Location ___ 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] OT Apache question
On Thu, Nov 27, 2008 at 07:10:20PM -0800, J. Shirley wrote: On Thu, Nov 27, 2008 at 6:45 PM, Jesse Sheidlower [EMAIL PROTECTED] wrote: [Details of unbelievably n00bish Apache config question] this obviously won't work because /Incomings/static isn't in fact under my document root, it's in the filesystem at /usr/local/www/modules/Incomings/root/static/. Trying this just gives me 404's for all of the static stuff (CSS, images, JS). How do I configure Apache to serve these files, without reorganizing what is by now a rather complicated directory structure? [...] If you just add in an alias, it should do the trick. You'll also have to instruct Apache on how to handle the directory, iirc. Something similar to this should do the trick (in addition to setting the proper handler, as you have done above): Alias /incoming/static /real/path/on/disk/to/incoming/static Directory /real/path/on/disk/to/incoming/static /Directory Many thanks to all who responded so quickly to a question I should have thought about more thoroughly myself, vastly sooner. The Alias option worked fine, though with the addition of a Directory block for the filesystem giving allow from all access to its contents. Is it worth putting this into the C::P::Static::Simple docs, or other places where we talk about Apache configs? I will quite obviously volunteer for the task, if people don't think it's OT or too basic to mention in Cat docs. Jesse ___ 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] OT Apache question
On 28/11/2008, at 2:30 PM, Jesse Sheidlower wrote: Is it worth putting this into the C::P::Static::Simple docs, Yes, that would be the right place for it. A recipe for lighttpd would be good too. or other places where we talk about Apache configs? I will quite obviously volunteer for the task, if people don't think it's OT or too basic to mention in Cat docs. Jesse ___ 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] OT Apache question
On Fri, Nov 28, 2008 at 02:40:26PM +1100, Kieren Diment wrote: On 28/11/2008, at 2:30 PM, Jesse Sheidlower wrote: Is it worth putting this into the C::P::Static::Simple docs, Yes, that would be the right place for it. Done, but A recipe for lighttpd would be good too. Since I've never used lighttpd, I'll leave this for someone else. A section on Using with Lighttpd under Using with Apache, and a mention in the last line of the Description section which mentions the Apache config, would be required. Thanks. Jesse ___ 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: OT: Use the CPAN, Luke?
On Fri, 28 Nov 2008, Johan Lindstr?m wrote: At 06:58 2008-11-27, Aristotle Pagaltzis wrote: According to the Mouse docs, Mouse supports the most commonly used features of Moose, but runs in 25% of the time. I'm happy I think that may be referring to startup time (and the Mouse POD refers to compile time actually). In the context of web apps, if you're interested in performance at all, you're obviously not going to use CGI. It's gonna be a persistent environment. So in that scenario, startup cost is irrelevant. I benchmarked a few OO/accessor modules, and Mouse was amongst the slowest ones. IIRC there's a 4:1 performance difference between Mouse and immutable Moose classes (mutable Moose classes is a disaster, a few percent slower than Mouse I think it was). So you make Moose classes immutable. The benchmark wasn't scientific or anything, basically just a new() with some of the default values overridden in the call + a getter access. I think Moose was something like 20% behind Class::Accessor::Fast and Spiffy was really fast. Like the Moose docs say, you pay for what you use. In this case, when I added type constraints they became the most expensive things beyond the basics, but still as performant as hand coding the validation. I'm pretty sure that Moose (especially when making one's classes immutable) has a much bigger _compile_ time hit than Mouse. OTOH, Moose's immutabilized constructor is faster than Mouse's. I think the optimal use case for Mouse is something in a process that gets started a lot (a CLI app, for example). In that case, the compile time savings can easily outweight the runtime loss. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */ ___ 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] OT Apache question
On Thu, Nov 27, 2008 at 8:13 PM, Jesse Sheidlower [EMAIL PROTECTED] wrote: On Fri, Nov 28, 2008 at 02:40:26PM +1100, Kieren Diment wrote: On 28/11/2008, at 2:30 PM, Jesse Sheidlower wrote: Is it worth putting this into the C::P::Static::Simple docs, Yes, that would be the right place for it. Done, but A recipe for lighttpd would be good too. Since I've never used lighttpd, I'll leave this for someone else. A section on Using with Lighttpd under Using with Apache, and a mention in the last line of the Description section which mentions the Apache config, would be required. Thanks. Jesse Not to get too distracted, but nginx and varnish shouldn't be neglected. Should this go in the wiki and pod, or just pod, or both? I'll try to get varnish and nginx recipes tomorrow, since I use both. -J ___ 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/
