Re: [Catalyst] Problems with Encoding support in Catalyst.

[John Napiorkowski]

Hi Bill,
is_utf8 probably doesn't do what you think it does:
http://stackoverflow.com/questions/14579560/am-i-using-utf8is-utf8-correctly

If we are throwing errors here that we'd prefer handled differently, see if you 
can workup a test case and I will bounce it around.
The Binmode problem is interesting.  I was never happy with that. lets work up 
some test cases and I will bounce it around some of the UTF8 experts.
At the least we might want some sort of configuration option.
John 

On Saturday, January 7, 2017 11:56 PM, Bill Moseley  
wrote:
 

 I just finally removed my custom encoding code to use the built-in code 
Catalyst now provides to decode input data and encode output.
But, I came across two issues that I wanted to get some feedback on.
First one is simple.  This code will die if $value is already decoded.  Any 
reason not to test it?

 sub _handle_param_unicode_decoding {     my ( $self, $value, $check ) = @_;    
 return unless defined $value; # not in love with just ignoring undefs - jnap   
  return $value if blessed($value); #don't decode when the value is an object.+ 
   return $value if Encode::is_utf8($value);  # already decoded?
This next one is what I have questions about.   This is also in Catalyst.pm in 
the encoding() method:
        # Let it be set to undef        if (my $wanted = shift)  {            
$encoding = Encode::find_encoding($wanted)              or Carp::croak( 
qq/Unknown encoding '$wanted'/ );            binmode(STDERR, ':encoding(' . 
$encoding->name . ')');

The problem with that is it seems to turn off autoflush on STDERR.   In my case 
that is causing intermixing of lines in the log files.
If I turn on STDERR->autoflush(1) then the logging works again and log lines 
are not mangled.
But, I'm not sure we should apply a layer to STDERR like that.   For example, I 
log to stderr with JSON and that is already encoded.
Is there a compelling reason to binmode STDERR there?



-- 
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] Multipart/form-data file uploads missing

[John Napiorkowski]

Hi,
We need more info to help understand this.  Like from what version of Catalyst 
did you upgrade from and what is the new version?  Also we'd need to see more 
details about the actual code that is working differently.
In general AFAIK file uploads are supposed to be in $c->req->uploads although I 
also think the filename or something is in req->body_parameters.  In general I 
tell people to avoid ->param and ->parameters since the munging of GET and BODY 
parameters can lead to weird bugs and security issues so modifying your code 
might be worth the time.  ->param is especially problematic (see the security 
notes over at https://metacpan.org/pod/Catalyst::Request#req-param )
There was a lot of work done on those bits when we worked on the UTF-8 support 
stuff, FWIW.
Please consider trying to work through this rather than just introducing a 
local hack or just saying, "fuck it I'm not going to bother upgrading."  As an 
open source project Catalyst can only improve when people bother.  
If you can get on IRC (irc.perl.org#catalyst) you might be able to get more 
timely help.
jnap

 

   

 On Tuesday, November 15, 2016 11:57 AM, Chris Huttman 
 wrote:
 

  There's no problem with my code - in fact I migrated to an Ubuntu 12.04 LTS 
EC2 image that I found and it is working fine there.  I just won't upgrade, I 
guess.  Clearly something broken in whatever the newest release that is in the 
14.04 or 16.04 server packages.
 
 -c
 
 
 
 On 11/15/2016 2:27 AM, Chris Welch wrote:
  
   I think the file upload is in $c->request->upload - I have a file called 
"image", which I access with $c->request->upload("image"), does that help?   
  
 ___
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/


   ___
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] Custom Folder Names...?

[John Napiorkowski]

So sadly these I think (last I looked) is pretty firmly hardcoded.  You might 
with some code change that but I'd rather see a patch to make those directorys 
something loaded from configuration.  That way various helper modules could use 
that configuration to do the right thing.
If interested let me know I could probably give you some pointers.
John 

On Sunday, August 14, 2016 4:55 AM, Andrew 
 wrote:
 

  Hello, =). Is it possible to customise the folder names of a Catalyst app?For 
example: rename the Controller folder...? Just wondered... =). Yours,Andrew.
___
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] UTF8 and content length

[John Napiorkowski]

So what it looks like to me is that the code that sets a content length if one 
is not set by the view is not dealing with unicode correctly.  I have another 
unicode issue I need to look at soonish so I try to see if we can get  a test 
case for this.  -jnap 

On Wednesday, July 20, 2016 8:18 AM, Kroshka Yenot <trash...@cary.lv> wrote:
 

  >>> Looks like to a bug to me tl;dr   I'm not sure its a Catalyst bug or 
problem. It's may be MY configuration problem or standard violation
  
  Here are my investigation results
  
  I created a test to reproduce this situation 
  # catalyst.pl test # test/script/test_create.pl view HTML TT
  # [editor]  test/lib/test/Controller/Root.pm
  sub index :Path :Args(0)
 {
     my ( $self, $c ) = @_;
 
     my $json_text = '{"id":1, "msg":"В Питере пить"}';
     $c->response->content_type('application/json');
     $c->response->body($json_text);
 }
  
  and found following:
  
   wget -S -O - http://domain.tld:3000
 --2016-07-20 13:56:18--  http://domain.tld:3000/
 Resolving cary.lv (cary.lv)... aaa.bbb.ccc.ddd
 Connecting to domain.tld (domain.tld)|aaa.bbb.ccc.ddd|:3000... connected.
 HTTP request sent, awaiting response...
   HTTP/1.0 200 OK
   Date: Wed, 20 Jul 2016 10:56:18 GMT
   Server: HTTP::Server::PSGI
   Content-Type: application/json
   X-Catalyst: 5.90106
   Content-Length: 42
 Length: 42 [application/json]
 Saving to: 'STDOUT'
  
  content-Length is properly set. I see same using Firefox Dev tools
  but in the log (build-in test server log)
  [debug] Response Code: 200; Content-Type: application/json; Content-Length: 
unknown
  
  Exactly same code, but app works as fastcgi daemon and Apache/2.4.23 
(FreeBSD) serves http requests 
  # wget -S -O - http://domain.tld/
 --2016-07-20 15:02:28--  http://domain.tld/
 Resolving domain.tld (domain.tld)... aaa.bbb.ccc.ddd
 Connecting to domain.tld (domain.tld)|aaa.bbb.ccc.ddd|:80... connected.
 HTTP request sent, awaiting response...
   HTTP/1.1 200 OK
   Date: Wed, 20 Jul 2016 12:02:28 GMT
   Server: Apache
   Set-Cookie: lang=ru; path=/; expires=Thu, 20-Jul-2017 12:02:28 GMT
   Set-Cookie: sid=3b2b88c4106b5e06c0c24a5c3a513ccbcb939299; domain=domain.tld; 
path=/; expires=Wed, 20-Jul-2016 12:52:28 GMT; HttpOnly
   X-Catalyst: 5.90106
   Content-Length: 31
   Keep-Alive: timeout=5, max=100
   Connection: Keep-Alive
   Content-Type: application/json
 Length: 31 [application/json]
  
  Content length here is in chars not in bytes
  A solution by Aristotle Pagaltzis 
   $c->response->body(Encode::encode_utf8 $json_text); gives proper content 
length in this situation
  I'm getting same proper content length if I change content type to 
'text/html' 
  Finally, I've discovered Catalyst::View::JSON and it not only solved this 
problem for me, but also gave me a much more comfortable solution to work with 
json 
  $c->stash->{msg} = "В Питере пить";
 $c->stash->{id} = 1;
 $c->forward('View::JSON');
  Works like a charm
  
  Taking this opportunity, thank you for this lovely framework! I'll be happy 
to provide any additional information if you still consider there is something 
should be fixed
  
  
  
 
 
 
 19.07.2016 19:10, John Napiorkowski пишет:
  
  Looks like to a bug to me, although I'm not personally keen on the auto 
length setting in Catalyst it should be corrected.  I'm happy to get a patch, 
or at the very least give me a broken test case (checkout 
https://github.com/perl-catalyst/catalyst-runtime/blob/master/t/utf_incoming.t  
  and see if you can help me figure it out -jnap 
  (created an issues for this, 
_https://github.com/perl-catalyst/catalyst-runtime/issues/143 
  
  
  
 
  On Friday, July 15, 2016 6:07 AM, Kroshka Yenot <trash...@cary.lv> wrote:
  
 
Hi! if content type is 'application/json' or 'application/json; 
charset=utf-8' Catalyst sets content length in chars, NOT IN BYTES and I'm  
getting 
  {"id":1, "msg":"В Питере if content type is 'text/html' Catalyst sets content 
length in bytes (properly) and everything works fine
  Is there any workaround to configure this behaviour, except setting content 
length manually everytime ?
  
  my $json_text = '{"id":1, "msg":"В Питере пить"}';
  $c->response->content_type('application/json');
 $c->response->content_length(bytes::length $json_text);
 $c->response->body($json_text);
  Thanks in advance
  

 ___
 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

Re: [Catalyst] UTF8 and content length

[John Napiorkowski]

Looks like to a bug to me, although I'm not personally keen on the auto length 
setting in Catalyst it should be corrected.  I'm happy to get a patch, or at 
the very least give me a broken test case (checkout 
https://github.com/perl-catalyst/catalyst-runtime/blob/master/t/utf_incoming.t 
and see if you can help me figure it out -jnap
(created an issues for this, 
_https://github.com/perl-catalyst/catalyst-runtime/issues/143


 

On Friday, July 15, 2016 6:07 AM, Kroshka Yenot  wrote:
 

   Hi! if content type is 'application/json' or 'application/json; 
charset=utf-8' Catalyst sets content length in chars, NOT IN BYTES and I'm 
getting 
  {"id":1, "msg":"В Питере if content type is 'text/html' Catalyst sets content 
length in bytes (properly) and everything works fine
  Is there any workaround to configure this behaviour, except setting content 
length manually everytime ?
  
  my $json_text = '{"id":1, "msg":"В Питере пить"}';
  $c->response->content_type('application/json');
 $c->response->content_length(bytes::length $json_text);
 $c->response->body($json_text);
  Thanks in advance
  
  
___
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] KISS - Base Subroutines.

[John Napiorkowski]

I'd consider a Role or maybe a Util package with 'Exporter' depending on what 
the shared function is intended to do -jnap 

On Thursday, July 14, 2016 6:47 PM, "anthony.okusa...@usbank.com" 
 wrote:
 

 Put a subroutine in a separate place, where it can beaccessed / called, by
whatever controllers need to use it?
-
Why not put all your subroutines ina Role  and consume the role in your main 
application class.

Package Role::HelpUtils;
use Moose::Role;

sub redirect_to_action {
        my ($c,$controller, $action, @params) =@_;
        
$c->response->redirect($c->uri_for($c->controller($controller)->action_for($action),@params));
        $c->detach;
}

1;

In your main app class, simply use therole
package MyApp;
use Moose; 
use Catalyst::Runtime ;
with 'Role::HelpUtils';

You can then access the subroutinesusing  e.g $c->redirect_to_action()



Thanks

Tony B. Okusanya



From:       "Andrew"
To:       "The elegant MVCweb framework" , 
Date:       07/14/2016 05:59 PM
Subject:       Re: [Catalyst]KISS - Base Subroutines.



Okay, no worries, I've done it now.

Created a folder called CommonUse to exist alongside Controller, View,and
Model folders, and hold perl modules that are commonly used, =).

Create a file in the folder.

Put my subroutine in the file.

Then in the controller I want to find the subroutine, where it normally
says:
BEGIN { extends 'Catalyst::Controller' }
...I switch it to say:
BEGIN { extends 'MyApp::CommonUse::File' }
where MyApp is the name of my app, and File is the name of the perl
module file I created in the CommonUse folder.
Then that controller can call the subroutine, and everything seems to work,
=).

I read online, you could also put subrountines inside of Myapp.pm withinthe
lib folder, and all controllers could access it. I did try that, however,I
couldn't get it working, so any pointers on that appreciated.

Yours,
Andrew.



- Original Message -
From: "Andrew" 
To: "The elegant MVC web framework" 
Sent: Thursday, July 14, 2016 9:20 PM
Subject: [Catalyst] KISS - Base Subroutines.


Is there a keep it simple stupid answer to the following question:

Put a subroutine in a separate place, where it can be accessed / called,by
whatever controllers need to use it?






___
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/



U.S. BANCORP made the following annotations
-
Electronic Privacy Notice. This e-mail, and any attachments, contains 
information that is, or may be, covered by electronic communications privacy 
laws, and is also confidential and proprietary in nature. If you are not the 
intended recipient, please be advised that you are legally prohibited from 
retaining, using, copying, distributing, or otherwise disclosing this 
information in any manner. Instead, please reply to the sender that you have 
received this communication in error, and then immediately delete it. Thank you 
in advance for your cooperation.

-
___
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] what happened to mod_fastcgi?

[John Napiorkowski]

I can't say why this site disappeared, but this project is 'mature' at the 
least and the technology is probably not seeing updates much.  And a lot of 
people are doing deployments using the front server as a proxy rather than 
other a protocol (for example running the server application on a stamen 
process with apache or nginx infrount via http or (ideally) via socket).  As a 
result the approach is falling out of favor for no particularly good reason 
other than a lot of people just don't use it.
That said its solid and I would use mod_fastcgi (and I do on several production 
applications).  I don't like mod_fcgid  and have not had good luck with it.
Just go ahead and keep using it.  As long as you understand how it works and 
know how to set it up its great.  I think its just slowly harder to find the 
correct documentation around it.  
Snap
 

On Tuesday, April 5, 2016 9:56 AM, Daniel J. Luke  
wrote:
 

 I had problems getting mod_fcgid working well on my (small) catalyst setups.

I've had good luck so far with mod_proxy_fcgi (with apache 2.4.x)

On Apr 5, 2016, at 8:46 AM, clara resende  wrote:
> The site of mod_fastcgi http://www.fastcgi.com/ has disappeared and googling 
> a bit further I found that apparently the project has been abandoned.
> 
> Does anybody know exactly what is going on with the project? 
> 
> I've been using catalyst+apache+mod_fastcgi for many years and now I am 
> wondering if I should switch to mod_fcgid. What I understand is that both 
> modules work differently and have different performance, are there any 
> guidelines/recommendations with respect to migrating?

-- 
Daniel J. Luke




___
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] New view: ICal?

[John Napiorkowski]

If you don't have a lot of view only logic (the view is just a dumb 'take this 
perl data structure, convert it to a display format using default serialization 
rules and send it to the response) then a thin view adaptor with 
Catalyst::Model::Adaptor might be the easiest thing.  If you are using the most 
recent Catalyst you could even avoid the need for a boilerplate proxy class 
using component injection.
Then main thing is thinking about how to shuffle data to the view.  Most 
current art uses the stash, but lately I prefer to avoid that and use either a 
dedicated view model, or the default model, so that I can properly constrain my 
data and offer the view better view only logic.
In general think 'how can I do something generally useful' over 'what is the 
Catalyst way to do this'.  Ideally your Catalyst components (models, views, 
etc) are the thinnest possible layer to adapt a stand alone model.
jnap 

On Friday, March 4, 2016 4:28 AM, Kieren Diment  wrote:
 

 looks to me like you'd want Catalyst::Model::Adaptor + Data::iCal + an 
optional very thin view that did something like:

    $c->res->content_type($ical_content_type);
    $c->res->body($c->stash->{calendar});

in the process method, and not much else.

The reason you don't see views for stuff like this much in catalyst land is 
that this kind of thing is usually pretty simple.

On Fri, Mar 4, 2016 at 8:22 PM, Chris Welch  wrote:

Thanks for the reply - may I ask what the model would be doing, given that 
presumably it would have to go through a view in the end anyway?  Because the 
data itself already exists in a model, all I'm wanting to do effectively is 
extract that and display it in a slightly different format, so I'm surprised 
that another model is the way to go - but then I've sort of been learning as I 
go with this stuff, so I may well be missing something fundamental!
Thanks
___
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/


  ___
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] soliciting feedback for alternative method attributes syntax

[John Napiorkowski]

On Monday, January 11, 2016 7:30 AM, Hartmaier Alexander 
<alexander.hartma...@t-systems.at> wrote:

Hi John,
the first question that came to my mind was: Why is it called At, both the 
module as well as the method attribute?
-Thanks for taking the time here, its really helpful!  Obviously I can 
always write something that makes total sense to me, but unless other people 
look at it and discuss I can't make it something that makes sense to others (or 
decide if its worth doing at all...)
'At' I chose because I wanted the shortest possible thing that I think conveyed 
 enough information to describe what it was doing.  I find with my actions when 
I have subroutine signatures, complex routing and a few action roles I end up 
with a very very long subroutine preamble.  Part of my motivation is to make it 
shorter but not at the expense of understanding.  is "At" too meaningless? -
The 'Naming your Arguments' section is confusing because it populates a 
variable named '$id' but uses '$_{id}' for the response.
I understand that you want to show that the args get passed to the sub like in 
core Catalyst but I'd do that in a second example as the preferred way to do it 
with this module would be $_{id}.
- I'll try to redo that bit to disambiguate better.  Part of me is not 100% 
convinced $_{NamedArg} is great for Catalyst.  So I am still thinking it 
over.-
I'd prefer to use the (experimental) subrouting signature feature of Perl 5.20 
than $_{id} which also doesn't have the same API as Perl 5.10 named regex 
capture patterns ($+{id}).
-Since my Catalyst stuff tries to be backcompat to 5.8.x and avoids 
anything marked experimental, and not widely seen on CPAN, I'd just use the 
classic form, but I think there's nothing stopping people from using something 
else right?-
An example how to allow literal {  and } in a URL should be added (and the 
feature if that doesn't exist).
-Awesome, will do that, and write a test case for it.-
The example in 'Matching GET parameters' is incorrect, the full-uri should 
be'https://fqdn/example/query?name=john;age=47'.
Would it also match any order of the parameters like 
'https://fqdn/example/query?age=47;name=john'? I didn't find this in the 
Catalyst::ActionRole::QueryParameter docs.
-Since query params are not supposed to be ordered, the example works 
either way.  I know some frameworks use hacks to allow ordering, but its 
explicitly in the RFC that the order is not to be considered meaningful.  I'll 
fix the typo, thanks!-
That might be a stupid question because I don't know the internal workings but 
could it be called 'Chained' instead of 'Via' so if someone want's to convert 
the route matching to this module (s)he doesn't have to rewrite as much?
-Again this is me looking for something shorter, but I could probably 
overload it to allow either Via or Chained.  I just always found that Chained 
being used to express root, midpoints and endpoints to be a little too much 
semantic polymorphism :)-
I think I like the parameter type matching and extraction more than the 
different syntax but I'm no good measure because I've grown up with Chained ;)
-The thing is if the classic Chained stuff works for you, I'm glad, and 
this is probably not aimed at you.  I've just heard from literally dozens of 
people that they don't understand chaining, often ban in in the code, and 
there's a lot of confusion as to when to using Chaining versus 'classic' 
attributes.  In general I've noted that the attribute based URL mapping caused 
a ton of trouble for people and just want to experiment with ideas that might 
make it easier for that group.  Thanks!-
Cheers, Alex


On 2016-01-08 00:41, John Napiorkowski wrote:

Lots of people tell me the hardest thing about catalyst is the method 
attributes used to describe routes, particularly chaining.  Here's a sketch for 
an alternative syntax that encompasses chaining along with more simple routes.
>
>
>jjn1056/Catalyst-ControllerRole-At
>
>  
>            
>jjn1056/Catalyst-ControllerRole-At
>Catalyst-ControllerRole-At - Alternative was to describe Catalyst URL matching 
>paths. 
>
> 
>View on github.com Preview by Yahoo 
>
> 
>  
>
>
>the SYNOPSIS bit is still WIP so ignore it, but the rest of the docs are 
>proposed final.  There's no code for this yet, just docs, I'm looking for 
>feedback on 'is this easier to understand'.  
>
>
>Critique welcome, if constructive.  I know lots of people don't like the 
>method attribute stuff, but I'm not doing any work on that right now, so 
>constructive critique means not saying you'd prefer something other than 
>method attributes :) I already hear that, but this is something that can layer 
>as sugar on top of the existing work, or even mixed into an existing project.  
>I'm trying to split the difference between usefully different and al

[Catalyst] soliciting feedback for alternative method attributes syntax

[John Napiorkowski]

Lots of people tell me the hardest thing about catalyst is the method 
attributes used to describe routes, particularly chaining.  Here's a sketch for 
an alternative syntax that encompasses chaining along with more simple routes.
jjn1056/Catalyst-ControllerRole-At

|   |
|   |  |   |   |   |   |   |
| jjn1056/Catalyst-ControllerRole-AtCatalyst-ControllerRole-At - Alternative 
was to describe Catalyst URL matching paths. |
|  |
| View on github.com | Preview by Yahoo |
|  |
|   |


the SYNOPSIS bit is still WIP so ignore it, but the rest of the docs are 
proposed final.  There's no code for this yet, just docs, I'm looking for 
feedback on 'is this easier to understand'.  
Critique welcome, if constructive.  I know lots of people don't like the method 
attribute stuff, but I'm not doing any work on that right now, so constructive 
critique means not saying you'd prefer something other than method attributes 
:) I already hear that, but this is something that can layer as sugar on top of 
the existing work, or even mixed into an existing project.  I'm trying to split 
the difference between usefully different and alien brains difference.  Thanks
Jnap___
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] Plugin attributes and Moose

[John Napiorkowski]

To speak to the issue with MooseX::Emulate::Class::Accessor::Fast I don't think 
this is supposed to mix and match with Moose 'has' style attributes as in your 
example, see the docs:

https://metacpan.org/pod/MooseX::Emulate::Class::Accessor::Fast

Basically this is meant to be the fast easy way to move an old CA based class 
to Moose. If you are going to define attributes via 'has' then I'd just say you 
should stop using it.  You see this used in a bunch of older plugins to 
'moosify' them.  But IMHO those should be really Moose or Moo top to bottom.  
Just again no volunteers to do it and it mostly just works anyway.

Again, I would say if you are writing new code to just not use any of those 
compatibility shims.  best of luck -jnap


On Sunday, November 22, 2015 3:03 PM, Bill Moseley  wrote:



I wanted to note something (before the week gets started and time vanishes) 
about how Catalyst is behaving, and see if it's expected.

I asked about this on the Moose list, so sorry if you already saw this.

A Catalyst app extends Catalyst::Component, which has a BUILDARGS sub to merge 
in class configuration when creating instances of components.

This is how configuration can set initial values on attributes in Models, 
Views, Controllers, and the application class itself. 

If a (non-role) Moose-based plugin is loaded (which is common) it's added to 
the app's inheritance like this:

$meta->superclasses($plugin, $meta->superclasses);

 Which can be thought of like this:

@App::ISA = ( qw/ Catalyst::Plugin::Foo  Catalyst / );

The result then is that BUILDARGS in Catalyst::Component is no longer called, 
and then attributes in the App class are no longer populated from the config.

So, the behavior changes depending on what plugins are brought in.

Another odd issue I came against is that MooseX::Emulate::Class::Accessor::Fast 
causes odd behavior of Moose attributes.   This role is widely used in Catalyst.

In the code below note how the "foo" attribute has init_arg => undef to prevent 
it from being initialized.  With the the role not only is it initialized, but 
with a value that isn't an "Int".



package Foo;
>use Moose;
>
>
>with 'MooseX::Emulate::Class::Accessor::Fast';
>
>has foo => (
>is  => 'ro',
>isa => 'Int', # for error
>init_arg => undef,
>);
>
>
>
>package main;
>use strict;
>use warnings;
>
>
>my $foo = Foo->new( { foo => 'bar' } );
>
>
>use Data::Dumper;
>print Dumper $foo->foo;


Generates 'bar', which is not an Int.

$VAR1 = 'bar';


Comment out "with 'MooseX::Emulate::Class::Accessor::Fast';" and it behaves as 
expected.   Also comment out "init_arg" and Moose will complain about the 
string not begin an Int.

-- 

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] Plugin attributes and Moose

[John Napiorkowski]

I'm not sure how to solve your problem, explanation wise, however I might 
wonder if we can find a way to use a role, either Moose or Moo, instead of a 
class for your plugin.  I find its a more sane implementation.  I know a lot of 
legacy stuff from pre Catamoose doesn't do that but I can't think of a good 
reason why we'd not wish for them to all be converted.  Basically what I think 
of a plugin in Catalyst is just a role but we didn't have roles at the time 
Catalyst was first done so we were stuck rolling our own.  There's a few other 
weird things like how plugins are applied at setup_plugin time rather than 
earlier (which again I personally find to be a real pain in the butt but maybe 
there's some actually good use for it, just I don't see it.)


Even the role interface is probably too much since its applied on top of the 
application (and then automatically on the context).  Its a big hammer.  Then 
number one thing that always stopped me from bigger Catalyst refactoring is 
that I have not idea what people did to Catalyst internals with plugins... Its 
hard to figure out what you are breaking, which is why I tended to encourage 
people to try and use other things when they could like custom models, 
middleware, etc.  But you still need them from time to time I guess.   If all 
you want is some application scoped attributes you could do that with a 
application model, for example.  I personally consider 
'MooseX::Emulate::Class::Accessor::Fast' something that was written as an 
expedient way to get get CataMoose off the ground. I definitely would not use 
it in my code, particularly if I could use Moose or Moo anyway.  I wasn't 
around for most of CataMoose so I don't know the reasons why a lot of stuff was 
done in certain ways, but tho
 se shims I'd not use for new stuff.  I always assumed it was 'until someone 
has time to fix this right' but then no body bothered.

Sorry this probably didn't help.  snap


On Sunday, November 22, 2015 3:03 PM, Bill Moseley  wrote:



I wanted to note something (before the week gets started and time vanishes) 
about how Catalyst is behaving, and see if it's expected.

I asked about this on the Moose list, so sorry if you already saw this.

A Catalyst app extends Catalyst::Component, which has a BUILDARGS sub to merge 
in class configuration when creating instances of components.

This is how configuration can set initial values on attributes in Models, 
Views, Controllers, and the application class itself. 

If a (non-role) Moose-based plugin is loaded (which is common) it's added to 
the app's inheritance like this:

$meta->superclasses($plugin, $meta->superclasses);

 Which can be thought of like this:

@App::ISA = ( qw/ Catalyst::Plugin::Foo  Catalyst / );

The result then is that BUILDARGS in Catalyst::Component is no longer called, 
and then attributes in the App class are no longer populated from the config.

So, the behavior changes depending on what plugins are brought in.

Another odd issue I came against is that MooseX::Emulate::Class::Accessor::Fast 
causes odd behavior of Moose attributes.   This role is widely used in Catalyst.

In the code below note how the "foo" attribute has init_arg => undef to prevent 
it from being initialized.  With the the role not only is it initialized, but 
with a value that isn't an "Int".



package Foo;
>use Moose;
>
>
>with 'MooseX::Emulate::Class::Accessor::Fast';
>
>has foo => (
>is  => 'ro',
>isa => 'Int', # for error
>init_arg => undef,
>);
>
>
>
>package main;
>use strict;
>use warnings;
>
>
>my $foo = Foo->new( { foo => 'bar' } );
>
>
>use Data::Dumper;
>print Dumper $foo->foo;


Generates 'bar', which is not an Int.

$VAR1 = 'bar';


Comment out "with 'MooseX::Emulate::Class::Accessor::Fast';" and it behaves as 
expected.   Also comment out "init_arg" and Moose will complain about the 
string not begin an Int.

-- 

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] ShinyCMS doesn't work with Catalyst 5.90102

[John Napiorkowski]

This is a regression caused by a change introduced in 5.90102, which clearly is 
a release that should have baked longer.  My apologies, I was trying to clean 
up existing pull requests on github before end of year since I thought people 
that put in the effort of donating code deserved some sort of response.  
5.90103 should fix this issue, or use 5.90101 which seems to be a stable 
release.
peace,
snap
 


 On Wednesday, November 11, 2015 4:23 PM, Denny <2...@denny.me> wrote:
   

 Hi all,

ShinyCMS fails to run with the latest release of Catalyst, 5.90102:
http://paste.scsys.co.uk/501327

It works okay with the previous release, 5.90100:
http://paste.scsys.co.uk/501326

I assume this is a conflict between some part of my code, and one or
more of the changes in the latest Catalyst release (maybe the 'preserve
state across a chain' changes), but I don't know how to dig into that.
Can anybody help or advise?

Thanks,
Denny



___
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] Setting config after setup has been run is not allowed.

[John Napiorkowski]

You shouldn't try to change the configuration once setup if finished since at 
that point everything has been initialized.  if you change stuff there its not 
going to do anything.  Whats the actual use case you are trying to achieve here.
FWIW Calling $c->config for application scoped stuff is ok I believe (no 
change, just getting the data).  For example if I really need to do a plugin, I 
usually do like:
my $adaptor_namespace = sub {  my $app = shift;  if(my $config = 
$app->config->{'Plugin::InjectionHelpers'}) {    my $namespace = 
$config->{adaptor_namespace};    return $namespace if $namespace;  }  return 
'Catalyst::Model::InjectionHelpers';};
to create a way for the plugin to have stuff in the config.  In this case I 
also created an anonymous code ref instead of a normal method so that the 
plugin would not pollute the application namespace so much. 


 On Friday, September 25, 2015 8:40 AM, Bill Moseley  
wrote:
   

 I'm confused about this rather stern note in Catalyst.pm.
Is this the following wrapper related to the text in the NOTE?

B you MUST NOT call C<< $self->config >> or C<< __PACKAGE__->config >>as 
a way of reading config within your code, as this B give you 
thecorrectly merged config back. You B take the config values supplied 
tothe constructor and use those instead.
=cut
around config => sub {    my $orig = shift;    my $c = shift;
    croak('Setting config after setup has been run is not allowed.')        if 
( @_ and $c->setup_finished );
    $c->$orig(@_);};

I understand the NOTE for Model/View/Controllers where the component's 
__PACKAGE__->config is merged in with the application config for that 
component.   Calling $self->config won't be the same thing passed to the 
component's constructor.
But, what's the issue with calling $c->config( foo => 123 ) at runtime?   Or 
even $c->config( \%new_config )?   
Note that wrapper only applies to calling config on the app class, and does not 
apply to Model/View/Controllers.
Is there some other issues I'm missing?   What problem is that wrapper trying 
to prevent?
Thanks,

-- 
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] A Catalyst::Plugin::Session Alternative: Web::Starch

[John Napiorkowski]

FWIW I had to add a bit to the Catalyst session stuff to enable that store in 
cookie thing, here's the diff:
Search the CPAN - metacpan.org

|   |
|   |   |   |   |   |
| Search the CPAN - metacpan.orgChanges05 META.yml88 
inc/Module/Install/Base.pm11 inc/Module/Install/Can.pm11 
inc/Module/Install/Fetch.pm11 inc/Module/Install/Makefile.pm22 
inc/Module/Install/Metadata.pm33  |
|  |
| View on metacpan.org | Preview by Yahoo |
|  |
|   |


 Might just need a simple change on the catalyst adaptor.  


 On Thursday, July 9, 2015 2:29 PM, John Napiorkowski jjn1...@yahoo.com 
wrote:
   

 I would think that this could be used by Plack middleware and Catalyst as core 
session functionality.  So I don't think in the end its either or.
Aran, the main thing I can't figure is how to have a cookie storage... since 
that's gotta be aware of the request/response cycle.  I'd adopt this in a 
moment for new code if we could figure that part out.  Personally I just put a 
few tiny IDs in the session so cookie storage is more than enough, and nice for 
quick prototypes.
Any thoughts?  You can hit me out on IRC #catalyst if that is either - jnap 


 On Thursday, July 9, 2015 10:35 AM, Aran Deltac bluef...@gmail.com wrote:
   

 Ya, I have Plack::Middleware::Session listed in the alternatives section of 
the manual.  Thanks for the reply!

On Thu, Jul 9, 2015 at 7:14 AM Hartmaier Alexander 
alexander.hartma...@t-systems.at wrote:

Hi Aran,
did you look at Plack::Session if you want something decoupled from Catalyst?
I haven't used it so far as I don't require sessions that are shared with 
non-Catalyst stuff but it might be a better base for a futureproof session 
module.

On 2015-07-09 02:17, Aran Deltac wrote:

Hey guys,
I've been working on a project which is a (mostly) drop in replacement for 
Catalyst::Plugin::Session.  Here are the GitHub repos:
https://github.com/bluefeet/Web-Starchhttps://github.com/bluefeet/Web-Starch-Store-CHIhttps://github.com/bluefeet/Web-Starch-Store-AmazonDynamoDBhttps://github.com/bluefeet/Web-Starch-Plugin-Serealhttps://github.com/bluefeet/Catalyst-Plugin-Starch
The manual is a good place to start:
https://github.com/bluefeet/Web-Starch/blob/master/lib/Web/Starch/Manual.pod

I'm using this @work and will be deploying it to production, replacing 
Catalyst::Plugin::Session, sometime next week if all goes well this week.
I've not put these modules on CPAN yet as I'd love some feedback before I do 
so.  I want to make sure the module names, the interfaces, and just the entire 
design are acceptable to people.  I want this to be a real step forward.
@work we've made extensive use of Catalyst::Plugin::Sesssion for years now, and 
related modules such as Catalyst::Plugin::Authentication.  So far everything 
has just worked when I replaced Catalyst::Plugin::Session with 
Catalyst::Plugin::Starch.
Why do this?   
   - Catalyst::Plugin::Session (C:P:S) is slower in NYTProf reports than I 
would expect it to be.
   - C:P:S is tied into Catalyst.  This is unnecessary.  Catalyst should be 
used to glue things together, not as a platform to build whole technologies on. 
 By decoupling sessions from Catalyst many wins can be had in reusability and 
unit testing (etc?).
   - C:P:S can be difficult and messy to extend.  This is partly due to how 
Catalyst plugins work, but also due to the design of C:P:S.
Aran

 


___
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/




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
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/


   

  ___
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] A Catalyst::Plugin::Session Alternative: Web::Starch

[John Napiorkowski]

I would think that this could be used by Plack middleware and Catalyst as core 
session functionality.  So I don't think in the end its either or.
Aran, the main thing I can't figure is how to have a cookie storage... since 
that's gotta be aware of the request/response cycle.  I'd adopt this in a 
moment for new code if we could figure that part out.  Personally I just put a 
few tiny IDs in the session so cookie storage is more than enough, and nice for 
quick prototypes.
Any thoughts?  You can hit me out on IRC #catalyst if that is either - jnap 


 On Thursday, July 9, 2015 10:35 AM, Aran Deltac bluef...@gmail.com wrote:
   

 Ya, I have Plack::Middleware::Session listed in the alternatives section of 
the manual.  Thanks for the reply!

On Thu, Jul 9, 2015 at 7:14 AM Hartmaier Alexander 
alexander.hartma...@t-systems.at wrote:

Hi Aran,
did you look at Plack::Session if you want something decoupled from Catalyst?
I haven't used it so far as I don't require sessions that are shared with 
non-Catalyst stuff but it might be a better base for a futureproof session 
module.

On 2015-07-09 02:17, Aran Deltac wrote:

Hey guys,
I've been working on a project which is a (mostly) drop in replacement for 
Catalyst::Plugin::Session.  Here are the GitHub repos:
https://github.com/bluefeet/Web-Starchhttps://github.com/bluefeet/Web-Starch-Store-CHIhttps://github.com/bluefeet/Web-Starch-Store-AmazonDynamoDBhttps://github.com/bluefeet/Web-Starch-Plugin-Serealhttps://github.com/bluefeet/Catalyst-Plugin-Starch
The manual is a good place to start:
https://github.com/bluefeet/Web-Starch/blob/master/lib/Web/Starch/Manual.pod

I'm using this @work and will be deploying it to production, replacing 
Catalyst::Plugin::Session, sometime next week if all goes well this week.
I've not put these modules on CPAN yet as I'd love some feedback before I do 
so.  I want to make sure the module names, the interfaces, and just the entire 
design are acceptable to people.  I want this to be a real step forward.
@work we've made extensive use of Catalyst::Plugin::Sesssion for years now, and 
related modules such as Catalyst::Plugin::Authentication.  So far everything 
has just worked when I replaced Catalyst::Plugin::Session with 
Catalyst::Plugin::Starch.
Why do this?   
   - Catalyst::Plugin::Session (C:P:S) is slower in NYTProf reports than I 
would expect it to be.
   - C:P:S is tied into Catalyst.  This is unnecessary.  Catalyst should be 
used to glue things together, not as a platform to build whole technologies on. 
 By decoupling sessions from Catalyst many wins can be had in reusability and 
unit testing (etc?).
   - C:P:S can be difficult and messy to extend.  This is partly due to how 
Catalyst plugins work, but also due to the design of C:P:S.
Aran

 


___
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/




***
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
***
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
***
___
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/


  ___
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] Regex dispatch type is deprecated

[John Napiorkowski]

Hey,

As far as I see this controller still works (I didn't even know about it...)  
It seems to do something a little different from the built in, which is it 
seems to want to return error messages (I can't really tell to be honest).  The 
built in support will just fail to match, so if you want a 'didn't match' 
response you;d need to add a catchall or less restrictive constraint to the 
same route.

Personally it doesn't do anything I need and its a bit old (uses NEXT and some 
other bits I'd like to see die from Catalyst support) but I have no current 
plan to break stuff that already works :)  You should try it and try the built 
in support and see what works best for you.   If you have code that works with 
this again I have no plan to break this but I'd consider for new stuff to see 
if the built in support does what you need (and if it doesn't consider 
contributing to that)

jnap



On Wednesday, July 8, 2015 4:13 AM, Craig Chant cr...@homeloanpartnership.com 
wrote:
Hi Jon,

Does that mean we shouldn't be using : 
http://search.cpan.org/~phaylon/Catalyst-Controller-Constraints-0.10_02/lib/Catalyst/Controller/Constraints.pm

Either?

Craig.

-Original Message-
From: John Napiorkowski [mailto:jjn1...@yahoo.com]
Sent: 07 July 2015 19:51
To: The elegant MVC web framework
Subject: Re: [Catalyst] Regex dispatch type is deprecated

Dmitry,

You can use the Regexp Dispatcher on CPAN, for legacy code.  There is no plan 
to stop supporting it, unless we hit a point where we can't support it when 
making required fixes to Catalyst.  I just wanted to remove it from Catalyst 
core such as to emphasis its no longer the approved approach and prevent people 
from writing new code with it.

If you are using the newest Catalyst, we added Type Constraint matching to Args 
and this should let you dispatch on regexp types in a very similar manner.  
Take a look at


https://metacpan.org/pod/distribution/Catalyst-Runtime/lib/Catalyst/RouteMatching.pod#Using-type-constraints-in-a-controller
which has an example of using a regular expression type constraint generator is 
a way that functions similarly to how the old regexp worked.  For example:


package MyApp::Controller::User;

use Moose;
use MooseX::MethodAttributes;
use Types::Standard qw/StrMatch/;

extends 'Catalyst::Controller';

sub looks_like_a_date :Path('') Args(StrMatch[qr{\d\d-\d\d-\d\d\d\d}]) {
  my ($self, $c, $date) = @_;
}

__PACKAGE__-meta-make_immutable;


requires a URL like /user/11-11-
That is one approach, or you can create custom ActionRoles for special dispatch 
rule needs.  In general I think the new feature to add type constraint checks 
on Args and CaptureArgs gives you everything you had with regexp and more.  
Feedback, and bug fix patches welcomed!

Jnap



On Tuesday, July 7, 2015 10:42 AM, Dmitry Karasik dmi...@karasik.eu.org wrote:



Hello all,

I'm upgrading an older Catalyst installation, and re-writing code that uses 
Regex/LocalRegex dispatchers. The rewriting is mostly for routes such as 
Regex('a-(\d+)-(\d+).png'), and I'm writing new code which basically does the 
same, but using :Args(1), manually matching the last part of url, and detaching 
to new route with matched parameters. This is not a problem, but I'm thinking 
that I must be not the only one having the same problem, and there must be a 
module on CPAN that dispatches execution using regexes, as a replacement. But 
Catalyst::DispatchType::Regex that seems to be the offical replacement, warns 
about the Regex/LocalRegex attributes are deprecated, which is confusing to me 
-- the feature was removed from the core, okay, but I still want to use it 
through a separate module, why then warn about deprecation again?

So basically my question is, what's the best recommended way to rewrite 
requests such as a-2-3.png, for example? Or, how could I rewrite these requests 
with chaining?

--
Thank you,
Dmitry Karasik


___
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/
This Email and any attachments contain confidential information and is intended 
solely for the individual to whom it is addressed. If this Email has been 
misdirected, please notify the author as soon as possible. If you are not the 
intended recipient you must not disclose, distribute, copy, print or rely on 
any of the information contained, and all copies must be deleted immediately. 
Whilst we take reasonable steps to try to identify any software viruses, any 
attachments to this e-mail may nevertheless contain viruses

Re: [Catalyst] Regex dispatch type is deprecated

[John Napiorkowski]

Dmitry,

You can use the Regexp Dispatcher on CPAN, for legacy code.  There is no plan 
to stop supporting it, unless we hit a point where we can't support it when 
making required fixes to Catalyst.  I just wanted to remove it from Catalyst 
core such as to emphasis its no longer the approved approach and prevent people 
from writing new code with it.

If you are using the newest Catalyst, we added Type Constraint matching to Args 
and this should let you dispatch on regexp types in a very similar manner.  
Take a look at 


https://metacpan.org/pod/distribution/Catalyst-Runtime/lib/Catalyst/RouteMatching.pod#Using-type-constraints-in-a-controller
which has an example of using a regular expression type constraint generator is 
a way that functions similarly to how the old regexp worked.  For example:


package MyApp::Controller::User;

use Moose;
use MooseX::MethodAttributes;
use Types::Standard qw/StrMatch/;

extends 'Catalyst::Controller';

sub looks_like_a_date :Path('') Args(StrMatch[qr{\d\d-\d\d-\d\d\d\d}]) {
  my ($self, $c, $date) = @_;
}

__PACKAGE__-meta-make_immutable;


requires a URL like /user/11-11-
That is one approach, or you can create custom ActionRoles for special dispatch 
rule needs.  In general I think the new feature to add type constraint checks 
on Args and CaptureArgs gives you everything you had with regexp and more.  
Feedback, and bug fix patches welcomed!

Jnap



On Tuesday, July 7, 2015 10:42 AM, Dmitry Karasik dmi...@karasik.eu.org wrote:



Hello all,

I'm upgrading an older Catalyst installation, and re-writing code that uses
Regex/LocalRegex dispatchers. The rewriting is mostly for routes such as
Regex('a-(\d+)-(\d+).png'), and I'm writing new code which basically does the
same, but using :Args(1), manually matching the last part of url, and detaching
to new route with matched parameters. This is not a problem, but I'm thinking
that I must be not the only one having the same problem, and there must be a
module on CPAN that dispatches execution using regexes, as a replacement. But
Catalyst::DispatchType::Regex that seems to be the offical replacement, warns 
about the
Regex/LocalRegex attributes are deprecated, which is confusing to me -- the
feature was removed from the core, okay, but I still want to use it through a
separate module, why then warn about deprecation again?

So basically my question is, what's the best recommended way to rewrite
requests such as a-2-3.png, for example? Or, how could I rewrite these requests
with chaining? 

-- 
Thank you,
Dmitry Karasik


___
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] Error: You requested a stash, but one does not exist #2

[John Napiorkowski]

Hi so

my $c = MyApp-new(); 

when you do that you don't have a context, its an instance of your application. 
 Since Catalyst conflates the two this is a common thing to think :)  But you 
only get a context IF you have a request.  So $app-stash isn't going to work.

I'd be happy to take a patch to do something sorta correct in application 
context, but I'd rather help you not use the stash like this.  Its probably 
going to make sad pandas down the road.  That's half the reason I went this 
direction (to help move us along toward the application/context split we've 
talked about for years and years...)

You could fake it by giving your instance a request object.  But tell me more 
about the use case

Jnap



On Wednesday, May 20, 2015 6:05 AM, Bernhard Bauch ba...@zsi.at wrote:



Hey all,

i'm testing an update to the latest Catalyst version.
the web-application via FCGI works fine, but i do run Catalyst from command 
line scripts as well.

likeuse MyApp;


my $c = MyApp-new(); 


my $val = 12345;
$c-stash-{val} = $val;

my $stash = $c-stash-{val};
print from stash: $stash\n;

since the upgrade i get the following error:

You requested a stash, but one does not exist at .\site\lib\Catalyst.pm 
line 517.

As i read stash is now a middleware plugin; and is stored in the PSGI? 
environment; for sure thats not available when running from CLI.

how to i make the good old stash working if i'm from command line ?

thanks for support,
bernhard






—
Bernhard Bauch
Webdevelopment

ZSI-Zentrum für Soziale Innovation GmbH
Centre for Social Innovation

Linke Wienzeile 246, A-1150 Wien, Austria
Mail: ba...@zsi.at
Skype: berni-zsi




___
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] Error: You requested a stash, but one does not exist #2

[John Napiorkowski]

Hey sorry to top post, but let me try to summarize:

1) You need to make URLs

Ok, perfect you should find that uri_for works in application context

MyApp-uri_for

and that should return a uri::generic object.  Hobbs thought it would be easy 
to add a util to Catalyst utils that takes a URI::generic and base URL and 
returns a real URL.  So that should work.  Give it a try and let me know?

2) Calling controllers from a script, etc.

I know you probably don't want to hear it (:) ) but I would strive to have all 
that business logic elsewhere (not in the controller), so that you can make 
this easier.

However if you can't do that we could take a patch to make stash do something 
not insane in application context or a plugin to make the stash like the old 
stash for people that can't make the leap.   How does that sound?

Jnap



On Wednesday, May 20, 2015 5:09 PM, Bernhard Bauch ba...@zsi.at wrote:
Hey again,

 You could fake it by giving your instance a request object.  

actually in my usecase, i already do fake a request object...
but that does not help either :(

looks like this.

 my $c = MyApp-new(); 
 

my $base_url = http://somedomain.com;;
my $uri_path = '/';
my $uri = \$uri_path;
bless $uri, 'URI::http';

my $base = \$base_url;
bless $base, 'URI::http';

# load request
$c-request(Catalyst::Request-new({
'cookies' = {},
'base'= $base,
'uri' = $uri,
'secure'  = 1,
'headers' = HTTP::Headers-new,
'_log'  = $c-log,
}));

 
 my $val = 12345;
 $c-stash-{val} = $val;
 
 my $stash = $c-stash-{val};
 print from stash: $stash\n;


I needed to have a request object to have
$c-uri_for();
working for my commandline script to be able to generate real URIs.

Do i need to add further magic while creating request object, so that stash 
would also work ? tried to 

 But tell me more about the use case
the CLI scripts are triggering different actions from Controllers and using the 
stash to passaround data from action to action or make some data available to 
all actions..
i guess that did not help much ;)

cheerz
bernhard


On 20 May 2015, at 21:27, John Napiorkowski jjn1...@yahoo.com wrote:

 Hi so
 
 my $c = MyApp-new(); 
 
 when you do that you don't have a context, its an instance of your 
 application.  Since Catalyst conflates the two this is a common thing to 
 think :)  But you only get a context IF you have a request.  So $app-stash 
 isn't going to work.
 
 I'd be happy to take a patch to do something sorta correct in application 
 context, but I'd rather help you not use the stash like this.  Its probably 
 going to make sad pandas down the road.  That's half the reason I went this 
 direction (to help move us along toward the application/context split we've 
 talked about for years and years...)
 
 You could fake it by giving your instance a request object.  But tell me more 
 about the use case
 
 Jnap
 
 
 
 On Wednesday, May 20, 2015 6:05 AM, Bernhard Bauch ba...@zsi.at wrote:
 
 
 
 Hey all,
 
 i'm testing an update to the latest Catalyst version.
 the web-application via FCGI works fine, but i do run Catalyst from command 
 line scripts as well.
 
 likeuse MyApp;
 
 
 my $c = MyApp-new(); 
 
 
 my $val = 12345;
 $c-stash-{val} = $val;
 
 my $stash = $c-stash-{val};
 print from stash: $stash\n;
 
 since the upgrade i get the following error:
 
 You requested a stash, but one does not exist at .\site\lib\Catalyst.pm 
 line 517.
 
 As i read stash is now a middleware plugin; and is stored in the PSGI? 
 environment; for sure thats not available when running from CLI.
 
 how to i make the good old stash working if i'm from command line ?
 
 thanks for support,
 bernhard
 
 
 
 
 
 
 —
 Bernhard Bauch
 Webdevelopment
 
 ZSI-Zentrum für Soziale Innovation GmbH
 Centre for Social Innovation
 
 Linke Wienzeile 246, A-1150 Wien, Austria
 Mail: ba...@zsi.at
 Skype: berni-zsi
 
 
 
 
 ___
 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/
 
 !DSPAM:555ce08316081354624907!

 
 

—
Bernhard Bauch
Webdevelopment

ZSI-Zentrum für Soziale Innovation GmbH
Centre for Social Innovation

Linke Wienzeile 246, A-1150 Wien, Austria
Mail: ba...@zsi.at
Skype: berni-zsi





___
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

Re: [Catalyst] Rackspace Ubuntu 14.04

[John Napiorkowski]

If you are installing Catalyst over a previous setup, or at least something 
where Moose already exists try using the moose-updated helper script to see if 
that clears stuff up -jnap 



 On Thursday, May 14, 2015 4:47 AM, Duncan Garland 
duncan.garl...@motortrak.com wrote:
   

 Hi John,

I didn't save all the terminal output, but here's what I have got from the 
second attempt.

Regards

Duncan



On Wed, May 13, 2015 at 9:30 PM, John Napiorkowski jjn1...@yahoo.com wrote:

I'd love to see a full install attempt.  I was getting tests for Perl down to 
5.8.8 before we release so I am not aware of a hard dependency on Tie::StdHash.
However I don't use cpanplus, and I write my own makefile.pl, not the one that 
Catalyst::Devel writes.  Its possible that something is going on there.  If 
someone can reproduce and send me an install trace I will review.
The intention for Catalyst is to run on the oldest Perl possible.  However I am 
finding particularly with the unicode stuff that getting a stable setup lower 
than 5.14 is a bit hard.  I do use 5.10.1 at work and we have it running there 
without trouble FWIW
John  


 On Wednesday, May 13, 2015 2:23 PM, Robert Brown r...@intelcompute.com 
wrote:
   

  Interesting, we don't use local::lib, just perlbrew, both dev and production, 
and keep the whole perlbrew dir in svn, works great.
 
 Will let the catalyst devs answer the actual/original question...
 
 
 On 13/05/15 19:01, Duncan Garland wrote:
  
  Hi,
 
  We don't use perlbrew on production, but I've used it in other areas without 
a problem. As far as I know it's very highly regarded.
 
  I've used local::lib successfully for development work ie Temporarily 
pointing to some different modules.
 
  I spent quite a lot of time at the beginning of this year trying to set it up 
so that we could use it seriously. I wanted to be able to do a twice yearly 
update from CPAN of all our modules into a seperate directory structure so that 
it would be easy to revert if the updated tree turned out to  contain a bug.
 
  local::lib plays nicely with cpan but not with cpanplus. The default way for 
a Catalyst app to maintain it's dependencies is to maintain Makefile.PL. When 
you run that it uses cpanplus. I struggled with it for quite a while and gave 
up.
 
  All the best.
  
 On Wed, May 13, 2015 at 6:26 PM, Robert Brown r...@intelcompute.com wrote:
 
  Not to answer your actual question, but...
 
 Have you also thought using Perlbrew http://perlbrew.pl
 
 As regular user, you can install any version of Perl locally (to your home 
dir), plus all the modules via cpanm, and keep everything self-contained for a 
particular user.
 
 It's made our deployments a breeze, rather than dealing with the system-wide 
perl, etc.
 
 (There's also local::lib tho I've not delved into that myself).
 
 Hope it helps a little.
 
 Rob
 
 
 On 13/05/15 18:16, Duncan Garland wrote:
  
Hi,
 
  I've just spun up a Rackspace server with Ubuntu 14.04 and tried to install 
Catalyst from CPAN.
 
  If the print out means what it seems to mean, then Catalyst will no longer 
install cleanly from CPAN on any version prior to 5.20.
 
  It's saying that there is a dependency on Tie::StdHash and that Tie::StdHash 
won't install without force because the latest version of the module is part of 
perl-5.20.2.
 
  It won't effect me because I'll just force it or download an older version of 
the module.
 
  All the same, it seems a bit poor.
 
  Is it deliberate?
 
  Regards
 
  Duncan
   
 
  
 The information contained in this message is for the intended addressee only 
and may contain confidential and/or privileged information. If you are not the 
intended addressee, please delete this message and notify the sender; do not 
copy or distribute this  message or disclose its contents to anyone. Any views 
or opinions expressed in this message are those of the author and do not 
necessarily represent those of Motortrak Limited or of any of its associated 
companies. No reliance may be placed on  this message without written 
confirmation from an authorised representative of the company. 
 Registered in England 3098391 V.A.T. Registered No. 667463890 
  
 ___
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/
 
 
  
  
 The information contained in this message is for the intended addressee only 
and may contain confidential and/or privileged information. If you are not the 
intended addressee, please delete this message and notify the sender; do

Re: [Catalyst] Rackspace Ubuntu 14.04

[John Napiorkowski]

Hi Duncan,
wow thats a lot of errors... this is system Perl now or a local lib, I got lost 
a bit in the thread above. 


 On Thursday, May 14, 2015 4:47 AM, Duncan Garland 
duncan.garl...@motortrak.com wrote:
   

 Hi John,

I didn't save all the terminal output, but here's what I have got from the 
second attempt.

Regards

Duncan



On Wed, May 13, 2015 at 9:30 PM, John Napiorkowski jjn1...@yahoo.com wrote:

I'd love to see a full install attempt.  I was getting tests for Perl down to 
5.8.8 before we release so I am not aware of a hard dependency on Tie::StdHash.
However I don't use cpanplus, and I write my own makefile.pl, not the one that 
Catalyst::Devel writes.  Its possible that something is going on there.  If 
someone can reproduce and send me an install trace I will review.
The intention for Catalyst is to run on the oldest Perl possible.  However I am 
finding particularly with the unicode stuff that getting a stable setup lower 
than 5.14 is a bit hard.  I do use 5.10.1 at work and we have it running there 
without trouble FWIW
John  


 On Wednesday, May 13, 2015 2:23 PM, Robert Brown r...@intelcompute.com 
wrote:
   

  Interesting, we don't use local::lib, just perlbrew, both dev and production, 
and keep the whole perlbrew dir in svn, works great.
 
 Will let the catalyst devs answer the actual/original question...
 
 
 On 13/05/15 19:01, Duncan Garland wrote:
  
  Hi,
 
  We don't use perlbrew on production, but I've used it in other areas without 
a problem. As far as I know it's very highly regarded.
 
  I've used local::lib successfully for development work ie Temporarily 
pointing to some different modules.
 
  I spent quite a lot of time at the beginning of this year trying to set it up 
so that we could use it seriously. I wanted to be able to do a twice yearly 
update from CPAN of all our modules into a seperate directory structure so that 
it would be easy to revert if the updated tree turned out to  contain a bug.
 
  local::lib plays nicely with cpan but not with cpanplus. The default way for 
a Catalyst app to maintain it's dependencies is to maintain Makefile.PL. When 
you run that it uses cpanplus. I struggled with it for quite a while and gave 
up.
 
  All the best.
  
 On Wed, May 13, 2015 at 6:26 PM, Robert Brown r...@intelcompute.com wrote:
 
  Not to answer your actual question, but...
 
 Have you also thought using Perlbrew http://perlbrew.pl
 
 As regular user, you can install any version of Perl locally (to your home 
dir), plus all the modules via cpanm, and keep everything self-contained for a 
particular user.
 
 It's made our deployments a breeze, rather than dealing with the system-wide 
perl, etc.
 
 (There's also local::lib tho I've not delved into that myself).
 
 Hope it helps a little.
 
 Rob
 
 
 On 13/05/15 18:16, Duncan Garland wrote:
  
Hi,
 
  I've just spun up a Rackspace server with Ubuntu 14.04 and tried to install 
Catalyst from CPAN.
 
  If the print out means what it seems to mean, then Catalyst will no longer 
install cleanly from CPAN on any version prior to 5.20.
 
  It's saying that there is a dependency on Tie::StdHash and that Tie::StdHash 
won't install without force because the latest version of the module is part of 
perl-5.20.2.
 
  It won't effect me because I'll just force it or download an older version of 
the module.
 
  All the same, it seems a bit poor.
 
  Is it deliberate?
 
  Regards
 
  Duncan
   
 
  
 The information contained in this message is for the intended addressee only 
and may contain confidential and/or privileged information. If you are not the 
intended addressee, please delete this message and notify the sender; do not 
copy or distribute this  message or disclose its contents to anyone. Any views 
or opinions expressed in this message are those of the author and do not 
necessarily represent those of Motortrak Limited or of any of its associated 
companies. No reliance may be placed on  this message without written 
confirmation from an authorised representative of the company. 
 Registered in England 3098391 V.A.T. Registered No. 667463890 
  
 ___
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/
 
 
  
  
 The information contained in this message is for the intended addressee only 
and may contain confidential and/or privileged information. If you are not the 
intended addressee, please delete this message and notify the sender; do not 
copy or distribute this message or disclose its contents to anyone

Re: [Catalyst] Rackspace Ubuntu 14.04

[John Napiorkowski]

I'd love to see a full install attempt.  I was getting tests for Perl down to 
5.8.8 before we release so I am not aware of a hard dependency on Tie::StdHash.
However I don't use cpanplus, and I write my own makefile.pl, not the one that 
Catalyst::Devel writes.  Its possible that something is going on there.  If 
someone can reproduce and send me an install trace I will review.
The intention for Catalyst is to run on the oldest Perl possible.  However I am 
finding particularly with the unicode stuff that getting a stable setup lower 
than 5.14 is a bit hard.  I do use 5.10.1 at work and we have it running there 
without trouble FWIW
John  


 On Wednesday, May 13, 2015 2:23 PM, Robert Brown r...@intelcompute.com 
wrote:
   

  Interesting, we don't use local::lib, just perlbrew, both dev and production, 
and keep the whole perlbrew dir in svn, works great.
 
 Will let the catalyst devs answer the actual/original question...
 
 
 On 13/05/15 19:01, Duncan Garland wrote:
  
  Hi,
 
  We don't use perlbrew on production, but I've used it in other areas without 
a problem. As far as I know it's very highly regarded.
 
  I've used local::lib successfully for development work ie Temporarily 
pointing to some different modules.
 
  I spent quite a lot of time at the beginning of this year trying to set it up 
so that we could use it seriously. I wanted to be able to do a twice yearly 
update from CPAN of all our modules into a seperate directory structure so that 
it would be easy to revert if the updated tree turned out to  contain a bug.
 
  local::lib plays nicely with cpan but not with cpanplus. The default way for 
a Catalyst app to maintain it's dependencies is to maintain Makefile.PL. When 
you run that it uses cpanplus. I struggled with it for quite a while and gave 
up.
 
  All the best.
  
 On Wed, May 13, 2015 at 6:26 PM, Robert Brown r...@intelcompute.com wrote:
 
  Not to answer your actual question, but...
 
 Have you also thought using Perlbrew http://perlbrew.pl
 
 As regular user, you can install any version of Perl locally (to your home 
dir), plus all the modules via cpanm, and keep everything self-contained for a 
particular user.
 
 It's made our deployments a breeze, rather than dealing with the system-wide 
perl, etc.
 
 (There's also local::lib tho I've not delved into that myself).
 
 Hope it helps a little.
 
 Rob
 
 
 On 13/05/15 18:16, Duncan Garland wrote:
  
Hi,
 
  I've just spun up a Rackspace server with Ubuntu 14.04 and tried to install 
Catalyst from CPAN.
 
  If the print out means what it seems to mean, then Catalyst will no longer 
install cleanly from CPAN on any version prior to 5.20.
 
  It's saying that there is a dependency on Tie::StdHash and that Tie::StdHash 
won't install without force because the latest version of the module is part of 
perl-5.20.2.
 
  It won't effect me because I'll just force it or download an older version of 
the module.
 
  All the same, it seems a bit poor.
 
  Is it deliberate?
 
  Regards
 
  Duncan
   
 
  
 The information contained in this message is for the intended addressee only 
and may contain confidential and/or privileged information. If you are not the 
intended addressee, please delete this message and notify the sender; do not 
copy or distribute this  message or disclose its contents to anyone. Any views 
or opinions expressed in this message are those of the author and do not 
necessarily represent those of Motortrak Limited or of any of its associated 
companies. No reliance may be placed on  this message without written 
confirmation from an authorised representative of the company. 
 Registered in England 3098391 V.A.T. Registered No. 667463890 
  
 ___
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/
 
 
  
  
 The information contained in this message is for the intended addressee only 
and may contain confidential and/or privileged information. If you are not the 
intended addressee, please delete this message and notify the sender; do not 
copy or distribute this message or disclose its contents to anyone. Any views 
or opinions expressed in this message are those of the author and do not 
necessarily represent those of Motortrak Limited or of any of its associated 
companies. No reliance may be placed on this message without written 
confirmation from an authorised representative of the company. 
 Registered in England 3098391 V.A.T. Registered No. 667463890 
  
 ___
List: 

Re: [Catalyst] Error: You requested a stash, but one does not exist

[John Napiorkowski]

Johannes,
If you have time to add a note in the Upgrading.POD file, feel free to send a 
pull request ;) = perl-catalyst/catalyst-runtime 

 On Tuesday, February 24, 2015 5:12 AM, Johannes Kilian jo.kil...@gmx.de 
wrote:
   

 Hello John, On Monday, February 23, 2015, John Napiorkowski 
jjn1...@yahoo.com wrote:...The likely reason is that about 9 months ago the 
stash was moved to the middleware layer, which makes it context bound and you 
are asking for the stash in application scope  Yes - you are right. 
Completly forgot about this - while I stuck in developing on Perl 5.18/Catalyst 
5.8 until yesterday.The error was indeed still using stash within 
application scope. After moving all stash access from application scope into 
the controller scope (root controller) everything works again as expected. 
Thanks for your valueable hint. RegardsJohannes
___
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] Bug in old Advent example of async/websockets code?

[John Napiorkowski]

Last I checked it worked however there's no version of this in the catalyst 
test repo.  If you can help me figure out how to bake a test for this (even if 
it needs to be an optional developer only test) I'd greatly appreciate it. 

 On Sunday, February 22, 2015 7:09 PM, Toby Corkindale t...@dryft.net 
wrote:
   

 Hi,
I've been trying to replicate the use of WebSockets in Catalyst, by
following the example from the Advent calendar a year and a bit ago.
ie.
https://github.com/perl-catalyst/2013-Advent-Staging/blob/master/Websocket-Echo/lib/MyApp/Controller/Root.pm

In my experience, it isn't actually working properly -- I get the
Echo Initiated message, but then an instant disconnect.

Looking at the code, I'm highly suspicious of the $hd variable -- it
doesn't get stored anywhere, and according to the AnyEvent docs, I
think that means it will get DESTROYed once it goes out of scope. ie.
Immediately.

That fits the behaviour I'm seeing, although I think I've had it work
for me randomly at times as well, so...  I don't know.

I wondered if anyone here has thoughts on the matter?

Cheers,
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/


   ___
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] Bug in old Advent example of async/websockets code?

[John Napiorkowski]

try the code here: jjn1056/Perl-Catalyst-AsyncExample and let me know if that's 
busted, it would give me something to go on.
|   |
|   |  |   |   |   |   |   |
| jjn1056/Perl-Catalyst-AsyncExamplePerl-Catalyst-AsyncExample - maybe some 
sort of async with catalyst |
|  |
| View on github.com | Preview by Yahoo |
|  |
|   |

 ___
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] Error: You requested a stash, but one does not exist

[John Napiorkowski]

Johannes,
We're going to need a ton more info to help.  The likely reason is that about 9 
months ago the stash was moved to the middleware layer, which makes it context 
bound and you are asking for the stash in application scope.  We need to know 
stuff like what version you upgraded from and configuration info, etc.  How all 
the log trace looks up to the error is also needed.
Please review the changlog, upgrading and delta pods as well, since that might 
assist.
jnap 

 On Monday, February 23, 2015 3:14 AM, Johannes Kilian jo.kil...@gmx.de 
wrote:
   

 Hi there, I just set up a new virtual machine with WinServer 2012. I've 
installed Strawberry Perl 5.20.1 and installed all needed modules from CPAN. My 
Catalyst-Application starts up correctly (no error seen) as Catalyst Standalone 
Server. Trying to access via Webbrowser (http://localhost:3000) runs into an 
error: Caught exception in Engine: You requested a stash, but one does not 
exist at .\site\lib\Catalyst.pm line 517. The very same application runs 
without any complaints on my old VM (Win2003 Server, Strawberry Perl 5.18.0)  
Any ideas whats going wrong? Johannes
___
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] Where best to store database connection information?

[John Napiorkowski]

People do different things based on there setup.  I tend to use ENV vars and 
store them on the local server under /etc with a restricted account.  There's 
no official way to do this (we are not Rails :)). -jnap 

 On Monday, February 16, 2015 8:42 AM, Adam Witney awit...@sgul.ac.uk 
wrote:
   

 Hi,

I have a Catalyst / DBIx::Class application and I have been storing the 
database connection parameters in a config file which is sourced using 
MYAPP_CONFIG_LOCAL_SUFFIX. But this seems a bit of a security problem having 
the main password in a text file like this, especially if it goes into git.

Is there a recommended or best practice place to store database connection 
information?

Thanks for any help

Adam

___
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] last chance to test 5.90079_006

[John Napiorkowski]

Hey all,

I'm planning on making the current development release of Catalyst stable soon. 
 If you are testing or planning to test it shortly and would like me to wait 
please ask now. 

peace out,

jnap

___
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 5.90080 on CPAN!

[John Napiorkowski]

Hey All!

We just cut 5.90080 release to stable.

Get it = https://metacpan.org/release/JJNAPIORK/Catalyst-Runtime-5.90080

Info and overview = 
http://jjnapiorkowski.typepad.com/modern-perl/2015/01/perl-catalyst-590080-released-to-cpan.html

Enjoy and shout out if you see trouble!

jnap

___
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] Requirement to add for C::A::Serialize::JSON to not give Content-Type application/json is not supported

[John Napiorkowski]

For better or worse this distribution expects the user of it to add 
dependencies for the types they want to handle.  Otherwise we'd end up making 
people install dependencies for types they might not want.  It would make a 
good note in the docs somewhere (unless they are already around... I just could 
not find them).
FWIW if you are just doing basic JSON POST/GET stuff you might be interested to 
know that newer Catalyst supports that out of the box.  I find the build in 
stuff + Catalyst::View::JSON is enough for the basic JSON API needs I tend to 
have.  SO unless you need all the power of the REST package you might want to 
skip it.
jnap 

 On Friday, December 26, 2014 12:48 PM, Octavian Rasnita 
orasn...@gmail.com wrote:
   

 Hello and... Marry Christmas!

I tried to use Catalyst::Controller::REST, but it returned the error 
Content-Type application/json is not supported..

I've seen that somehow I had the module Catalyst::Action::Serialize::JSON 
installed, so it should have been working.
I checked its source code and I've seen that it uses the module 
JSON::MaybeXS, but I didn't have that module.
I installed it and now it works fine.

This is just a note that may be helpful for others that may have this 
problem.
Also maybe JSON::MaybeXS will be added as a requirement for 
Catalyst::Action::Serialize::JSON.

--Octavian


___
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] Development release 004 on CPAN

[John Napiorkowski]

Hey All,

Dev004 is on CPAN, I've blogged details =  
http://jjnapiorkowski.typepad.com/modern-perl/2014/12/perl-catalyst-590079-development-004-holland-on-cpan.html

I know I keep saying this is a dev release to test, but I am going to be really 
mad and discouraged if after this is live Jan 28 and a bunch of people tell me 
it busts their code.  I'm likely to say, Patches welcomed...

Happy Holidays, etc.

jnap

___
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::Request::Upload-filename is not decoded.

[John Napiorkowski]

Any chance you can test this on the current dev release on CPAN?  There's a ton 
of utf8 fixes there.  
Catalyst-Runtime-5.90079_003 - The Catalyst Framework Runtime - metacpan.org

|   |
|   |   |   |   |   |
| Catalyst-Runtime-5.90079_003 - The Catalyst Framework Runtime - 
metacpan.orgThe Catalyst Framework Runtime |
|  |
| View on metacpan.org | Preview by Yahoo |
|  |
|   |


If trouble remains, I'd love an issue or ideally a test case.  There's a big 
UTF8 test case over here

perl-catalyst/catalyst-runtime

|   |
|   |  |   |   |   |   |   |
| perl-catalyst/catalyst-runtimecatalyst-runtime - The Elegant MVC Web 
Application Framework |
|  |
| View on github.com | Preview by Yahoo |
|  |
|   |

  Take a look and let me know if we need  more here.  The file upload stuff is 
something that is a bit confusing to me that I got it all correct 

 On Wednesday, December 17, 2014 7:22 PM, Bill Moseley mose...@hank.org 
wrote:
   

 All my upload forms have accept-charset=utf-8.    We expect that uploaded 
filenames could have wide-characters.
The problem I hit was -basename does this:
$ perl -le 'use Catalyst::Request::Upload; my $upload = 
Catalyst::Request::Upload-new( { filename = q[документ обучения.pdf] } ); 
print $upload-basename;'_.pdf
That's pretty mangled.

The problem is that $upload-filename is not decoded so the substitution is 
working on octets not characters. 

sub _build_basename {    my $self = shift;    my $basename = $self-filename;   
 $basename =~ s|\\|/|g;    $basename = ( File::Spec::Unix-splitpath($basename) 
)[2];    $basename =~ s|[^\w\.-]+|_|g;    return $basename;}

Obviously, we want \w to work on characters, not encoded octets.   Decoding the 
filename should be done -- it's character data.
Does it make sense to do it in Engine's prepare_uploads?
For example:
            my $u = Catalyst::Request::Upload-new(               size = 
$upload-{size},               type = scalar $headers-content_type,           
    headers = $headers,               tempname = $upload-{tempname},         
      filename = $c-_handle_unicode_decoding($upload-{filename}),            
);

-- 
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] Catalyst::Request::Upload-filename is not decoded.

[John Napiorkowski]

actually you might need to checkout and test the holland branch HEAD, there's 
fixes around that are not on CPAN -jnap 

 On Friday, December 19, 2014 11:15 AM, John Napiorkowski 
jjn1...@yahoo.com wrote:
   

 Any chance you can test this on the current dev release on CPAN?  There's a 
ton of utf8 fixes there.  
Catalyst-Runtime-5.90079_003 - The Catalyst Framework Runtime - metacpan.org

|   |
|   |   |   |   |   |
| Catalyst-Runtime-5.90079_003 - The Catalyst Framework Runtime - 
metacpan.orgThe Catalyst Framework Runtime |
|  |
| View on metacpan.org | Preview by Yahoo |
|  |
|   |


If trouble remains, I'd love an issue or ideally a test case.  There's a big 
UTF8 test case over here

perl-catalyst/catalyst-runtime

|   |
|   |  |   |   |   |   |   |
| perl-catalyst/catalyst-runtimecatalyst-runtime - The Elegant MVC Web 
Application Framework |
|  |
| View on github.com | Preview by Yahoo |
|  |
|   |

  Take a look and let me know if we need  more here.  The file upload stuff is 
something that is a bit confusing to me that I got it all correct 

 On Wednesday, December 17, 2014 7:22 PM, Bill Moseley mose...@hank.org 
wrote:
   

 All my upload forms have accept-charset=utf-8.    We expect that uploaded 
filenames could have wide-characters.
The problem I hit was -basename does this:
$ perl -le 'use Catalyst::Request::Upload; my $upload = 
Catalyst::Request::Upload-new( { filename = q[документ обучения.pdf] } ); 
print $upload-basename;'_.pdf
That's pretty mangled.

The problem is that $upload-filename is not decoded so the substitution is 
working on octets not characters. 

sub _build_basename {    my $self = shift;    my $basename = $self-filename;   
 $basename =~ s|\\|/|g;    $basename = ( File::Spec::Unix-splitpath($basename) 
)[2];    $basename =~ s|[^\w\.-]+|_|g;    return $basename;}

Obviously, we want \w to work on characters, not encoded octets.   Decoding the 
filename should be done -- it's character data.
Does it make sense to do it in Engine's prepare_uploads?
For example:
            my $u = Catalyst::Request::Upload-new(               size = 
$upload-{size},               type = scalar $headers-content_type,           
    headers = $headers,               tempname = $upload-{tempname},         
      filename = $c-_handle_unicode_decoding($upload-{filename}),            
);

-- 
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] Catalyst::Request::Upload-filename is not decoded.

[John Napiorkowski]

actually you might need to checkout and test the holland branch HEAD, there's 
fixes around that are not on CPAN 
and it looks like filename is right but baseman is using a regexp that is not 
unicode friendly.  I'll take a look
jnap 

 On Friday, December 19, 2014 11:15 AM, John Napiorkowski 
jjn1...@yahoo.com wrote:
   

 Any chance you can test this on the current dev release on CPAN?  There's a 
ton of utf8 fixes there.  
Catalyst-Runtime-5.90079_003 - The Catalyst Framework Runtime - metacpan.org

|   |
|   |   |   |   |   |
| Catalyst-Runtime-5.90079_003 - The Catalyst Framework Runtime - 
metacpan.orgThe Catalyst Framework Runtime |
|  |
| View on metacpan.org | Preview by Yahoo |
|  |
|   |


If trouble remains, I'd love an issue or ideally a test case.  There's a big 
UTF8 test case over here

perl-catalyst/catalyst-runtime

|   |
|   |  |   |   |   |   |   |
| perl-catalyst/catalyst-runtimecatalyst-runtime - The Elegant MVC Web 
Application Framework |
|  |
| View on github.com | Preview by Yahoo |
|  |
|   |

  Take a look and let me know if we need  more here.  The file upload stuff is 
something that is a bit confusing to me that I got it all correct 

 On Wednesday, December 17, 2014 7:22 PM, Bill Moseley mose...@hank.org 
wrote:
   

 All my upload forms have accept-charset=utf-8.    We expect that uploaded 
filenames could have wide-characters.
The problem I hit was -basename does this:
$ perl -le 'use Catalyst::Request::Upload; my $upload = 
Catalyst::Request::Upload-new( { filename = q[документ обучения.pdf] } ); 
print $upload-basename;'_.pdf
That's pretty mangled.

The problem is that $upload-filename is not decoded so the substitution is 
working on octets not characters. 

sub _build_basename {    my $self = shift;    my $basename = $self-filename;   
 $basename =~ s|\\|/|g;    $basename = ( File::Spec::Unix-splitpath($basename) 
)[2];    $basename =~ s|[^\w\.-]+|_|g;    return $basename;}

Obviously, we want \w to work on characters, not encoded octets.   Decoding the 
filename should be done -- it's character data.
Does it make sense to do it in Engine's prepare_uploads?
For example:
            my $u = Catalyst::Request::Upload-new(               size = 
$upload-{size},               type = scalar $headers-content_type,           
    headers = $headers,               tempname = $upload-{tempname},         
      filename = $c-_handle_unicode_decoding($upload-{filename}),            
);

-- 
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] Catalyst::Request::Upload-filename is not decoded.

[John Napiorkowski]

ok so we can't change the existing baseman for backcompat, so we added a new 
raw_basename that I think should do what you want.  That will work its way to 
CPAN as dev004 shortly.  Holland is expected to become stable Jan 28, 2015
john
 

 On Friday, December 19, 2014 11:40 AM, John Napiorkowski 
jjn1...@yahoo.com wrote:
   

 actually you might need to checkout and test the holland branch HEAD, there's 
fixes around that are not on CPAN 
and it looks like filename is right but baseman is using a regexp that is not 
unicode friendly.  I'll take a look
jnap 

 On Friday, December 19, 2014 11:15 AM, John Napiorkowski 
jjn1...@yahoo.com wrote:
   

 Any chance you can test this on the current dev release on CPAN?  There's a 
ton of utf8 fixes there.  
Catalyst-Runtime-5.90079_003 - The Catalyst Framework Runtime - metacpan.org

|   |
|   |   |   |   |   |
| Catalyst-Runtime-5.90079_003 - The Catalyst Framework Runtime - 
metacpan.orgThe Catalyst Framework Runtime |
|  |
| View on metacpan.org | Preview by Yahoo |
|  |
|   |


If trouble remains, I'd love an issue or ideally a test case.  There's a big 
UTF8 test case over here

perl-catalyst/catalyst-runtime

|   |
|   |  |   |   |   |   |   |
| perl-catalyst/catalyst-runtimecatalyst-runtime - The Elegant MVC Web 
Application Framework |
|  |
| View on github.com | Preview by Yahoo |
|  |
|   |

  Take a look and let me know if we need  more here.  The file upload stuff is 
something that is a bit confusing to me that I got it all correct 

 On Wednesday, December 17, 2014 7:22 PM, Bill Moseley mose...@hank.org 
wrote:
   

 All my upload forms have accept-charset=utf-8.    We expect that uploaded 
filenames could have wide-characters.
The problem I hit was -basename does this:
$ perl -le 'use Catalyst::Request::Upload; my $upload = 
Catalyst::Request::Upload-new( { filename = q[документ обучения.pdf] } ); 
print $upload-basename;'_.pdf
That's pretty mangled.

The problem is that $upload-filename is not decoded so the substitution is 
working on octets not characters. 

sub _build_basename {    my $self = shift;    my $basename = $self-filename;   
 $basename =~ s|\\|/|g;    $basename = ( File::Spec::Unix-splitpath($basename) 
)[2];    $basename =~ s|[^\w\.-]+|_|g;    return $basename;}

Obviously, we want \w to work on characters, not encoded octets.   Decoding the 
filename should be done -- it's character data.
Does it make sense to do it in Engine's prepare_uploads?
For example:
            my $u = Catalyst::Request::Upload-new(               size = 
$upload-{size},               type = scalar $headers-content_type,           
    headers = $headers,               tempname = $upload-{tempname},         
      filename = $c-_handle_unicode_decoding($upload-{filename}),            
);

-- 
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/

[Catalyst] Call for Mailing List Community Manager

[John Napiorkowski]

Hey All,
So lately I've not done such a great job of mirroring important announcements 
like the start of Advent, information about the  current development release 
(or stable releases, etc.) over to the mailing list. Mostly my time is a bit 
limited and also I just find that I don't use email as much as I used to.  As a 
result I end up logging into email just to check the ML now, which is not so 
frequent where before I'd check it when I was checking my regular email on a 
daily or several times a day basis.
Although the list is pretty low traffic I think there are likely some of you 
that cannot log into IRC all the time to keep up with stuff so it would be 
great if the important things did get announced here.  As a result I am looking 
for someone to volunteer for 2015 to be the mailing listing community 
representative.
This is not a big job.  All you need to be is someone that is regular on IRC 
and willing to monitor my blog and relay the big stuff like releases of 
catalyst to CPAN, start of Advent (call for submissions, etc.)  You can do more 
with it if you want but it really could be as few as 10 emails or less a year.  
I also don't expect heavy deadlines, just if sometime is announce if it could 
be relayed here to the ML within a few days that's totally fine.  You can find 
old release announcements in the ML history and use that for a template.
Ideally there would be two people in case someone is away or possible to take 
turns so that its less work.  If you are willing to do this for 2015 please let 
me know.  I'd like to keep the ML abreast of stuff for people that can't hit 
IRC.  I think its reasonably important.  Thanks!
--Jnap
___
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] Perl equivalent to Java PrimeFaces - Reaction...?

[John Napiorkowski]

I believe that the Reaction project founder felt the project did not meet its 
initial goals a number of years ago and switched to other projects.  I think 
there's some people doing life support on it that have it on in house apps but 
I don't think this a project that is moving forward.  Its got a lot a great 
ideas I think and I am hoping to see some of those trickle down into catalyst 
is ways varied.
RapidApp is probably the closet thing to a project along Reaction lines.  I 
don't know of anything that is doing what Primefaces is trying (and in my 
opinion mostly failing) to do.  I think what most of us are doing when we have 
cross UI needs is to build a backend web service and then build the various 
bits on that (for example a website and an iPhone app could share the same or 
nearly the same web service.  That way each type of application is coded in the 
best way instead of trying to build one set of user interface code and have it 
work for all target UIs.  Personally its not my approach because I find it is 
not satisfactory but you know your own business needs.
You might want to see if anyone is doing stuff with XUL, which is a cross 
target UI built with HTML and so forth that Mozilla uses.   I think its cool 
stuff but I don't think its caught on beyond the stuff mozilla does.
best of luckjnap 

 On Saturday, December 6, 2014 9:00 AM, Jorge Gonzalez 
jorge.gonza...@daikon.es wrote:
   

 Hi listers,

I've been searching lately for a Perl equivalent of Java PrimeFaces.  
For those who do not know about it, it's a layer on top of a basic web  
framework, intended to build web applications with the same concepts  
as Desktop apps, i.e. high level controls (tables, tree lists,  
buttons, forms etc.), heavy AJAX use, and lots of automatic code  
generation for controllers which react to the AJAX events and requests.

A framework like this for Perl would use Catalyst as a web backend,  
but would be built on top of it as higher level of app development.

I think Reaction builds on this concept, but:

a) It has not been updated in 3 years

b) I have been able to build a basic web app with it, but I haven't  
found a complex example application and UI themes or directions on  
integrating it with client side libraries like jQuery or Bootstrap.

c) Searching about Reaction on the web gave me really, _really_ poor  
results, which leads me to suppose that there are really no good  
resources appart from the very basic info in the tutorial and the PODs.

Is Reaction an abandoned project? Are there any Perl Primefaces  
equivalents out there?

Any ideas?
TIA
Jorge

-- 
Jorge Gonzalez
CTO, DAIKON Ingenieria de Sistemas







___
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] Catalyst Advent Calendar 2014

[John Napiorkowski]

good ideas to do if you need help
- take any old articles from older advents that are good but need a modern 
refresher- talk about how you use Catalyst on your job- take some POD docs from 
the core distribution and expand on it- take some docs form a module you use 
(like a plugin) and expand on it
Don't worry too much or overthink it!  50 - 75 lines of POD is enough.
Thanks all!
jnap 

 On Friday, December 5, 2014 4:00 AM, Duncan Garland 
duncan.garl...@motortrak.com wrote:
   

 That's 5 by John N and one by you. John blogged that he could do 10. That 
leaves us 20 short.

I haven't done much new stuff on Catalyst this year. I did use ZOMG for 
something. I could look to see if the article on JFDI needs updating and, if it 
does, write a few lines. I'm not going to have any spare time until 20 Dec, so 
it would have to go right at the end.

Other than that, I haven't got any ideas.

On Fri, Dec 5, 2014 at 9:35 AM, David Schmidt davew...@gmx.at wrote:

6 articles have been committed so far

http://dev.catalystframework.org/repos/Catalyst/trunk/examples/CatalystAdvent/root/2014/

On 5 December 2014 at 10:16, Duncan Garland
duncan.garl...@motortrak.com wrote:
 John N published an appeal for help a few days ago.

 http://blogs.perl.org/users/john_napiorkowski/2014/12/catalyst-advent-2014.html

 Is the situation under control now or are we still very short of articles?



 The information contained in this message is for the intended addressee only
 and may contain confidential and/or privileged information. If you are not
 the intended addressee, please delete this message and notify the sender; do
 not copy or distribute this message or disclose its contents to anyone. Any
 views or opinions expressed in this message are those of the author and do
 not necessarily represent those of Motortrak Limited or of any of its
 associated companies. No reliance may be placed on this message without
 written confirmation from an authorised representative of the company.

 Registered in England 3098391 V.A.T. Registered No. 667463890

 ___
 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/



The information contained in this message is for the intended addressee only 
and may contain confidential and/or privileged information. If you are not the 
intended addressee, please delete this message and notify the sender; do not 
copy or distribute this message or disclose its contents to anyone. Any views 
or opinions expressed in this message are those of the author and do not 
necessarily represent those of Motortrak Limited or of any of its associated 
companies. No reliance may be placed on this message without written 
confirmation from an authorised representative of the company.
Registered in England 3098391 V.A.T. Registered No. 667463890
___
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] Help on Catalyst::Plugin::RunAfterRequest

[John Napiorkowski]

Although that plugin might have some convenience value for development, I can't 
see using it for real work.  If you need to process long running tasks your 
best best is a job queue.   You can setup one or use one of many available 
infrastructure as a service systems. (see Iron.io. etc)

jnap


On Monday, October 6, 2014 8:53 AM, Antonio Soro antonio.s...@koinesistemi.it 
wrote:
 


Hello,
I plan to run server code in asynchronous mode after a response back to the
client made from an action code in a Catalyst controller.

I'm using Catalyst::Plugin::RunAfterRequest plugin in a Catalyst 5.80
environment started in 'FastCGI' mode, called by Apache2 httpd server, with
FastCgiExternalServer directive of mod_fastcgi.c module (v2.4.6), in a Linux
UBUNTU box with Perl 5.12.4.

It seems, in that environment, response for client request occurs after long
time processing, differently that I run Catalyst Runtime in 'Server' mode
where response back to the client occurs immediately and long time processing
occurs delayed. 

Can somebody tell me this behavior is correct or there is something wrong?
Are there better methods to call long-time-running code across
Apache/FastCGI/Catalyst ?

Thanks for feedback.
Antonio Soro.

---
Questa comunicazione e ogni eventuale file allegato sono confidenziali 
e destinati all'uso esclusivo del destinatario. Se avete ricevuto 
questo messaggio per errore Vi preghiamo di comunicarlo al mittente e 
distruggere quanto ricevuto.


___
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] New Development Branch Holland for Perl Catalyst now open

[John Napiorkowski]

Hey all!,

One more real Catalyst release this year?  Wanna help?  Here's the blog post

http://jjnapiorkowski.typepad.com/modern-perl/2014/09/new-perl-catalyst-development-branch-holland-now-open.html

Thanks!

jnap

___
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] Announcing 5.90070 release to CPAN

[John Napiorkowski]

Hi everyone!

Yesterday I cut the 5.90070 version of catalyst and send it along to CPAN.  
Since it seems to be stable after 24 hours I am officially announcing that it 
is ready for you to download and start using.

I've also blogged about some of the changes:

Catalyst 5.90070 has Landed! - Modern Perl

  
             
Catalyst 5.90070 has Landed! - Modern Perl
Morning Catalyst Programmers and Users! I'm pleased to announced that the 
current development branch of Catalyst has been deemed stable and ready for 
use. This re...  
View on jjnapiorkowski.typepa... Preview by Yahoo  
  

As a side note, I've been getting various reports of issues with Unicode.  I'm 
not a unicode foomaster and could really use someone who is to help poke / prod 
the code a bit and help me get it figured out.  Just give me a shout.

Jnap
___
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] New Catalyst Releases

[John Napiorkowski]

Howdy!

There's been a few updates to Catalyst on CPAN recently, and I've blogged about 
it here: 

Catalyst Development and Stable Releases: Current Summary - Modern Perl
 
   Catalyst Development and Stable Releases: Current Sum...
Howdy Catalyst Lovers! Here's a quick update on things that have been happening 
with Catalyst recently. On the stable branch we've had a bunch of updates to 
impr...  
View on jjnapiorkowski.typepa... Preview by Yahoo  

There's still plenty left to do before we start to kick back and think about 
what Advent 2014 should look like, so lets see if we can move things closer to 
a place where a Catalyst 6 seems possible!

jnap___
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 release and new documentation project

[John Napiorkowski]

Hi Catalyst Developers!

You might have noticed a new dev release of Catalyst is on CPAN: 
Catalyst-Runtime-5.90069_001 - The Catalyst Framework Runtime - metacpan.org
 
 Catalyst-Runtime-5.90069_001 - The Catalyst Framework Runtime - metacpan.org
The Catalyst Framework Runtime  
View on metacpan.org Preview by Yahoo  

This is a modest first release in the Ancona series that introduces some 
changes to how Catalyst logger works. If you've run into issues setting up the 
logger you might want to take a look.  There's also some bug fixes and 
documentation improvements.

Additionally I've cut a repository for a new documentation project, which I've 
also blogged about:

Perl Catalyst - Concepts, Components and (use) Cases. - Modern Perl

 
   Perl Catalyst - Concepts, Components and (use) Case...
Howdy All, One of the main ongoing themes of discussion around Perl Catalyst is 
to determine a mid to long term roadmap for where the platform is goin...  
View on jjnapiorkowski.typepa... Preview by Yahoo  

Please take a look and help me shape the direction of the documentation 
project, so that it reflects the issues you find head scratching!

John (jnap) ___
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] HTTP headers returned from GET vs HEAD

[John Napiorkowski]

Content Length auto detection was moved from Catalyst core to middleware in a 
recent build of Catalyst.  Its likely that the view you are using isn't 
bothering to set the length and the middleware is failing to provide it 
properly since the Head middleware has already removed it.

Since the content length SHOULD be provided for the case of HEAD, could you 
provide a test case and lets see if shuffling the order of the registered 
middleware fixes this problem?

There's a method called 'registered_middlewares' in Catalyst.pm that dictates 
the order.  If you can provide me a failing test case in the repo 
(https://github.com/perl-catalyst/catalyst-runtime) I am sure I could fix it 
pretty quick.

Sorry for the slow response, BTW, there's also middleware for the md5

Plack::Middleware::ContentMD5 - Automatically sets the Content-MD5 header on 
all String bodies - metacpan.org

 
 Plack::Middleware::ContentMD5 - Automatically sets the Content-MD5 header on 
all String bodies...
Automatically sets the Content-MD5 header on all String bodies  
View on metacpan.org Preview by Yahoo  

I could be talked into adding that as well, although maybe not everyone wants 
the overhead.

Any thoughts on that?  --jnap
On Wednesday, April 23, 2014 6:50 PM, Trevor Leffler tleff...@uw.edu wrote:
 
I've been playing with a toy application and inspecting its responses to 
various HTTP methods and noticed that Content-Length is missing from the 
HEAD response.  Both Catalyst::Action::RenderView and C::A::Serialize 
(from the C::A::REST package) seem to take the easy way out and return 
1 if $c-req-method eq 'HEAD'.  Does anyone with CAR history know why 
this is?

To provide message-body-based headers (content-length, last-modified, 
content-md5, etc) I'm doing this:

sub render : ActionClass('RenderView') { }

sub end : Private {
   my $self = shift;
   my ($c) = @_;

   $c-forward('render');

   # see also Catalyst::Action::RenderView or ::Serialize
   if ($c-req-method eq 'HEAD') {
     my $view = $c-view
       || die sprintf(%s could not find a view to forward to.\n, 
__PACKAGE__);
     $c-forward($view);
   }

   # fun with headers, for example...
   # or enable P::M::ContentMD5
   if ($c-res-has_body) {
     my $md5 = Digest::MD5::md5_hex($c-res-body);
     $c-res-headers-header(Content-MD5 = $md5);
   }
}

I've noted that while $c-res-body now has my rendered view, it gets 
removed by Plack::Middleware::Head prior to returning the response, so I 
don't have to worry about that detail.

--Trevor

___
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] HTTP headers returned from GET vs HEAD

[John Napiorkowski]

Hey,

So when I was looking at this it seemed to me the order of the middleware stack 
was correct, so I wrote a quick test case:

https://github.com/perl-catalyst/catalyst-runtime/blob/master/t/head_middleware.t


and it does seem to me that this works as desired (if you have an action that 
provides a body content, but hit it with a HEAD request, then the body gets 
removed by the Head middleware but not before the ContentLength middleware has 
time to calculate the missing content length header.  Here's the current 
middleware stack for the most recent release of Catalyst:

          Plack::Middleware::HTTPExceptions-new,
          Plack::Middleware::RemoveRedundantBody-new,
          Plack::Middleware::FixMissingBodyInRedirect-new,
          Plack::Middleware::ContentLength-new,
          Plack::Middleware::MethodOverride-new,
          Plack::Middleware::Head-new,

Middleware handles a response from the top down (and the request comes the 
other way, from the bottom up).  In fact I can make my test case fail by 
reversing the order of the Head and ContentLength middleware, so I am sure this 
is the case.  I'm adding this test case to the next release of catalyst to help 
and to help prevent regressions.

jnap
On Thursday, May 1, 2014 6:01 PM, John Napiorkowski jjn1...@yahoo.com wrote:
 
Content Length auto detection was moved from Catalyst core to middleware in a 
recent build of Catalyst.  Its likely that the view you are using isn't 
bothering to set the length and the middleware is failing to provide it 
properly since the Head middleware has already removed it.

Since the content length SHOULD be provided for the case of HEAD, could you 
provide a test case and lets see if shuffling the order of the registered 
middleware fixes this problem?

There's a method called 'registered_middlewares' in Catalyst.pm that dictates 
the order.  If you can provide me a failing test case in the repo 
(https://github.com/perl-catalyst/catalyst-runtime) I am sure I could fix it 
pretty quick.

Sorry for the slow response, BTW, there's also middleware for the md5

Plack::Middleware::ContentMD5 - Automatically sets the Content-MD5 header on 
all String bodies - metacpan.org

 
 Plack::Middleware::ContentMD5 - Automatically sets the Content-MD5 header on 
all String bodies...
Automatically sets the Content-MD5 header on all String bodies  
View on metacpan.org Preview by Yahoo  

I could be talked into adding that as well, although maybe not everyone wants 
the overhead.

Any thoughts on that?  --jnap
On Wednesday, April 23, 2014 6:50 PM, Trevor Leffler tleff...@uw.edu wrote:
 
I've been playing with a toy application and inspecting its responses to 
various HTTP methods and noticed that Content-Length is missing from the 
HEAD response.  Both Catalyst::Action::RenderView and C::A::Serialize 
(from the C::A::REST package) seem to take the easy way out and return 
1 if $c-req-method eq 'HEAD'.  Does anyone with CAR history know why 
this is?

To provide message-body-based headers (content-length, last-modified, 
content-md5, etc) I'm doing this:

sub render : ActionClass('RenderView') { }

sub end : Private {
   my $self = shift;
   my ($c) = @_;

   $c-forward('render');

   # see also Catalyst::Action::RenderView or ::Serialize
   if ($c-req-method eq 'HEAD') {
     my $view = $c-view
       || die sprintf(%s could not find a view to forward to.\n, 
__PACKAGE__);
     $c-forward($view);
   }

   #
 fun with headers, for example...
   # or enable P::M::ContentMD5
   if ($c-res-has_body) {
     my $md5 = Digest::MD5::md5_hex($c-res-body);
     $c-res-headers-header(Content-MD5 = $md5);
   }
}

I've noted that while $c-res-body now has my rendered view, it gets 
removed by Plack::Middleware::Head prior to returning the response, so I 
don't have to worry about that detail.

--Trevor

___
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] Announcing Quest list for the next Catalyst development cycle, Ancona

[John Napiorkowski]

Hey all,

I blogged about the quest list for the next release of Catalyst.  As usual 
feedback is desired.

http://jjnapiorkowski.typepad.com/modern-perl/2014/03/new-catalyst-development-branch-ancona-ready-for-commiters.html#.UzQfstzmM-Y


John___
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 and unicode: broken or I'm dumb?

[John Napiorkowski]

Hi,

The mailing list is not particularly active, you might wish to hang out on IRC 
(irc.perl.org#catalyst).

John



On Monday, March 24, 2014 8:37 AM, 疾驰者 78778...@qq.com wrote:
 
Hello everyone:
    For thirty days no mail? Why?
 
 
      Thai
___
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] utf8 on c-res-write or c-res-print

[John Napiorkowski]

On Friday, February 21, 2014 7:25 AM, Sergey Dmitriev 
sergey.program...@gmail.com wrote:

Thank you, it works! by using Encode::encode(UTF-8, 'my text' ).


And just for reference, if anyone will use it, HTTP headers should be set 
BEFORE calling write_fh.
e.g.
    $c-res-header( 'Cache-Control'  = 'public, max-age=600' ); 
    my $fh = $c-res-write_fh; # psgi writer, not filehandle


Otherwise headers will not be set.


===

Correct, once you call -write_fh OR -write on Response, we must finalize the 
headers. This is because the streaming interface can't stream a HTTP body 
without first sending HTTP headers.  By using -write/_fh you have chosen to 
bypass part of the Catalyst finalization process and talk more directly to the 
requesting client.

In newer versions of catalyst trying to set headers after requesting a write 
handler will generate an error.

--John

===


HtH, Sergey Dmitriev
All that is necessary for evil to triumph is for good men to do nothing. -- 
Edmund Burke



2014-02-20 18:53 GMT+04:00 Tomas Doran bobtf...@bobtfish.net:


On Feb 20, 2014, at 2:19 PM, Dmitry L. dim0...@gmail.com wrote:

    use utf8;

You shouldn’t need this unless you have actual utf8 characters (rather than 
escapes) in your source code.


    my $fh = $c-res-write_fh;
    my $test = \x{41f}\x{440}\x{43e}\x{431}\x{430};
    utf8::encode($test);

You probably actually want Encode::encode(‘UTF-8’, $test);


    $fh-write($test);

 On 20 February 2014 17:45, Sergey Dmitriev sergey.program...@gmail.com 
 wrote:
 Hello,

 I'm trying to put some utf8 strings as a part of Catalyst response as
 follows:


Right, you can’t do that :)

If you try to use the raw write interfaces you have to send bytes not 
characters (and so need to encode your utf8 character strings).


 $c-res-print ( ... )
 and
 $c-res-write( ... )

 line by line.

 However it dies with

   Wide character in syswrite at . IO/Handle.pm line 474

 Any ideas how can utf8 be written to response?

 E.g. set binmode on output handle. Cannot find how.
 Using Catalyst Runtime 5.90042.


This is not what you want to do.

The handle is already binary - just you’re not writing binary to it, you’re 
writing characters (and perl does not know how to translate those characters 
into bytes).

Cheers
Tom



___
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/

___
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] ProjectTaskToDo: open source project management system

[John Napiorkowski]

Bill,

Looks great, mind if I mention it on my blog?

John



On Saturday, February 15, 2014 3:30 PM, bill hauck wbha...@yahoo.com wrote:
 
Hi.

So I've finally gotten enough time to put out a version of my project 
management system, ProjectTaskToDo.

I've put the code out on GitHub at 
https://github.com/wbhauck/ProjectTaskToDo.git

I'm releasing it under the Affero GPL.  

It's beta software and some things don't work well, others don't work at all.  
I'm fixing bugs and cleaning code as quickly as possible.  But I wanted to post 
this now in the hopes that some folks might take a peek at it and give some 
suggestions and general feedback.

This is my first open source project so please be kind.  Be honest, but gentle. 
:)

Cheers,

bill
___
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] Announcing Perl Catalyst 5.90060 is on CPAN

[John Napiorkowski]

Hey All,

Here's my blog post: 
http://jjnapiorkowski.typepad.com/modern-perl/2014/02/perl-catalyst-runner-version-590060-now-on-cpan.htm

And the full, consolidated Changelog:

https://metacpan.org/changes/distribution/Catalyst-Runtime

Thanks!

Jnap

___
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] Announcing Perl Catalyst 5.90060 is on CPAN

[John Napiorkowski]

Thanks for the correction!  I might be trying to do too many things at once 
today! -jnap



On Monday, February 10, 2014 2:17 PM, Lance A. Brown la...@bearcircle.net 
wrote:
 
I had to put an 'l' on the end of that blog post URL.

--[Lance]


On 2014-02-10 1:32 pm, John Napiorkowski wrote:
 Hey All,
 
 Here's my blog
 post: 
 http://jjnapiorkowski.typepad.com/modern-perl/2014/02/perl-catalyst-runner-version-590060-now-on-cpan.htm
 


___
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] Perl Catalyst Dev 5 Runner on CPAN

[John Napiorkowski]

Hey Ya All,

I've cut development release 6 and sent it on the way to CPAN.  If this release 
turns out to be as stable as the dev 5 release, it will become the next stable 
version of Catalyst.  Items that remain on the Runner quest list are either 
small or things that might not be great to start on so close to the end of the 
development cycle (like the modperl changes).  Plus, I have to use mod_perl at 
work and not really inspired to hack on it in my spare time ;).

This version has small changes, as befit its age:

  - MyApp-setup now returns $app to allow class method chaining.
  - New Util helper functional localize $env to make it easier to mount PSIG
    applications under controllers and actions.  See Catalyst::Utils/PSGI 
Helpers.

Those last set of helpers exist to make it easier to localize the PSGI $env 
when you are using Catalyst as a sort of dispatcher to other PSGI apps (such as 
other Catalyst apps, or other).  The idea here is to make it easier to build 
your large Catalyst application as a collection of smaller apps, should you 
desire that.  with the new $c-req-from_psgi_response these helpers should 
make it easier.

Everything that's been said about this release making deeper changes to how the 
body is finalized of course still apply (along with moving some key bits to 
middleware).   This is the last chance you get to test Runner against your 
code.  There's great new stuff in this release that I am sure can enable you to 
do new and cool things with Catalyst, but if you can't upgrade because 
something broke, that's going to suck.

Assuming I hear of no showstoppers this will go 'gold' sometime in the next day 
or two.

jnap___
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] Random thoughts on helper class generation

[John Napiorkowski]

==JOHN

One of my reach goals for Catalyst6 is to have a separate project like 
Catalyst'Stack or some such that would be aimed at having more opinions and 
setup, to make it easier for newcomers to understand.  Ideally we'd have 3 or 4 
non trivial but understandable and well scoped example applications that would 
basically be the test cases for it and they'd be there to help people get 
started.  Volunteers very welcomed.

I'll try to spend more time blogging about internals.  I will say that the more 
I see other people stepping up to take on Catalyst quests (or suggesting solid 
ones and taking ownership of it) the more I will feel comfortable to spend time 
on docs.

I know it might seem hard to get started, but two years ago I felt pretty 
confused but I just took on some basic tasks and over time started to feel my 
away around.  If you put your mind to it, choose something and be willing to 
chew on it for a year or so and you will also pick up the code.  For me I 
wanted to see better support for async in Catalyst.  There was like 5 or 6 
branches all trying to do this in the repo but nothing ever got production 
ready.  It took a while but we now have something basic that works and didn't 
break back compat.  So find something about Catalyst that really bothers you 
and think about it.  Two bigger things that come to mind, if nothing on the 
quest list looks good to you, is some way to move forward on app/ctx split or 
migrating all the existing dispatch types to use chaining under th hood 
(there's code for this, t0m knows where it is, just never got enough testing).

The bigger the community of contribs are, the more information will get shared. 
 I know its hard for a lot of us since all the big brains have moved mostly on 
to other things, but we will just have to manage.  Its not going to be easy for 
the first bunch of us to figure all this out, but we can make it easier for the 
next group behind us and try to put Catalyst on a sustainable path were it 
remains relevant well into the future.

==/JOHN



On Thursday, January 30, 2014 6:33 AM, Craig Chant 
cr...@homeloanpartnership.com wrote:
I second Octavian's comments.

Though I still chose Catalyst over the other Perl frameworks, when you spend 
copious amounts of time reading docs and learning how to use the Catalyst 
framework, to then be questioned why you are doing something the way you are in 
the IIRC because it's wrong or at least outdated and not the best method, when 
all you are doing is following what the documentation tells you to do, is 
rather frustrating to say the least, and a waste of everyone's time... which 
then makes you wonder, how good other framework's documentation is and if that 
would be easier , simpler and more up-to-date.

It's not just the documentation / tutorials and how-to's either, it's even the 
error messages.

 Too bad that those people don't have the necessary time for that.

That doesn't cover the cryptic, poorly written error / warning messages!

There are clearly ridiculously clever people working on this project, but I 
feel sometimes they need to step back for a second and think... how could I 
explain this to a total idiot, verbose and verbatim documentation, error 
messages, tutorial and alike, are not the place for fiendishly clever one 
liners!

Catalyst has a big advantage over the other frameworks other than just being an 
awesome piece of software and that's the community; it's friendly , accessible 
and a pleasure to be involved in, it's littered with seriously talented 
individuals at the top of their game, working in huge corporations with a vast 
wealth of experience and technical know-how, but the documentation lets this 
down and it shouldn't.

Unless of course the goal of Catalyst isn't to make it accessible to the 
greenest of users regardless of their technical ability?


-Original Message-
From: Octavian Rasnita [mailto:octavian.rasn...@ssifbroker.ro]
Sent: 27 January 2014 09:25
To: The elegant MVC web framework
Subject: Re: [Catalyst] Random thoughts on helper class generation

From: neil.lunn n...@mylunn.id.au

 On 27/01/2014 1:27 PM, John Napiorkowski wrote:
 Neil,

 I know the problem we have here, but honestly I think the solution is going 
 to be more about having less stuff in Catalyst.pm rather than more...
 Hi John,

 Actually probably missed something in my intended context in the
 course of the rant.
 Couldn't agree more with that statement, truly less is more and I
 wasn't putting a shout out to either change 'Catalyst::Helper' or
 otherwise bloat things in 'Catalyst Core'. So I think we can agree
 that it is better to pull things out and delegate to more generic 
 add-in's.

 I have seen in some reading terms and statements such as monolithic
 catalyst application ..., which is sadly a sad misnomer and seems
 more of an indictment on the development model of the authors than an
 actual problem of Catalyst itself.

 That said, it doesn't help today

[Catalyst] New Development Release of the Next stable version of Catalyst on CPAN!

[John Napiorkowski]

Hi All!

I'm please to announce Development 5 of Perl Catalyst Runner.  This replaces 
dev4, which had some issues with incorrect minimum versions of some new 
dependencies and as a result was broadly un-installable.  Consolidated changes 
from the last development release:

5.90059_005 - 2014-01-28
  - Specify newested versions of some middleware in attempt to solve test errors
reported while installing.

5.90059_004 - 2014-01-27
  - Make sure IO handle objects do 'getline' before sending them to the
response callback, to properly support the PSGI specification.
  - Added some backcompat code when setting a response body to an object
that does 'read' but not 'getline'.  Added deprecation notice for this
case.  Added docs to Catalyst::Delta.
  - Catalyst::Delta contains a list of behaviors which will be considered
deprecated immediatelty.  Most items have workarounds and tweaks you can
make to avoid issues.  These deprecations are targeted for 
removal/enforcement
in the Catalyst 6 release.  Please review and give your feedback.
  - More middleware to replace inline code (upasana++)
  - Documentation around Exceptions and how we handle them.
  - update copyright notices.

I've blogged in more detail here regarding the status of Catalyst development, 
our progress in attaining our goals:

http://jjnapiorkowski.typepad.com/modern-perl/2014/01/perl-catalyst-runner-development-release-5-on-cpan.html

As mentioned in the blog we are getting near the end of the Runner development 
cycle, which is targeted to be released sometime in February.  Please take the 
time to review the proposed changes and submit issue reports, or you concerns 
and thoughts either here in the mailing list, on on IRC.

As always:

cpanm --dev Catalyst


Thanks!

Jnap

Github: https://github.com/perl-catalyst/
Code Repository: catag...@git.shadowcat.co.uk:Catalyst-Runtime.git
Questhub: http://questhub.io/realm/perl/explore/latest/tag/catalyst 

___
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] Random thoughts on helper class generation

[John Napiorkowski]

On Monday, January 27, 2014 3:25 AM, Octavian Rasnita 
octavian.rasn...@ssifbroker.ro wrote:
From: neil.lunn n...@mylunn.id.au

 On 27/01/2014 1:27 PM, John Napiorkowski wrote:
 Neil,

 I know the problem we have here, but honestly I think the solution is going 
 to be more about having less stuff in Catalyst.pm rather than more...
 Hi John,
 
 Actually probably missed something in my intended context in the course 
 of the rant.
 Couldn't agree more with that statement, truly less is more and I 
 wasn't putting a shout out to either change 'Catalyst::Helper' or 
 otherwise bloat things in 'Catalyst Core'. So I think we can agree that 
 it is better to pull things out and delegate to more generic add-in's.
 
 I have seen in some reading terms and statements such as monolithic 
 catalyst application ..., which is sadly a sad misnomer and seems more 
 of an indictment on the development model of the authors than an actual 
 problem of Catalyst itself.
 
 That said, it doesn't help today much :)  Feel free to try a plugin and see 
 what people think.  Is a good way to shakeout new ideas.
 So largely a position on how many people are generally cargo culting 
 the catalyst helper default files, which probably would have been a 
 better title. And otherwise trying to get a feel for what other people 
 were doing as typical, App, Controller, View, Model setups.
 
 As for the code, that was my way of saying here's one other way of 
 doing it, what's yours?
 
 If anything, the only critique here regarding the helper templates is 
 that new inductees are likely to come on board and just so things as 
 they are in the manual, without much thought to what is actually 
 happening. Hence the reference to getting logging set up under 
 ConfigLoader, and so we show another approach. But not sure exactly 
 what to do about making people think, and think differently, yet.



I think a better documentation for Catalyst *written by those who know the 
internals very well* would be very helpful to solve this problem.
Too bad that those people don't have the necessary time for that.

I think the fact that Catalyst has too much magic is a reason why most 
beginners prefer Dancer or Mojolicious.

Octavian


==JOHN

Ha, but I did try with this years catalyst advent to pull back the curtain, but 
its never bad to say more.  I think the key here is to focus on the good bits, 
and try to make it better (the way we interface with PSGI and all that).

That said, if we move toward a version 6, I'd probably spend some time 
discussing the general architecture and the design patterns around it.

Yeha, the helper templates are a bit long in the tooth.  I'd actually prefer a 
separate project for project builders, one that could be shared across 
frameworks and that would make it easy for people to share project templates, 
even on github for example.  There's like 10 of these of CPAN but obviously 
we've not hit the sweet spot yet, found the 'PSGI of project builders' since 
everyone still does their own thing.  Personally I just us bash myself.  One 
problem with the project builders is that it makes it easy to go to far and you 
end up with complex bunch of stuff only you understand.   my guess is that is 
the core of the problem.

I personally don't have time for any of the helpers, but if someone stepped up 
and wanted to modernize a bit I'd be happen to advise.  Otherwise I do have a 
side project for a project builder but not sure if its going to make sense for 
others as it does for me,

John

___
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] Random thoughts on helper class generation

[John Napiorkowski]

Neil,

I know the problem we have here, but honestly I think the solution is going to 
be more about having less stuff in Catalyst.pm rather than more... Ideally the 
application class would be a simple object rather than something that did a lot 
of setup and configuration stuff, something more like

(my $app = Catalyst::Builder
  -build(MyApp))-to_app;

Where the builder is responsible for reading any configuration and doing and 
inversion of control games to provide whatever the MyApp application needed to 
startup.  That way we separate the concerns and simplify the code.  Right now 
we often run into issues where the order of setup and configuration gets wonky. 
I think we can solve this with a standard design pattern,

That said, it doesn't help today much :)  Feel free to try a plugin and see 
what people think.  Is a good way to shakeout new ideas.

John



On Friday, January 24, 2014 8:42 PM, neil.lunn n...@mylunn.id.au wrote:
On 25/01/2014 10:58 AM, neil.lunn wrote:
 Hi all,

 Was just thinking through setting up various project minting files and 
 got to looking at the default Catalyst app layout from the helper. 
 Specifically I wondered how much the defaults were just being cargo 
 culted, and specifically addressing my dislike for overuse of inline 
 __PACKAGE__ calls when we have Moose and BUILD available. So random 
 musings below:

Oops. Big fail. Forgot the most important bit. See edit
 Here's a sensible base class for the App context:

 package Catalyst::BaseClass;
 use Moose;
 use namespace::autoclean;

 use Catalyst::Runtime 5.80;
 use Catalyst qw/ PluginLoader /;  # Should be all we need

 extends 'Catalyst';

 our $VERSION = '0.01';

 sub hook_config {
   my $self = shift;
   my $class = ref($self);

   # Set some basic defaults
   return {
     name = $class,
     enable_catalyst_header = 1,  # Send X-Catalyst header
   };
 }

 sub hook_logger {
   # Do nothing by default. Setup will take care of it.
 }

 sub BUILD {
   my $self = shift;
   my $class = ref($self);

      unless ( $self-setup_finished ) {
   # Setup Config
   $self-config(
     %{ $self-hook_config }
   );

   # Place a hook to hang a logger on before setup is called
   $self-hook_logger();

   $class-setup();

        }

 }

 As you can see by the hook methods, this was take 2  where I was 
 abstracting my personal cause from the general base class. By 
 placing the hooks in you can abstract in your application, as in:

 package YourApp::Web;
 use Moose;
 use namespace::autoclean;

 extends 'Catalyst::BaseClass';

 our $VERSION = '0.01';

 our $load_class = \Plack::Util::load_class;

 around 'hook_config' = sub {
   my $orig = shift;
   my $self = shift;
   my $class = ref($self);
   my $basename = $class;
   $basename =~ s/::.+//g;

   use Hash::Merge qw/merge/;

   # Setup Config
   my $configclass = $load_class-( ${basename}::Config );
   return merge( $self-$orig, $configclass-config || {} );

 };

 override 'hook_logger' = sub {
   my $self = shift;

   # Optional logger from class
   my $logger = $self-config-{Logger};
   if ( defined $logger ) {
     die Config Logger requires a Class key
       unless $logger-{Class};

     my $logclass = $load_class-( $logger-{Class} );
     $self-log( $logclass-new( @{ $logger-{Config} || [] } ) );

     $self-log-debug( qq/Initialized logger: $logclass/ );

   }

 };

 Now, realistically even the *second* and extended implementation is 
 still notably generic and *for me* this is even enough to place as a 
 *base class* to every application as this is how I will lay things 
 out. Plack::Util seems to be a fair assumption to be loaded as the end 
 result is a PSGI app, and Plack::Runner is going to pull this in. For 
 the nosy, the Logger class in this case is a mere wrapper around 
 Log::Log4perl in this case, and would only get the logger instance if 
 it had already been initialized. You can (and I do) set up Plack 
 middleware to do the same thing, making the same logger available to 
 other PSGI parts that might be used in your application, all without 
 needing to wrap context to get at the logger, or explicitly call 
 Log::Log4pperl::get_logger as we might just want to change that to a 
 different logger at some stage.

 So general thoughts are:
 1. Have a config class that is external to Catalyst logic. You can use 
 it elsewhere without hassle.
 2. Have a hook to hang that config on and get it early; because
 3. Hang a logger on a hook before 'setup' is called so you can get the 
 startup logging on debug
 4. Pull in the plugins from Config so there isn't a need to keep 
 modifying that code in the context class for every app

 Also minimising the selection of Plugins. I do try to keep this to 
 session and auth stuff for convenience, and again have these as just 
 thin layers over Plack Middleware. Other things can be delegated to 
 role applicator stuff, which I haven't typed in here.

 Anyone else have thoughts? Alternate favourite methods for layout?




 ---

[Catalyst] New Development Release on CPAN

[John Napiorkowski]

Hi All,

Yesterday I released the third development version of Catalyst 'Runner' on the 
heels of the second release just a few days ago.  This was needed because the 
second release had some debugging code left in it accidentally and was causing 
installation and testing fails for people that wanted to try out the new 
features.  My apologies.

Included with this bug fix is some additional documentation around using plack 
middleware and one new feature that allows one to use (or to mount a psgi 
application that uses) exception objects as described in the plack middleware

https://metacpan.org/pod/Plack::Middleware::HTTPExceptions


The idea is this middleware catches exception object that match an interface 
and uses them to provide content or behavior like redirection.  Ultimately I 
think all the custom error handling could move to middleware, including the 
default production and debug error pages.  This would get them out of the main 
code and let you customize the behavior without needing nasty plugins.  For 
this first iteration

Later on I plan to see what tools like might buy us.  I've always been a big 
fan of the lisp conditional approach but for now you can actually do like

  use HTTP::Throwable:: Factory;

  sub from_catalyst :Local {
    my ($self, $c) = @_;
    HTTP::Throwable::Factory-throw(MovedPermanently = { location = '/new' });

  }

and it works as expected.

So the hope here is to make it easier to customize and control default for the 
various types of error pages you use. 

As we add more middleware we are starting to approach the point where an array 
is no longer the best way to manage our included middlware.  Anyone out there 
have experience using Javascript Connect or the Rails MiddlewareStack can 
comment and help design a Sane API?

jnap___
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] New Development Release on CPAN

[John Napiorkowski]

Hi All,

Yesterday I released the third development version of Catalyst 'Runner' on the 
heels of the second release just a few days ago.  This was needed because the 
second release had some debugging code left in it accidentally and was causing 
installation and testing fails for people that wanted to try out the new 
features.  My apologies.

Included with this bug fix is some additional documentation around using plack 
middleware and one new feature that allows one to use (or to mount a psgi 
application that uses) exception objects as described in the plack middleware

https://metacpan.org/pod/Plack::Middleware::HTTPExceptions


The idea is this middleware catches exception object that match an interface 
and uses them to provide content or behavior like redirection.  Ultimately I 
think all the custom error handling could move to middleware, including the 
default production and debug error pages.  This would get them out of the main 
code and let you customize the behavior without needing nasty plugins.  For 
this first iteration

Later on I plan to see what tools like might buy us.  I've always been a big 
fan of the lisp conditional approach but for now you can actually do like

  use HTTP::Throwable:: Factory;

  sub from_catalyst :Local {
    my ($self, $c) = @_;
    HTTP::Throwable::Factory-throw(MovedPermanently = { location = '/new' });

  }

and it works as expected.

So the hope here is to make it easier to customize and control default for the 
various types of error pages you use. 

As we add more middleware we are starting to approach the point where an array 
is no longer the best way to manage our included middlware.  Anyone out there 
have experience using Javascript Connect or the Rails MiddlewareStack can 
comment and help design a Sane API?

jnap___
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] New stable and development versions on CPAN

[John Napiorkowski]

On Sunday, December 22, 2013 10:58 PM, neil.lunn n...@mylunn.id.au wrote:
On 23/12/2013 3:40 AM, John Napiorkowski wrote:
 There's a lot of weirdness in how the ConfigLoader plugin works, and it 
 causes a lot of hair pulling since it is a plugin and gets installed during 
 the 'setup_plugins' phase.  There's a couple of options, ranging from 'doing 
 something else' to hacking a special case where if this plugin is seen it 
 gets installed ASAP.  Thoughts and discussion welcomed.
The approach I've favored for a while is remove ConfigLoader and setup 
config via a custom class. Also allows loading config external of 
Catalyst. Like so:

__PACKAGE__-config(
   name = 'MyApp::FunnyIO::Web',
   # Disable deprecated behavior needed by old applications
   disable_component_resolution_regex_fallback = 1,
   enable_catalyst_header = 1, # Send X-Catalyst header
   %{ MyApp::FunnyIO::Config-config || {} }
);

Also just as a matter of current taste, I tend to inject log into the 
$app instance from new:

builder {

   my $app = MyApp::FunnyIO::Web-new;

   $app-log(
     Log::Log4perl::Catalyst-new(
       $app-config-{log}, autoflush = 1
     )
   );

   $app-apply_default_middlewares( $app-psgi_app );

};


---
Thanks Neil, I think a lot of people sometimes forget that the Catalyst object 
is really in the end just a class.  --jnap

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.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/


___
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] New stable and development versions on CPAN

[John Napiorkowski]

On Monday, December 23, 2013 9:19 AM, neil.lunn n...@mylunn.id.au wrote:

On 24/12/2013 1:20 AM, John Napiorkowski wrote:
 ---
 Thanks Neil, I think a lot of people sometimes forget that the Catalyst 
 object is really in the end just a class.  --jnap

I tend to generally agree that a lot of Catalyst::Plugin::* stuff is a 
giant bag of Blue meth that we all need to ween ourselves off of. 
Config structures and logging implementation are always best 
externalized along with general Domain logic with any application. By 
externalized I mean, outside the framework in a manner that they 
just work when implemented by themselves, without the framework's help.

At the risk of entering into a rant, I prefer a class factory approach 
to applying Roles/mixins to plain classes. Something that the Java 
POJO crowd got right.

--
I think ideally well have something like Catalyst::Application that just
has a new method, and maybe Catalyst::Builder or similar that does the
job of instantiating the application in a given context (configuration, etc.)
SO yeah, I think we need to think carefully about the approach of extending
stuff just by slapping a role over it.  Sometimes its correct but other times
it just causes confusion.  Moving more stuff into middleware is a goal for 
Runner and hopefully that will start to reduce the overall code bulk and let
use figure out the cleanest refactoring approach that doesn't kill backcompat

---


Keen to fix up a lot of this stuff. As simply moving ::Plugin* guff to 
applied roles, Probably code cahanges and new modules in preference to 
'Plugin', and Ideally having good DI on top of Catalyst. That is 
sensibly consumed. It would be nice to pull in config and service 
locators from something external and that was itself configuration file 
aware.

--
Regarding dependency injection, there's the long lost Bread::board branch
which I think has a lot of good stuff (and at least test cases).  I think
the approach I want to take here is to generalize what Catalyst wants from
A DI interface (probably start with just generalized what we do now, which
is like half a DI as it stands).  that way later on someone could just 
do an adaptor for the interface for BB.  I'm not currently sure that BB in
core is the correct long term approach since I am not 100% certain that Catalyst
will stay wedded to Moose (in core) over the term.  I was a big supporter of
the CataMoose project, but I also had an assumption that Perl would have core
MOP support by now to deal with some of the memory and speed issues.  Since that
looks like its now at least two years off give or take I think we should 
consider
alternatives if such ccan be done without breaking the bank.
--


BTW. Good work on the native file handle and psgi.streaming support, +If 
#miyagawa will patch up Plack::Util::content_length as suggested, then 
Catalyst in new release should work just the same as before but with new 
improvements and performance.

---
We need to write a test case and a proposed patch to help him along I think :)
If someone can do that I will go and push to get it included.

--john


Neil

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.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/

___
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] Plack::Middleware::ContentLength problem

[John Napiorkowski]

On Sunday, December 22, 2013 12:33 AM, neil.lunn n...@mylunn.id.au wrote:

On 22/12/2013 3:26 PM, neil.lunn wrote:

Not jumping around on this any longer. Changing
  Plack::Util::content_length seems to be the most sane answer.
'is_real_fh' does good for guarding against things that are not
  going to return a valid file descriptor, as would be requried by
  IO::AIO functions.

Hopefully the proposed change gets some traction and is accepted.
https://github.com/plack/Plack/issues/439


On 22/12/2013 7:47 AM, John Napiorkowski wrote:

The current HEAD of the runner branch actually has beta code that replaces the 
existing logic for calculating content length when its not set with this Plack 
middleware  (we also replace some custom logic to remove the content body when 
the request is HEAD with similar Plack middleware).  So this work is useful to 
help us shake out and improve the common middleware bits.
Was hoping that would be the case. Checked out the current HEAD of
  runner to confirm tests



Over the coming time I plan to move more and more custom code into middleware 
when it makes sense.  The goal is to reduce the amount of custom code in 
Catalyst and move some of the burden of maintenance onto the broader Plack 
community.
And hopefully other frameworks do the same so the Plack parts remain common.



However I am unclear what the failing cases is this example are...  Is is 
possible to contrive a failing case for the content length middleware we can 
bring to #plack / miyagawa?
Still working on something that solves but with some work I got a reproducible 
result on plain PSGI and also on the runner branch. The good news being I can 
get the ContentLength middleware to correctly report on the handle even under 
'runner'.

The not so good news is that first suspicions were right. As I had
  in a base test script, it is the order of Plack::Util loading that
  is the problem. To make the 'is_real_fh' function work in this
  case, I am overriding perl's built in 'fileno'. Problem being that
  the Plack::Util is being pulled in before the code that overrides
  the built in is being loaded. Thus the 'fileno' call within
  'is_real_fh' is still pointing to CORE. 

The reason is Plack::Runner as Plack::Util is in it's imports
  before parsing the content of a supplied *.psgi file in the
  arguments. If instead this is manually scripted (ie plain script
  invoking Plack::Runner) and the symbol table alteration is loaded
  first, well then all is okay.

Most deployments will probably use the *.psgi file to setup. So
  trying to find a way around this or otherwise have a different way
  to change symbol table. But mostly looking like chicken and egg
  stuff :)

Neil


___
Niel,

I'm reviewing the plack issue you created.  One thing though, in the future it 
should not be so important for a catalyst application to run via *.psgi since 
you can configure middleware and mount other applications directly.  The only 
cases where having a psgi file would be useful is when you want to tie together 
applications with shared behaviors when the applications are not really part of 
each other.  So if we have this working correctly under runner, that's pretty 
good I think!  Base on that I think this issue could belong to plack and we can 
hack on it over there.  Which is ultimately my goal, which is to reduce the 
amount of custom behavior in Catalyst so that we can share the development load.

John




I recommend anyone interested to start pulling from the HEAD of the runner 
branch if they want to play with it.  I want to ponder the best approach to 
using middleware for core app functionality (pondering how Rails middleware 
stack works, and looking at PlackX::MiddlewareStack for examples.)  Right now 
in HEAD the core middleware is just tacked onto the top of 
registered_middleware.  Thoughts on the best way to architect this are very 
welcome.  I see in the nearish future a good chuck of stuff that is in 
Catalyst.pm and related files moving into Middleware, possibly including the 
debugging screens, errors screens, etc.  In Rails and Django for example all 
that stuff is in middleware to make it easier for people to pull out and hack 
on it.


John



On Saturday, December 21, 2013 9:38 AM, Bill Moseley mose...@hank.org wrote:
 
On Fri, Dec 20, 2013 at 8:34 PM, neil.lunn n...@mylunn.id.au wrote:


 
My article today actually (http://www.catalystframework.org/calendar/2013/21), 
even though I'm actually talking here about the above case.



Just a note on the Advent article.


Thanks for writing that up.   It's a well-written article and clearly explains 
the issue I was facing and the fix you provided to me.  One thing I really 
like about the Advent articles is that I learn new ways to do things.   For 
example, I wasn't aware of namespace::sweep and never thought about overriding 
the -X filetests.   I just set the content length

[Catalyst] New stable and development versions on CPAN

[John Napiorkowski]

Today we released v5.90053, the latest stable Catalyst.  This release fixes a 
regression caused by the previous release that in some cases would cause 
trouble installing plugins that need access to the logger.

We also clarified how log configuration interacts with the general phases of 
Catalyst setup and added some documentation and workarounds in Catalyst::Delta 
for people that are trying to use the ConfigLoader plugin to configure a custom 
logger differently based on %ENV.

There's a lot of weirdness in how the ConfigLoader plugin works, and it causes 
a lot of hair pulling since it is a plugin and gets installed during the 
'setup_plugins' phase.  There's a couple of options, ranging from 'doing 
something else' to hacking a special case where if this plugin is seen it gets 
installed ASAP.  Thoughts and discussion welcomed.

Since this fixes a regression I consider it a required update.  At some point 
we will remove 5.90052 from CPAN since its broken.

As a result, we've also released the next development version of Catalyst, 
5.90059_002 which contains the regression fix (the 001 release has the 
regression).  This way people that want to test the development revisions of 
Catalyst can do so without having trouble with that regression.  This new 
development revision of Runner contains deeper changes to how the we connect 
Catalyst to PSGI, here's the full change log:

5.90059_002 - 2013-12-21
  - We now pass a scalar or filehandle directly to you Plack handler, rather
    than always use the streaming interface (we are still always using a
    delayed response callback).  This means that you can make use of Plack
    middleware like Plack::Middleware::XSendfile and we expect better use of
    server features (when they exist) like correct use of chunked encoding or
    properly non blocking streaming when running under a supporting server like
    Twiggy.  See Catalyst::Delta for more.  This change might cause issues if
    you are making heaving use of streaming (although in general we expect 
things
    to work much better.
  - In the case when we remove a content body from the response because you set
    an information status or a no content type status, warn that we are doing so
    when in debug mode.  You might see additional debugging information to help
    you find and remove unneeded response bodies.
  - Updated the code where Catalyst tries to guess a content length when you
    fail to provide one.  This should cause less issues when trying to guess the
    length of a funky filehandle.  This now uses 
Plack::Middleware::ContentLength
  - Removed custom code to remove body content when the request is HEAD and
    swapped it for Plack::Middleware::Head
  - Merged fix for regressions from stable..

So in addition to those deeper changes to better support streaming cases, we 
are starting to migrate custom Catalyst code to available Plack::Middleware.  
Right now that middleware is basically hard coded into the application, but we 
expect later releases to offer more control (perhaps something similar to the 
Rails MiddlewareStack).  

On thing that has come up is ambiguity about the case when an application is 
calling $response-write to custom stream a response, but later sets a 
$response-body anyway.  Right now we allow this but it would greatly simplify 
the code if we didn't (and right now its somewhat incorrect, in that we are 
forced to let Catalyst stream any file handles sent to the body.)  If anyone is 
using $res-write and needs to set the -body later please let me know.  I see 
some use cases for this but not many :)

Both new stable and new development should be on CPAN by the time you see this!

jnap

___
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 understand the relation of TT and dojo and Plack

[John Napiorkowski]

Thai,

Catalyst, unlike a framework like say Ruby on Rails, sits at the center of a 
number of other Perl technologies.  You named a few, such as Plack/PSGI, 
Template Toolkit, etc.  Others might include DBIx::Class for interfacing with a 
database.  And of course any number of testing tools on the Test::* namespace.  
As a result you have to put together a stack that makes sense to you, although 
one of the more common ones would be those mentioned.

Plack is an implementation of the PSGI specification, which connections a web 
application (such as Catalyst) to a web server, such as Nginx, Apache, Starman, 
etc.  This glue layer is reusable across many web frameworks, so we all work on 
it together for the betterment of all.  Plack also implements common middleware 
for concerns that are cross cutting, such as session and cookie management, 
authentication, etc.  Some web frameworks make heavy use of middleware, such as 
Web::Simple, while Catalyst tends to mix and match between middleware and 
pre-existing Catalyst specific components.  For example, Catalyst has its own 
mature session and authentication components, so we tend to use that rather 
than the Plack middleware (although over time I'd personally like to move 
towards using more middleware).

Template Toolkit (TT) is a templating system which is a common choice for a 
View layer in Catalyst.  It allows you a more cleanly expressive approach to 
the concern of how your web pages look.  Quite often you will use a Javascript 
framework, such as Dojo, Jquery or Angular.js to name a few of the ones I am 
personally familiar with.  Javascript will be integrated into the View (TT).  
Catalyst, unlike some web frameworks, doesn't offer a lot of Javascript code 
generation tools since most Perl programmers prefer a more hands on approach 
and write their Javascript manually.  Catalyst offers some tools for 
interacting with a Javascript application, such as support for JSON.  So using 
Javascript with Catalyst is totally fine, just as I said compared to some 
frameworks you might find yourself needing to write a bit more manual code.  As 
I said, Perl programmers tend to like to be 'close to the metal' so that is 
reflected in how Catalyst works.

I recommend you look at a few Catalyst applications on Github and review the 
tutorial if you can.



On Saturday, December 14, 2013 6:04 PM, 疾驰者 78778...@qq.com wrote:
 
Hi:
   Everyone!  I haven't get the all stack of Catalyst application.
   An application have so many functions. Some is done by some component, and 
some function can be done by application code.
   I have get the TT and dojo and Plack, may be. It will entry-level.

   Can anyone illustrate three concepts or terms? Especially there relations? 
For example, why should we use Plack, and not use old fastcgi?

--
FastCGI is great, and my first choice for production systems.  Plack implements 
PSGI and offers you a way to integrate a server such as FastCGI with your 
Catalyst web application.  It also lets you 'glue' that same application to a 
different server.  For example, many people use Starman as a server for 
development be cause its very easy to setup, but use something else in 
production (although Starman if run behind a proxy can be solid in production 
as well and some people choose that setup).

[client web browser] -- [Apache -- FastCGI] -- [Plack FastCGI Handler 
-- Catalyst -- DBIx::Class -- Database]

^^ is one example stack.  

Here's a great blog of someone that started with Catalyst from the start and he 
did his best to record the journey.  Maybe it will help you.

http://blogs.perl.org/users/j0e/

Also, I recommend reading the current and past Advent Calendars:

http://www.catalystframework.org/calendar/


   You are welcome!

Best of luck! --jnap


    Thai Heng

___
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] Perl Catalyst Quest list open for comments

[John Napiorkowski]

Hey All,

My proposals for the upcoming development cycle have been posted for review: 

http://questhub.io/realm/perl/explore/latest/tag/runner


More details on my blog:

http://jjnapiorkowski.typepad.com/modern-perl/2013/12/perl-catalyst-quests-for-winter-2013-14-development-cycle-runner-request-for-comments.htm


Thanks!

Jnap___
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] Non Blocking File Streaming - write_fh

[John Napiorkowski]

Neil,

You're the man!  Any change I could get this as a pull request on the github 
repo (is also the sane place I am asking people to submit articles)


https://github.com/perl-catalyst/2013-Advent-Staging

That way I am sure to get the code correct.

The only thing is that when using eval I prefer the following idiom as I think 
its a little safer

eval { ...; 1 } || die trouble: $!;

On the other hand since Catalyst already requires Try::Tiny no reason to just 
not use that.

John



On Friday, December 6, 2013 1:56 AM, neil.lunn n...@mylunn.id.au wrote:

Hi all, and mostly John,

I was just browsing through the upcoming Advent code examples when I saw 
the example for this had a bug. The code will die horribly when a call 
is made to HEAD rather than get as the output filehandle gets closed. 
The die is from an uncaught exception on $self-write.

My patch to MyApp::Stream :

sub read_chunk {
   my ($self, $fh, $offset) = @_;
   my $buffer = '';
   aio_read $fh, $offset, 65536, $buffer, 0, sub {
     my $status = shift;
     die read error[$status]: $! unless $status = 0;
     if($status) {
       eval {
         $self-write($buffer);
       };
       if ($@) {
         warn Cannot write, probably a closed pipe;
       }
       $self-read_chunk($fh, ($offset + 65536));
     } else {
       $self-close;
       aio_close $fh, sub { };
     }
   }
}

So the eval block and the warn, not die as this is not being caught 
under any other exception handler. Real world, YMMV. Not elegant, but 
would probably be better for passing in context.

Also I have a full Advent style writeup of the issue Bill brought up 
recently with explainations and solutions down to making the handle DWIW 
for for transparent handing over to Catalyst. If that is wanted/needed :)

Neil


---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.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/

___
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] In ActionRole is NotDoes Available?

[John Napiorkowski]

No this functionality not does exist.  

The best approach I think is to have more than one base controller or roles if 
you need that.

good luck, jnap



On Wednesday, December 4, 2013 11:36 PM, Sheeju Alex sheeju...@gmail.com 
wrote:
 
Hi All,
   
    I have applied some Action Roles to all the controllers to work without 
specifying Does keyword in every action function. Now I have a situation where 
I want NotDoes function so that I don't use one of the default Roles.

For Eg:



package MyApp::Controller::Bar
 
use Moose;
use namespace::autoclean;
 
BEGIN { extends 'Catalyst::Controller::ActionRole' }
 
__PACKAGE__-config(
action_roles = ['Foo', 'Bar'],
);
sub moo : Local { ... }


sub go : Path NotDoes('Foo') { ... }


Please let me know how can I do this?



Best Regards,     
Alex

___
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] Advent 2013 launched !!!

[John Napiorkowski]

dpetrov++



On Tuesday, December 3, 2013 6:09 AM, Carl Franks fireart...@gmail.com wrote:
 
That's great - thanks very much

On 3 December 2013 11:59, Dimitar Petrov mita...@gmail.com wrote:
 The problem should be fixed now and the only available articles should be
 displayed into the feed.

 Cheers


 On Tue, Dec 3, 2013 at 11:01 AM, Dimitar Petrov mita...@gmail.com wrote:

 That seems like the feed takes always the last 5 articles, so those
 articles are the one planned for 18,19,20 Dec.
 I have pushed a fix to display only the published entries and it should
 take effect soon.


 On Tue, Dec 3, 2013 at 10:06 AM, Carl Franks fireart...@gmail.com wrote:

 BTW, the XML feed seems to have a life of its own.
 Yesterday it listed an article which wasn't on the advent website
 (unfortunately, I forget what it was).
 Today the feed lists 3 copies of an article titled A LINUX WEEK IN
 THE LIFE OF A WINDOWS GUY! which again isn't on the advent site.
 http://www.catalystframework.org/calendar/feed/2013

 Carl

 On 2 December 2013 04:23, John Napiorkowski jjn1...@yahoo.com wrote:
  Hey all:
 
  I am pleased to announce that perl catalyst advent 2013 has launched!
 
  http://www.catalystframework.org/calendar/2013
 
  So far there are 15 articles in the queue and I have commits for a few
  more days but there is still opportunity for someone else to step up.  So
  get writing ( and reading )
 
  Sorry if there's some issue with article titles.  Small glitch which
  should resolve shortly.
 
  Jnap
 
  Sent from my iPhone
  ___
  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/




 ___
 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/___
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] Advent 2013 launched !!!

[John Napiorkowski]

Dimitar,

Thanks I was pressed for time a bit last night.  Was this a pod change or 
something else?  

Johnn



On Monday, December 2, 2013 2:22 AM, Dimitar Petrov mita...@gmail.com wrote:
 
I fixed the article names, thanks for spotting that.
Should be just fine now.

Cheers



On Mon, Dec 2, 2013 at 5:53 AM, Dmitry L. dim0...@gmail.com wrote:

Cool!
Just small thing: on the Articles List page all articles have title
Title lol:

Articles
Day 01: Title
Day 02: Title




On 2 December 2013 08:23, John Napiorkowski jjn1...@yahoo.com wrote:
 Hey all:

 I am pleased to announce that perl catalyst advent 2013 has launched!

 http://www.catalystframework.org/calendar/2013

 So far there are 15 articles in the queue and I have commits for a few more 
 days but there is still opportunity for someone else to step up.  So get 
 writing ( and reading )

 Sorry if there's some issue with article titles.  Small glitch which should 
 resolve shortly.

 Jnap

 Sent from my iPhone
 ___
 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/



--
//wbr, Dmitry L.


___
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/___
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] Advent 2013 launched !!!

[John Napiorkowski]

lol, I guess that's why the template was $title not TITLE.  And I made the 
exact same error last year.  Oh well!

I have a few people with stuff in progress or already in the queue for me to 
move to the calendar site.  The faster we fill the days the quicker I can move 
to prototyping what Catalyt6 could look like.

John



On Monday, December 2, 2013 7:37 AM, Dimitar Petrov mita...@gmail.com wrote:
 
Hey John,

yep. I made it as the the previous years

=head2 $title

instead of

=head2 Title

$title

I also fixed the link to the email address and now it seems like everything is 
fine. Respect for preparing the first 15 articles!




On Mon, Dec 2, 2013 at 2:16 PM, John Napiorkowski jjn1...@yahoo.com wrote:

Dimitar,


Thanks I was pressed for time a bit last night.  Was this a pod change or 
something else?  


Johnn



On Monday, December 2, 2013 2:22 AM, Dimitar Petrov mita...@gmail.com wrote:
 
I fixed the article names, thanks for spotting that.
Should be just fine now.


Cheers



On Mon, Dec 2, 2013 at 5:53 AM, Dmitry L. dim0...@gmail.com wrote:

Cool!
Just small thing: on the Articles List page all articles have title
Title lol:

Articles
Day 01: Title
Day 02: Title




On 2 December 2013 08:23, John Napiorkowski jjn1...@yahoo.com wrote:
 Hey all:

 I am pleased to announce that perl catalyst advent 2013 has launched!

 http://www.catalystframework.org/calendar/2013

 So far there are 15 articles in the queue and I have commits for a few more 
 days but there is still opportunity for someone else to step up.  So get 
 writing ( and reading )

 Sorry if there's some issue with article titles.  Small glitch which should 
 resolve shortly.

 Jnap

 Sent from my iPhone
 ___
 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/



--
//wbr, Dmitry L.


___
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/



___
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] Advent 2013 launched !!!

[John Napiorkowski]

Hey all:

I am pleased to announce that perl catalyst advent 2013 has launched!

http://www.catalystframework.org/calendar/2013

So far there are 15 articles in the queue and I have commits for a few more 
days but there is still opportunity for someone else to step up.  So get 
writing ( and reading )

Sorry if there's some issue with article titles.  Small glitch which should 
resolve shortly.

Jnap

Sent from my iPhone
___
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] Setting file handle as the response body generates warnings.

[John Napiorkowski]

On Wednesday, November 27, 2013 8:03 AM, neil.lunn n...@mylunn.id.au wrote:

On 27/11/2013 4:28 AM, John Napiorkowski wrote:

Awesome, send me a pull request :)


https://github.com/perl-catalyst/catalyst-runtime

John.
The pull is there along with another doc patch I noticed when
playing around with downstream PSGI invocations. I think the change
is sane as it worked for me in a trivial test.

What I mentioned regarding subclassing ( or rather what I tested was
more of a Moose delegation ) for such a class as
IO::Compress::Gunzip and applying an overload seems rather trivial,
though perhaps something people may come accross. Perhaps a doc
patch to Catalyst::Manual or an Advent entry just for documentation
sake. 

Also passing $c-res-body is something I have used on a few
occasions as something providing a write for streaming responses
(and possibly non blocking). So keen to share any thoughts re doing
this non-blocking for read on a future release. 

There's a few approaches, you can also access the $response-write_fh which 
returns the psgi $writer (see the PSGI docs for delayed and streaming 
responses. 


Should we really be documenting some of the newer catalyst features
in Cookbook? Or at least putting recipes in Advent . Event loop
things, response from PSGI and how about Pocket::IO seem relevant.

Advent will have a bunch of articles related to new features, and some stuff 
around web sockets. nonblocking.

If someone wants to port any of the web sockets examples to pocket.io or 
similar, for running on older browsers, that would be great.  If you know about 
pocket.io feel free to take a look over at the catalyst a-synch example 
repository on github : https://github.com/jjn1056/Perl-Catalyst-AsyncExample

Thanks!

john





   This email is free from viruses and malware because avast! Antivirus 
protection is active.  

___
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] Reminder: Perl Catalyst Advent 2013 starts Monday

[John Napiorkowski]

Hello Catalyst Developers!

Just a reminder that our Advent Articles start publishing this monday.  We have 
some contribution but not nearly enough to cover the month.  

Nows the time!

Get writing!

Johnn

___
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] Setting file handle as the response body generates warnings.

[John Napiorkowski]

Awesome, send me a pull request :)

https://github.com/perl-catalyst/catalyst-runtime




On Tuesday, November 26, 2013 1:24 AM, neil.lunn n...@mylunn.id.au wrote:
 
On 26/11/2013 12:54 PM, John Napiorkowski wrote:

We should probably document what it means by $c-response-body can accept a 
file handle.  Like plack specifies the interface it must deal with.  Anyone up 
to that?
Something along these lines maybe?

Catalyst can accept a file handle type of object as the response
body in the sense that the handle reasonably has a read method
that will return content. In such a case and where no content length
has been already set in the response headers catalyst will make a
reasonable attempt to determine the size of the file. Depending on
the implementation of your file handle object setting the content
length may fail. If it is at all possible for you to determine the
content length of your file handle, it is recomended that you set
the content length in the response headers yourself, which will be
respected and sent by catalyst in the response.



This FH in body thing is something I've been thinking about a lot lately, in 
regards to when Catalyst is running under an event loop for example, should 
Catalyst stream the Filehandle a non blocking manner.  But it would be great 
to document this.  Also, I am thinking setting the default size when its 
missing could really belong to middleware.  Plack has some default middleware 
that does this:


https://metacpan.org/source/MIYAGAWA/Plack-1.0030/lib/Plack/Middleware/ContentLength.pm

Which interestingly does not take a too different approach to what
the Catalyst code is attempting. Also noting that in a case such as
Bill presented it too would fail, which is only to be expected.

Noting such IO magic modules like IO::Uncompress::* and IO::Scalar
etc and speaking of cat skinning, another approach could be
subclassing these modues and overloading the file test operators to
do something sane when used, and thus return a correct response
when the -s test is used. Or try and convince said authors to have
these classes do this natively.




the means it works looks like this


https://metacpan.org/source/MIYAGAWA/Plack-1.0030/lib/Plack/Util.pm#L68



There's a few things in Catalyst.pm that could profitable just use 
Plack::Middleware counterparts.


just a thought.


johnnap



On Thursday, November 21, 2013 9:20 AM, neil.lunn n...@mylunn.id.au wrote:
 
On 22/11/2013 12:33 AM, Bill Moseley wrote:






On Wed, Nov 20, 2013 at 11:32 PM, neil.lunn n...@mylunn.id.au wrote:



This approach may work for you is the compressed data is actually in a scalar 
and not too large. And not too small. YMMV.

my $z = read_file product.json.gz;

my $io = IO::Scalar-new( \$z );
$io-seek( -4, 2 );
$io-read( my $buf, 4);

my $uncompressed_size = unpack( 'V',
$buf );




This indeed does work in my tests.   Thanks for all the help, Neil.   I 
really appreciate the time you spent on this.


No prob. Part of my thing on list reponses is that there is a seed for others 
to learn from what was discussed. 
I do wonder if there is a sane way to test for an in
memory file handle and give a more appropriate
warning, but that is for further discussion. 







-- 
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/



 
   This email is free from viruses and malware because avast! Antivirus 
 protection is active.  



___
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/ 




 
   This email is free from viruses and malware because avast! Antivirus 
protection is active.  ___
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] Setting file handle as the response body generates warnings.

[John Napiorkowski]

This would make an awesome Advent article.  If you started it I'd be sure to 
proofread and help out

https://github.com/perl-catalyst/2013-Advent-Staging


There's a few in there you can crib to help you get started.  Something like

what is the problem

show the solution

example

very easy to do!

john



On Tuesday, November 26, 2013 3:14 AM, Craig Chant 
cr...@homeloanpartnership.com wrote:
 
I’ve been using this for while….
 
    # check for ok status
    if($result-ok)
    {    
 
    # output header
    $c-response-content_type('application/vnd.ms-excel');
    $c-response-content_length(length($xls));    
$c-response-header(Content_Disposition = 
'attachment;filename=NBCS_Export.csv');
  
# create an IO::File for Catalyst
    use IO::File;
    my $iof = IO::File-new;
    
# open XLS
    $iof-open(\$xls, r);  
  
# output XLS data  
$c-response-body($iof);
    
# close file
    undef $iof;
    }
 
It resolves the out of memory issue if you try to print direct to 
$c-response-body without putting the content in an IO::File object.
 
 
From:John Napiorkowski [mailto:jjn1...@yahoo.com] 
Sent: 26 November 2013 01:54
To: The elegant MVC web framework
Subject: Re: [Catalyst] Setting file handle as the response body generates 
warnings.
 
We should probably document what it means by $c-response-body can accept a 
file handle.  Like plack specifies the interface it must deal with.  Anyone up 
to that?
 
This FH in body thing is something I've been thinking about a lot lately, in 
regards to when Catalyst is running under an event loop for example, should 
Catalyst stream the Filehandle a non blocking manner.  But it would be great to 
document this.  Also, I am thinking setting the default size when its missing 
could really belong to middleware.  Plack has some default middleware that does 
this:
 
https://metacpan.org/source/MIYAGAWA/Plack-1.0030/lib/Plack/Middleware/ContentLength.pm
 
the means it works looks like this
 
https://metacpan.org/source/MIYAGAWA/Plack-1.0030/lib/Plack/Util.pm#L68
 
There's a few things in Catalyst.pm that could profitable just use 
Plack::Middleware counterparts.
 
just a thought.
 
johnnap
 
On Thursday, November 21, 2013 9:20 AM, neil.lunn n...@mylunn.id.au wrote:
On 22/11/2013 12:33 AM, Bill Moseley wrote:
 
 
On Wed, Nov 20, 2013 at 11:32 PM, neil.lunn n...@mylunn.id.au wrote:
 
This approach may work for you is the compressed data is actually in a scalar 
and not too large. And not too small. YMMV.

my $z = read_file product.json.gz;

my $io = IO::Scalar-new( \$z );
$io-seek( -4, 2 );
$io-read( my $buf, 4);

my $uncompressed_size = unpack( 'V', $buf );
 
 
This indeed does work in my tests.   Thanks for all the help, Neil.   I really 
appreciate the time you spent on this.
 
No prob. Part of my thing on list reponses is that there is a seed for others 
to learn from what was discussed. 
I do wonder if there is a sane way to test for an in memory file handle and 
give a more appropriate warning, but that is for further discussion.
 
 
 
-- 
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/
 




 
 This email is free from viruses and malware because avast! Antivirus 
protection is active.  
 
 
___
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/
 
This Email and any attachments contain confidential information and is intended 
solely for the individual to whom it is addressed. If this Email has been 
misdirected, please notify the author as soon as possible. If you are not the 
intended recipient you must not disclose, distribute, copy, print or rely on 
any of the information contained, and all copies must be deleted immediately. 
Whilst we take reasonable steps to try to identify any software viruses, any 
attachments to this e-mail may nevertheless contain viruses, which our 
anti-virus software has failed to identify. You should therefore carry out your 
own anti-virus checks before opening any documents. HomeLoan Partnership will 
not accept any liability for damage caused by computer viruses emanating from 
any attachment or other document supplied with this e-mail. HomeLoan 
Partnership reserves the right to monitor and archive all e-mail communications 
through its network. No representative or
 employee of HomeLoan Partnership has the authority to enter 

Re: [Catalyst] Setting file handle as the response body generates warnings.

[John Napiorkowski]

We should probably document what it means by $c-response-body can accept a 
file handle.  Like plack specifies the interface it must deal with.  Anyone up 
to that?

This FH in body thing is something I've been thinking about a lot lately, in 
regards to when Catalyst is running under an event loop for example, should 
Catalyst stream the Filehandle a non blocking manner.  But it would be great to 
document this.  Also, I am thinking setting the default size when its missing 
could really belong to middleware.  Plack has some default middleware that does 
this:

https://metacpan.org/source/MIYAGAWA/Plack-1.0030/lib/Plack/Middleware/ContentLength.pm


the means it works looks like this

https://metacpan.org/source/MIYAGAWA/Plack-1.0030/lib/Plack/Util.pm#L68


There's a few things in Catalyst.pm that could profitable just use 
Plack::Middleware counterparts.

just a thought.

johnnap



On Thursday, November 21, 2013 9:20 AM, neil.lunn n...@mylunn.id.au wrote:
 
On 22/11/2013 12:33 AM, Bill Moseley wrote:






On Wed, Nov 20, 2013 at 11:32 PM, neil.lunn n...@mylunn.id.au wrote:



This approach may work for you is the compressed data is actually in a scalar 
and not too large. And not too small. YMMV.

my $z = read_file product.json.gz;

my $io = IO::Scalar-new( \$z );
$io-seek( -4, 2 );
$io-read( my $buf, 4);

my $uncompressed_size = unpack( 'V', $buf );




This indeed does work in my tests.   Thanks for all the help, Neil.   I really 
appreciate the time you spent on this.


No prob. Part of my thing on list reponses is that there is a seed for others 
to learn from what was discussed. 
I do wonder if there is a sane way to test for an in memory file
handle and give a more appropriate warning, but that is for further
discussion.






-- 
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/



 
   This email is free from viruses and malware because avast! Antivirus 
protection is active.  


___
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] Setting file handle as the response body generates warnings.

[John Napiorkowski]

This works, but Catalyst in finalize_headers issues two warnings:

-s on unopened filehandle GEN10 at 
/home/bill/perl5/perlbrew/perls/perl-5.14.2/lib/site_perl/5.14.2/Catalyst.pm 
line 1893.


[warn] Serving filehandle without a content-length


Are those warning a problem with how Catalyst is handling this, or something 
wrong with how IO::Uncompress::Gunzip is working?


Bill,

This looks familiar, but I thought we fixed this... what version of Catalyst 
are you using here?

John


-- 
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] Providing a REST API from behind Apache/FastCGI?

[John Napiorkowski]

Sent from my iPhone

 On Nov 11, 2013, at 9:50 PM, Dan Lowe d...@tangledhelix.com wrote:
 
 
 On Nov 11, 2013, at 3:51 PM, brainbuz brain...@brainbuz.org wrote:
 
 Newer versions of apache make some security changes
 so apache, even though you don't think any access control is being applied 
 on the server side,
 might be blocking it by default (although that should be a 403 rather than 
 401).
 
 You could try a block like this:
 
 Location /uri_for/my/app.fcgi
 Order Allow,Deny
 Allow From All
 Satisfy Any
 /Location
 
 That did not work unfortunately... but I have found that the data I need is 
 available in $c-engine-env-{Authorization}, so I'll see what I can do with 
 that.

Just FYI but -env is attached to the request obj in more modern versions of 
catalyst.  You might want to write a bit of wrapper logic there to check on 
then the other such as to ease any future upgrades 

Jnap 

 I'll also look at starman and see if that improves things.
 
 Thanks,
 Dan
 
 
 
 I wrote an article on deploying starman with apache in the 2011 catalyst 
 advent calendar, with some errata on my blog, you might want to consider 
 switching, although you would still run afoul of tighter apache defaults if 
 that is indeed your problem.
 
 
 
 ___
 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] Its Time for Advent 2013!

[John Napiorkowski]

Hey All,

I've opened a repo on github to get you started with Perl Catalyst advent 2013

https://github.com/perl-catalyst/2013-Advent-Staging/


More details on my blog : 
http://jjnapiorkowski.typepad.com/modern-perl/2013/11/perl-catalyst-request-for-advent-season-articles.html

Get writing!

jnap___
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] $c-write() buffering?

[John Napiorkowski]

Daniel,

Have you taken a look at what Plack's FCGI handlers does?  I'm not so familiar 
with the intricacies of FCGI but here's the source:

https://metacpan.org/source/MIYAGAWA/Plack-1.0029/lib/Plack/Handler/FCGI.pm


psgi.input is set to STDIN it appears.  Not sure if that is what you are 
looking for.

the PSGI based Catalyst introduced a way to allow you to have more fined 
control over the write process.  I wonder if you could experiment with that and 
let us know how it goes?  

John



On Thursday, November 7, 2013 3:07 PM, Daniel J. Luke dl...@geeklair.net 
wrote:
 
I've done some more experimentation and this doesn't end up working very well 
for us. For the list archive:

You can accomplish what I was going for using mod_fastcgi and a standalone 
FCGI-based script. mod_fastcgi needs to be configured with its -flush option 
/and/ you need to be able to call FCGI::Flush($request) when you want output 
sent out to the client.

Catalyst::Engine:FastCGI doesn't expose the FCGI request (lexical variable in 
the run() method), though, so there's not an easy way to do this (and it's icky 
anyway). Catalyst::Engine::FastCGI should possibly FCGI::Flush in its write() 
method [note that Plack::Handler::FCGI doesn't expose the FCGI request either 
and also doesn't call FCGI::Flush anywhere].

So, I guess no one is doing $c-res-write() with mod_fastcgi and 
http://wiki.catalystframework.org/wiki/longcomputations should probably be 
edited to explain that this doesn't work (unless you pad each write() you want 
to go to the client to 8k).

We'll likely implement some AJAX ui (possibly tying up 2 catalyst processes 
instead of just one and/or fork/exec a worker) for now, until we can get some 
time to move things over to a job queue that isn't as horrible as the one we 
currently have :-)


On Nov 1, 2013, at 11:42 AM, John Napiorkowski jjn1...@yahoo.com wrote:
 I was reviewing code last night for release of Catalyst Hamburg dev5 and saw 
 that $c-res-write is just calling the writer under the hood.  So as long as 
 your headers are ready to finalize, that should be fine as well.  Just 
 remember this approach is going to block, so be careful with anything  that 
 is taking a lot of time.  --jnap
 
 
 On Thursday, October 31, 2013 4:34 PM, John Napiorkowski jjn1...@yahoo.com 
 wrote:
 Recent releases of Catalyst makes it possible to stream write, although you 
 need to be careful when using a blocking web server (long stream will of 
 course block the available listener).
 
 Older versions of Catalyst had similar ability with the write method, I never 
 used it, and would be happen to get patches or test cases to make it work as 
 we'd like.
 
 Here's a link to an example, this one assume AnyEvent as a loop, but you 
 could use a similar technique with any web server, as long as you don't mind 
 blocking:
 
 https://metacpan.org/pod/release/JJNAPIORK/Catalyst-Runtime-5.90049_005/lib/Catalyst/Response.pm#res-write_fh
 
 If you follow that, you will see stuff 'stream' as you wish unless there is 
 some buffering going on at some other level of the stack.
 
 Johnn
 
 
 On Thursday, October 31, 2013 4:22 PM, Daniel J. Luke dl...@geeklair.net 
 wrote:
 I replicated this today outside of Catalyst (just a small 
 FCGI/FCGI::ProcManager test script). If anyone else has seen this/fixed it, 
 I'd appreciate a pointer. I'll report back to the list if/when I get it 
 resolved so that there's an answer in the list archives for future people to 
 google otherwise.
 
 On Oct 31, 2013, at 10:12 AM, Daniel J. Luke dl...@geeklair.net wrote:
  We're actually running Catalyst::Runtime 5.80031 (currently), so I believe 
  it's using Catalyst::Engine::FastCGI which just does *STDOUT-syswrite()
  
  I guess I try to do some testing with newer Catalyst (and maybe alternate 
  deployment methods), to see if that changes anything. Looking through the 
  Changelog, I didn't see anything specifically related to this, though 
  (although I imagine the Plack stuff makes it somewhat different in the more 
  recent releases). 
  
  On Oct 30, 2013, at 11:03 PM, Hailin Hu i...@h2l.name wrote:
  It is an engine relevant stuff.
  Find which engine you are using ( for example, Plack::Handler::FCGI )
  and look around codes around write(r), you may find something.
  Good luck :)
  
  On Wed, Oct 30, 2013 at 9:51 AM, Daniel J. Luke dl...@geeklair.net wrote:
  I've got some legacy CGI code that does a bunch of processing and uses 
  the old hack of $| = 1; print foo\n; do_work(); print foo done\n; 
  etc. (solution #1 from 
  http://wiki.catalystframework.org/wiki/longcomputations)
  
  While I'll eventually convert it to a job queue, I'd like to create an 
  output-identical implementation first with Catalyst, however it seems 
  like I'm getting output buffering when I don't want it.
  
  As a very simple test, I've set up apache 2.2, mod_fastcgi 
  (FastCgiExternalServer with -flush and without -flush) and a method like 
  this:
  
  sub test

[Catalyst] New Point release of Perl Catalyst, 5.90051 on CPAN

[John Napiorkowski]

Hey All,

Yesterday we release a point increase to the recent stable Catalyst to solve a 
regression this release caused in Catalyst::Action::REST

If you use CAR, this update is required.

If anyone runs into additional regressions, please shout on on the mailing 
list, IRC or feel free to add a bug to the github issues list

https://github.com/perl-catalyst/catalyst-runtime/issues


jnap___
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 Hamburg is the new stable, Version 5.90050 on CPAN!

[John Napiorkowski]

Hello Catalyst Users and Hackers!

Today we mark the end of the Hamburg development cycle, which was kicked off 
back in June.  This release is a bit longer in development than the past few, 
but as I expected, things got a bit slow over the summer (I'm Northern 
hemisphere located) and since we did a lot of development releases along the 
way I think the longer cycle worked out.

Now I am please to announce 
https://metacpan.org/release/JJNAPIORK/Catalyst-Runtime-5.90050 !

A number of people contributed to this release included two of my coworkers 
here at Campus Explorer (ether++, gerda++), n0body from IRC (who stepped up 
with a patch at the last moment that solved some testing problems in dev 
release 5) as well as many people who contributed via discussion, or doing code 
review (t0m++)

In general I think we hit most of the goals we set at the start of the hamburg. 
 I'll do a full end retrospective later in the week.  In no particular order of 
important:

-- You can now declare PSGI Middleware via configuration (making it easier and 
potentially less messy to use Middleware in your applications).
-- Catalyst::Response can now consume a PSGI response (making it easier to use 
Catalyst to dispatch to an underlying PSGI application, such as one based on 
Web::Machine, Web::Simple (or Dancer, or even another Catalyst application).
-- Other small PSGI related improvements, like we now buffer request body 
content if a buffer does not exist (such as if you are using FastCGI) so that 
PSGI applications running under Catalyst will be able to read that data.
-- You can use Hash::MultiValue for your body and query parameters.  This 
approach is used in a lot of PSGI middleware and applications because it 
reduces the need to worry about if incoming parameters are scalars or arrays
-- Catalyst::Request now has a new method 'body_data' which exposes perl 
structures of incoming body content such as JSON and nested parameters ( 
Catalyst now can read JSON posted data out of the box !)

We also fixed up docs, modernized some of the Moose code, added experimental 
support for IO-Async based event loops for doing non blocking IO (web sockets, 
long polling, streaming, etc.)  And some other stuff, go check out the change 
log and view the diffs.

I'll blog more about some of these updates, and retrospect this development 
cycle a bit later.  And there's nothing stopping any of the rest of you from 
playing with this and blogging as well!

What's next?  I'm not setting the start of a new goal specific development 
cycle, but of course the repo is still open and you can branch the code and 
hack as you wish.  If you are looking for some ideas, feel free to checkout our 
quest hub list: http://questhub.io/realm/perl/explore/latest/tag/catalyst

Remember, there's lots of ways to contribute.  You can code of course, but we 
also need people that review proposals and ask questions or consider solutions 
(see the quest hub link above), as well as people to blog, review documentation 
and just generally help out people when they are stuck on IRC.

Thanks again for everyones help, and please don't be upset if I forgot to 
mention you by name.

Catalyst on CPAN : 
https://metacpan.org/release/JJNAPIORK/Catalyst-Runtime-5.90050
Questhub: http://questhub.io/realm/perl/explore/latest/tag/catalyst
Git repo: git://git.shadowcat.co.uk/catagits/Catalyst-Runtime.git
Github: https://github.com/perl-catalyst/catalyst-runtime

This closes the hamburg branch.  On a personal note, both my Hamburg hen and 
rooster were lost to predation over the summer, so this release will serve for 
me as a memorial to them.  Thanks for checking in!

Jnap___
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: Have exceeded the maximum number of attempts (1000) to open temp file/dir

[John Napiorkowski]

Wow, that does seem odd.  I wonder if there's some evil sharing going on 
between mod_perl processes or something...



On Monday, November 4, 2013 8:26 AM, Bill Moseley mose...@hank.org wrote:
 





On Fri, Oct 25, 2013 at 6:51 AM, Bill Moseley mose...@hank.org wrote:



[ERROR] Caught exception in engine Error in tempfile() using 
/tmp/XX: Have exceeded the maximum number of attempts (1000) to open 
temp file/dir


I don't really see how this can be a Catalyst issue, but I can't reproduce it 
outside of Catalyst -- and outside of our production environment.   

Can anyone think of anything else that might be going on here?   


The template has 10 X that are replaced by I think 63 random ascii 
characters.   63^10 is a huge number of random strings.   File::Temp only loops 
when sysopen returns EEXISTS -- that is, when sysopen fails AND the error is 
that the file already exists.

Sure, there's 50 web processes but the odds of them all being in exact 
lock-step with calling rand() is unlikely.  And even if they started out that 
way if two processes opened the exact same name at the same time one process 
would just try the next random name and be done.



I have something like 26K files in /tmp, so nothing compared to 63^10.   And 
each web server is only seeing about 10 request/sec.

It's just not making sense.


Again, I'm unable to replicate the problem with a simple test script that is 
designed to clash.

I fork 50 (or more) child processes to replicate the web server processes and 
then in each one I do this:



        # Wait until top of the second so each child procss starts about the 
same time.

        my $t = time();  # Time::HiRes
        sleep( int( $t ) + 1 - $t );


        for ( 1 .. 500 ) {

            my $fh = File::Temp-new(
                TEMPLATE = 'bill_X',
                DIR = '/tmp',
            );

        }


And never see any contention.

 


The File::Temp docs say:


If you are forking many processes in parallel that are all creating
temporary files, you may need to reset the random number seed using
srand(EXPR) in each child else all the children will attempt to walk
through the same set of random file names and may well cause
themselves to give up if they exceed the number of retry attempts.


We are running under mod_perl.   Could it be as simple as the procs all were 
in sync?   I'm just surprised this has not happened before.   Is there another 
explanation?


Where would you suggest to call srand()?




Another problem, and one I've commented on before, is that HTTP::Body doesn't 
use File::Temp's unlink feature and depends on Catalyst cleaning up.  This 
results in orphaned files left on temp disk.









-- 
Bill Moseley
mose...@hank.org 



-- 
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] Re: Response traits.

[John Napiorkowski]

I think a patch that made sure strings being set to location conformed to the 
expected standard would be very welcomed!

on the other hand I thought this was also caught by 

https://metacpan.org/pod/Plack::Middleware::Lint


as well?  In any case Catalyst response could reject any attempts to set 
-location with incorrect values.

The only thing is that people could still probably get around it by setting 
headers directly.  I think for now we'll say if you do that we have to assume 
you know what you are doing!

John



On Thursday, October 31, 2013 7:03 PM, Bill Moseley mose...@hank.org wrote:
 





On Thu, Oct 31, 2013 at 2:34 PM, John Napiorkowski jjn1...@yahoo.com wrote:

I'm currently recommending people take advantage of native PSGI support in the 
newer Catalyst and use Middleware for when you need to munge and or alter the 
response (if its being done globally).  The interface is more straightforward.

Do you think that Catalyst::Response should validate the location provided to 
redirect()?

The issue that came up was a newline was ending up in the location provided 
which resulted in a split response.    I was thinking of doing something like:

$self-location( URI-new( $location )-as_string );

But with perhaps a bit more error handling.




 


johnn



On Thursday, October 31, 2013 11:33 AM, Bill Moseley mose...@hank.org wrote:
 


On Thu, Oct 31, 2013 at 12:51 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote:

CatalystX::RoleApplicator
Thanks.  That was what I was looking for.   Just missed it when looking.



-- 
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/






-- 
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/

Re: [Catalyst] Mocking PSGI layers in Test WWW Mechanize Catalyst

[John Napiorkowski]

Catalyst::Test uses Plack::Test under the hood.  That mangle_response stuff is 
mostly evil :)

Sounds like you are saying you'd like to apply Plack Middleware during testing. 
 The latest dev release on CPAN lets you configure middleware via 
configuration, so you could have some middleware in your test configuration.  
This use case is one of the reasons I added this feature, so that we could 
manage middleware for catalyst inside of catalyst configuration.

If you don't like that approach, I could be talked into a patch to 
Catalyst::Test that would let you declare additional middleware in the test 
case.

I'd prefer this over messing with Catalyst::Test internals.  One of the hard 
things about trying to move Catalyst forward is that we've expose a ton of API 
that we fear to change since we don't know who is overriding what in the 
Darkpan.  Ideally I'd like to see people use Plack Middleware for jobs 
involving modifying the request and response, since that is something its great 
at, and the API is just a code ref, so its very well decoupled (could even be 
used outside of Catalyst).

Good luck!

John



On Thursday, October 31, 2013 8:26 PM, Toby Corkindale t...@dryft.net wrote:
 
On 1 November 2013 12:01, Kieren Diment dim...@gmail.com wrote:
 You mean you want two apps interacting with each other in the same script 
 using WWW::MEchanize?  Eden and I were working some docs up on that topic 
 until real life intervened.

 This was the start of it:

 http://paste.scsys.co.uk/273844

Not exactly -- in this case I have a PSGI layer that is supposed to
inject some extra information into the env for consumption by the
application.

A simple example would be if you had a PSGI layer providing, say,
Basic HTTP auth, and setting the REMOTE_USER variable.
Although in my case, there's a bit more to it than that.

T

 On 01/11/2013, at 11:39 AM, Toby Corkindale wrote:

 Umm, not that I know of.

 I suppose another way to phrase the question is: Is there a way to
 manipulate the $c-engine-env in the Catalyst application, from
 within unit tests neatly?

 On 1 November 2013 08:35, John Napiorkowski jjn1...@yahoo.com wrote:
 Not sure what you mean, is there an example in another framework you can
 point to?

 johnn


 On Thursday, October 31, 2013 12:55 AM, Toby Corkindale t...@dryft.net
 wrote:
 Hi,
 I wondered if there's any prior art around on inserting (mocked) PSGI
 layers into Test::WWW::Mechanize:Catalyst?

 Cheers,
 Toby

 --
 Turning and turning in the widening gyre
 The falcon cannot hear the falconer
 Things fall apart; the center cannot hold
 Mere anarchy is loosed upon the world

 ___
 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/





 --
 Turning and turning in the widening gyre
 The falcon cannot hear the falconer
 Things fall apart; the center cannot hold
 Mere anarchy is loosed upon the world

 ___
 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/



-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world

___
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] $c-write() buffering?

[John Napiorkowski]

I was reviewing code last night for release of Catalyst Hamburg dev5 and saw 
that $c-res-write is just calling the writer under the hood.  So as long as 
your headers are ready to finalize, that should be fine as well.  Just remember 
this approach is going to block, so be careful with anything  that is taking a 
lot of time.  --jnap



On Thursday, October 31, 2013 4:34 PM, John Napiorkowski jjn1...@yahoo.com 
wrote:
 
Recent releases of Catalyst makes it possible to stream write, although you 
need to be careful when using a blocking web server (long stream will of course 
block the available listener).

Older versions of Catalyst had similar ability with the write method, I never 
used it, and would be happen to get patches or test cases to make it work as 
we'd like.

Here's a link to an example, this one assume AnyEvent as a loop, but you could 
use a similar technique with any web server, as long as you don't mind blocking:

https://metacpan.org/pod/release/JJNAPIORK/Catalyst-Runtime-5.90049_005/lib/Catalyst/Response.pm#res-write_fh


If you follow that, you will see stuff 'stream' as you wish unless there is 
some buffering going on at some other level of the stack.

Johnn



On Thursday, October 31, 2013 4:22 PM, Daniel J. Luke dl...@geeklair.net 
wrote:
 
I replicated this today outside of Catalyst (just a small 
FCGI/FCGI::ProcManager test script). If anyone else has seen this/fixed it, I'd 
appreciate a pointer. I'll report back to the list if/when I get it resolved so 
that there's an answer in the list archives for future people to google 
otherwise.


On Oct 31, 2013, at 10:12 AM, Daniel J. Luke dl...@geeklair.net wrote:
 We're actually running Catalyst::Runtime 5.80031 (currently), so I believe 
 it's using Catalyst::Engine::FastCGI which just does *STDOUT-syswrite()
 
 I guess I try to do some testing with newer Catalyst (and maybe alternate 
 deployment methods), to see if that changes anything. Looking through the 
 Changelog, I didn't see anything specifically related to this, though 
 (although I imagine the Plack stuff makes it somewhat different in the more 
 recent releases). 
 
 On Oct 30, 2013, at 11:03 PM, Hailin Hu i...@h2l.name wrote:
 It is an engine relevant stuff.
 Find which engine you are using ( for example, Plack::Handler::FCGI )
 and look around codes around write(r), you may find something.
 Good luck :)
 
 On Wed, Oct 30, 2013 at 9:51 AM, Daniel J. Luke dl...@geeklair.net wrote:
 I've got some legacy CGI code that does a bunch of processing and uses the 
 old hack of $| = 1; print foo\n; do_work(); print foo done\n; etc. 
 (solution #1 from http://wiki.catalystframework.org/wiki/longcomputations)
 
 While I'll eventually convert it to a job queue, I'd like to create an 
 output-identical implementation first with Catalyst, however it seems like 
 I'm getting output buffering when I don't want it.
 
 As a very simple test, I've set up apache 2.2, mod_fastcgi 
 (FastCgiExternalServer with -flush and without -flush) and a method like 
 this:
 
 sub test: Local {
   my ($self, $c) = @_;
 
   $c-res-body('');
   $c-response-content_type( 'text/plain; charset=utf-8' );
   $c-finalize_headers;
 
   my $i;
   for($i=1;$i8;$i++) {
       $c-write($i: foo bar baz\n);
       sleep(1);
   }
 }
 
 I see all the data at once in my browser instead of a line every second, 
 and with tcpdump, can see that all of the data is coming back in one packet 
 and not in 8+ smaller packets like I expect. If I make the string that gets 
 passed to write longer, I get several packets, but all at once (and not 
 with each iteration through the for loop).
 
 Am I missing something obvious? Is there some way to get the behavior I'm 
 expecting?

--
Daniel J. Luke                                         
                         
++                      
  
| * dl...@geeklair.net * |                      
    
| *-- http://www.geeklair.net -* |                      
    
++                      
  
|   Opinions expressed are mine and do not
 necessarily   |                          
|          reflect the opinions of my employer.          |                      
    
++




___
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/___
List: Catalyst@lists.scsys.co.uk

Re: [Catalyst] $c-write() buffering?

[John Napiorkowski]

Also, check out 

https://github.com/jjn1056/Perl-Catalyst-AsyncExample


which has a few examples related.  Those are more about async IO but the 
approach is the same, just more simple since you don't need to run a lot of 
callbacks.

Basically post PSGI Catalyst returns a deferred response to the underlying 
server, so streaming and all that is straightforward.

Johnn



On , John Napiorkowski jjn1...@yahoo.com wrote:
 
Recent releases of Catalyst makes it possible to stream write, although you 
need to be careful when using a blocking web server (long stream will of course 
block the available listener).

Older versions of Catalyst had similar ability with the write method, I never 
used it, and would be happen to get patches or test cases to make it work as 
we'd like.

Here's a link to an example, this one assume AnyEvent as a loop, but you could 
use a similar technique with any web server, as long as you don't mind blocking:

https://metacpan.org/pod/release/JJNAPIORK/Catalyst-Runtime-5.90049_005/lib/Catalyst/Response.pm#res-write_fh


If you follow that, you will see stuff 'stream' as you wish unless there is 
some buffering going on at some other level of the stack.

Johnn



On Thursday, October 31, 2013 4:22 PM, Daniel J. Luke dl...@geeklair.net 
wrote:
 
I replicated this today outside of Catalyst (just a small 
FCGI/FCGI::ProcManager test script). If anyone else has seen this/fixed it, I'd 
appreciate a pointer. I'll report back to the list if/when I get it resolved so 
that there's an answer in the list archives for future people to google 
otherwise.


On Oct 31, 2013, at 10:12 AM, Daniel J. Luke dl...@geeklair.net wrote:
 We're actually running Catalyst::Runtime 5.80031 (currently), so I believe 
 it's using Catalyst::Engine::FastCGI which just does *STDOUT-syswrite()
 
 I guess I try to do some testing with newer Catalyst (and maybe alternate 
 deployment methods), to see if that changes anything. Looking through the 
 Changelog, I didn't see anything specifically related to this, though 
 (although I imagine the Plack stuff makes it somewhat different in the more 
 recent releases). 
 
 On Oct 30, 2013, at 11:03 PM, Hailin Hu i...@h2l.name wrote:
 It is an engine relevant stuff.
 Find which engine you are using ( for example, Plack::Handler::FCGI )
 and look around codes around write(r), you may find something.
 Good luck :)
 
 On Wed, Oct 30, 2013 at 9:51 AM, Daniel J. Luke dl...@geeklair.net wrote:
 I've got some legacy CGI code that does a bunch of processing and uses the 
 old hack of $| = 1; print foo\n; do_work(); print foo done\n; etc. 
 (solution #1 from http://wiki.catalystframework.org/wiki/longcomputations)
 
 While I'll eventually convert it to a job queue, I'd like to create an 
 output-identical implementation first with Catalyst, however it seems like 
 I'm getting output buffering when I don't want it.
 
 As a very simple test, I've set up apache 2.2, mod_fastcgi 
 (FastCgiExternalServer with -flush and without -flush) and a method like 
 this:
 
 sub test: Local {
   my ($self, $c) = @_;
 
   $c-res-body('');
   $c-response-content_type( 'text/plain; charset=utf-8' );
   $c-finalize_headers;
 
   my $i;
   for($i=1;$i8;$i++) {
       $c-write($i: foo bar baz\n);
       sleep(1);
   }
 }
 
 I see all the data at once in my browser instead of a line every second, 
 and with tcpdump, can see that all of the data is coming back in one packet 
 and not in 8+ smaller packets like I expect. If I make the string that gets 
 passed to write longer, I get several packets, but all at once (and not 
 with each iteration through the for loop).
 
 Am I missing something obvious? Is there some way to get the behavior I'm 
 expecting?

--
Daniel J. Luke                                         
                         
++                      
  
| * dl...@geeklair.net * |                      
    
| *-- http://www.geeklair.net -* |                      
    
++                      
  
|   Opinions expressed are mine and do not
 necessarily   |                          
|          reflect the opinions of my employer.          |                      
    
++




___
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] $c-write() buffering?

[John Napiorkowski]

Recent releases of Catalyst makes it possible to stream write, although you 
need to be careful when using a blocking web server (long stream will of course 
block the available listener).

Older versions of Catalyst had similar ability with the write method, I never 
used it, and would be happen to get patches or test cases to make it work as 
we'd like.

Here's a link to an example, this one assume AnyEvent as a loop, but you could 
use a similar technique with any web server, as long as you don't mind blocking:

https://metacpan.org/pod/release/JJNAPIORK/Catalyst-Runtime-5.90049_005/lib/Catalyst/Response.pm#res-write_fh


If you follow that, you will see stuff 'stream' as you wish unless there is 
some buffering going on at some other level of the stack.

Johnn



On Thursday, October 31, 2013 4:22 PM, Daniel J. Luke dl...@geeklair.net 
wrote:
 
I replicated this today outside of Catalyst (just a small 
FCGI/FCGI::ProcManager test script). If anyone else has seen this/fixed it, I'd 
appreciate a pointer. I'll report back to the list if/when I get it resolved so 
that there's an answer in the list archives for future people to google 
otherwise.


On Oct 31, 2013, at 10:12 AM, Daniel J. Luke dl...@geeklair.net wrote:
 We're actually running Catalyst::Runtime 5.80031 (currently), so I believe 
 it's using Catalyst::Engine::FastCGI which just does *STDOUT-syswrite()
 
 I guess I try to do some testing with newer Catalyst (and maybe alternate 
 deployment methods), to see if that changes anything. Looking through the 
 Changelog, I didn't see anything specifically related to this, though 
 (although I imagine the Plack stuff makes it somewhat different in the more 
 recent releases). 
 
 On Oct 30, 2013, at 11:03 PM, Hailin Hu i...@h2l.name wrote:
 It is an engine relevant stuff.
 Find which engine you are using ( for example, Plack::Handler::FCGI )
 and look around codes around write(r), you may find something.
 Good luck :)
 
 On Wed, Oct 30, 2013 at 9:51 AM, Daniel J. Luke dl...@geeklair.net wrote:
 I've got some legacy CGI code that does a bunch of processing and uses the 
 old hack of $| = 1; print foo\n; do_work(); print foo done\n; etc. 
 (solution #1 from http://wiki.catalystframework.org/wiki/longcomputations)
 
 While I'll eventually convert it to a job queue, I'd like to create an 
 output-identical implementation first with Catalyst, however it seems like 
 I'm getting output buffering when I don't want it.
 
 As a very simple test, I've set up apache 2.2, mod_fastcgi 
 (FastCgiExternalServer with -flush and without -flush) and a method like 
 this:
 
 sub test: Local {
   my ($self, $c) = @_;
 
   $c-res-body('');
   $c-response-content_type( 'text/plain; charset=utf-8' );
   $c-finalize_headers;
 
   my $i;
   for($i=1;$i8;$i++) {
       $c-write($i: foo bar baz\n);
       sleep(1);
   }
 }
 
 I see all the data at once in my browser instead of a line every second, 
 and with tcpdump, can see that all of the data is coming back in one packet 
 and not in 8+ smaller packets like I expect. If I make the string that gets 
 passed to write longer, I get several packets, but all at once (and not 
 with each iteration through the for loop).
 
 Am I missing something obvious? Is there some way to get the behavior I'm 
 expecting?

--
Daniel J. Luke                                                                  
++                      
  
| * dl...@geeklair.net * |                      
    
| *-- http://www.geeklair.net -* |                      
    
++                      
  
|   Opinions expressed are mine and do not necessarily   |                      
    
|          reflect the opinions of my employer.          |                      
    
++




___
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: Response traits.

[John Napiorkowski]

I'm currently recommending people take advantage of native PSGI support in the 
newer Catalyst and use Middleware for when you need to munge and or alter the 
response (if its being done globally).  The interface is more straightforward.

johnn



On Thursday, October 31, 2013 11:33 AM, Bill Moseley mose...@hank.org wrote:
 


On Thu, Oct 31, 2013 at 12:51 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote:

CatalystX::RoleApplicator
Thanks.  That was what I was looking for.   Just missed it when looking.


-- 
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] Mocking PSGI layers in Test WWW Mechanize Catalyst

[John Napiorkowski]

Not sure what you mean, is there an example in another framework you can point 
to?

johnn



On Thursday, October 31, 2013 12:55 AM, Toby Corkindale t...@dryft.net wrote:
 
Hi,
I wondered if there's any prior art around on inserting (mocked) PSGI
layers into Test::WWW::Mechanize:Catalyst?

Cheers,
Toby

-- 
Turning and turning in the widening gyre
The falcon cannot hear the falconer
Things fall apart; the center cannot hold
Mere anarchy is loosed upon the world

___
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] Have exceeded the maximum number of attempts (1000) to open temp file/dir

[John Napiorkowski]

Bill,

I see over here (latest release)

https://metacpan.org/source/JJNAPIORK/Catalyst-Runtime-5.90049_005/lib/Catalyst/Request.pm#L260


am calling -cleanup(1) when we create the HTTP::Body.  is that not enough to 
cleanup tmp files ?

regarding the tmp file thing, wow I have no idea, but I hope you find out and 
report it to us!

Johnn



On Friday, October 25, 2013 8:53 AM, Bill Moseley mose...@hank.org wrote:
 
I have an API where requests can include JSON.  HTTP::Body saves those off to 
temp files.

Yesterday got a very large number of errors:

[ERROR] Caught exception in engine Error in tempfile() using /tmp/XX: 
Have exceeded the maximum number of attempts (1000) to open temp file/dir

The File::Temp docs say:

If you are forking many processes in parallel that are all creating
temporary files, you may need to reset the random number seed using
srand(EXPR) in each child else all the children will attempt to walk
through the same set of random file names and may well cause
themselves to give up if they exceed the number of retry attempts.

We are running under mod_perl.   Could it be as simple as the procs all were in 
sync?   I'm just surprised this has not happened before.   Is there another 
explanation?

Where would you suggest to call srand()?


Another problem, and one I've commented on before, is that HTTP::Body doesn't 
use File::Temp's unlink feature and depends on Catalyst cleaning up.  This 
results in orphaned files left on temp disk.




-- 
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/

[Catalyst] Development 5 Release of Catalyst 'Hamburg' on CPAN

[John Napiorkowski]

Hey All,

Catalyst 5.90049_005 is on CPAN, please check it out!

This is the fifth and likely last development release of Catalyst in this 
current series.  Assuming no serious problems show up on CPAN testers, and 
nobody shouts out, I will make this as stable sometime in the next few days.

In general the development releases have gone over well with CPAN testers and I 
feel the release is pretty solid.  That being said there are a lot of changes 
and features so it is well worth testing your code on this release.  Its just a 

    cpanm --dev Catalyst

Away from being on your box!

Here's the most recent changes:

  - NEW FEATURE:  New Controller action attribute 'Consumes', which allows you
to specify the content type of the incoming request.  This makes it easier
to create actions that only handle certain content type POST or PUT, such
as actions that only handle JSON or actions that only understand classic
HTML forms.
  - NEW FEATURE: Request-body_data is now also populated from classic HTML 
Forms using CGI::Struct to support nested data.  For non nested data you
should use the classic -body_parameters method.
  - Removed PSGI $env keys that are added on the 'plack.request.*' namespace
since after discussion it was clear those keys are not part of the public
API.  Keys removed: 'plack.request.query', 'plack.request.body', 
'plack.request.merged' and 'plack.request.http.body'. Altered some test
cases to reflect this change.

Cheers!

Johnn

___
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] One more thing on the state of Async IO on Catalyst Dev5

[John Napiorkowski]

One thing that was noted in the changlog is we have added experimental support 
of IO:Async based event loops, to compliment Anyevent.  The Async examples on 
github have been updated to include a IOAsync version of the streaming, web 
socket echo and web socket chat examples.

Async IO support in Catalyst is still experimental overall, but the feature is 
there and worth playing with if you are interested in learning about it.  

Have Fun!

https://github.com/jjn1056/Perl-Catalyst-AsyncExample


Jnap

___
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] Calling controller/action based on parameter

[John Napiorkowski]

You could also try to encapsulate the match logic in an action class or role.  
--jnap



On Saturday, October 19, 2013 1:58 AM, Richard Thomas r...@mac.com wrote:
 Any suggestions on how to do this?  I'm toying with a large switch statement 
 in the root controller and visiting the appropriate controller/action based 
 on the parameter.  Is this right?  Does Catalyst provide a way to accomplish 
 this either easier or cleaner?

Hi Bill,

Rather than a big mess of a switch statement, I would be inclined to construct 
a hash that contains the rules for the mapping of the short-codes to the 
appropriate Controller/action, i.e.

my $codes = {
    'tms' = [ 'Controller1', 'action1' ],
    'tve' = [ 'Controler1', 'action2' ],
    'prn' = [ 'ControllerN', 'actionN' ],
};

then the control flow is more or less abstracted into a simple hash of rules:

if($args[0] =~ /^(\w{3})(\w{13})$/){ # separate media type from key
    my ($code, $key) = ($1, $2);
    if(my $ca = $codes-{$code}){
        $c-forward(MyApp::Controller::.$ca-[0], $ca-[1], [ $key, @args ]);
    }
    else {
        ...
    }
}

To be honest, I think this is the sort of use for which the 'Regex' action type 
shines, but I believe it's being deprecated.

cheers
RET
___
If the programmers like each other, they play a game called pair programming.
And if not, then the game is called peer review.
- Anna Nachesa (@ashalynd)

Richard Thomas





___
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] Catalyst::Request path method as a setter

[John Napiorkowski]

My guess here is that path should be RO and that if you need to write code that 
messed with the path, that should happen in plack middleware.

I'll ask around IRC to try and find out why this was allowed in the first 
place.  My guess it that we wanted to allow people to change the path for doing 
complex path rewriting.

jnap



On Monday, October 21, 2013 10:00 AM, Bill Moseley mose...@hank.org wrote:
 
=head2 $req-path

 
Returns the path, i.e. the part of the URI after $req-base, for the current 
request.

Pasted below is Catalyst::Request's path method.   Note from the final else 
block that $req-path returns the request uri's path ($req-uri-path) with the 
$req-base-path removed as the documentation says.

So, if the request URI and base URI are these:

http://localhost/myapp/path/to/action  # $req-uri
http://localhost/myapp/  # $req-base

then $req-path is:

path/to/action

Using the example above, and looking at what $req-path( ) does as a setter:

$req-path( $req-path );

would result in a new request URI of:

http://localhost/path/to/action.

The path method doesn't document what it does as a setter, but this behavior 
looks broken because it alters the request URI's path.

What do you think?


sub path {
    my ( $self, @params ) = @_;

    if (@params) {
        $self-uri-path(@params);
        $self-_clear_path;
    }
    elsif ( $self-_has_path ) {
        return $self-_path;
    }
    else {
        my $path     = $self-uri-path;
        my $location = $self-base-path;
        $path =~ s/^(\Q$location\E)?//;
        $path =~ s/^\///;
        $self-_path($path);

        return $path;
    }
}




-- 
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/

[Catalyst] Forth Development Release of Catalyst 'Hamburg' now on CPAN

[John Napiorkowski]

This release of Catalyst tries to build more on our PSGI underpinnings.  Here's 
the changelog

 - JSON Data handler looks for both JSON::MaybeXS and JSON, and uses
whichever is first (prefering to find JSON::MaybeXS).  This should
improve compatibility as you likely already have one installed.
  - Fixed a warning in the server script (bokutin++)
  - We now populate various Plack $env keys in order to play nice with
downstream middleware or plack apps (and to reduce processing if
those keys already exist).  Keys added:
  - plack.request.query
  - plack.request.body
  - plack.request.merged
  - plack.request.http.body
  - If incoming input (from a POST or PUT) is not buffered, create the
buffer and set the correct psgi env keys to note this for downstream
psgi apps / middleware.  This should solve some issues where Catalyst
sucks up the body input but its not buffered so downstream apps can't
read it (for example FCGI does not buffer).  We now also try to make
sure the body content input is reset to the start of the filehandle
so that we are polite to downstream middleware /apps.
  - NEW FEATURE: Catalyst::Response can now pull response from a PSGI
specification response.  This makes it easier to host external Plack
applications under Catalyst.  See Catalyst::Response-from_psgi_response
  - NEW FEATURE: New configuration option 'use_hash_multivalue_in_request'
will populate $request methods 'parameters', 'body_parameters' and
'query_parameters' with an instance of Hash::MultiValue instead of a
HashRef.  This is used by Plack and is intended to reduce the need to
write defensive logic since you are never sure if an incoming parameter
is a scalar or arrayref.
  - NEW FEATURE: We now experimentally support Net::Async::HTTP::Server
and IO-Async based event loops.  Examples will follow.

I also blogged a few more details:

http://jjnapiorkowski.typepad.com/modern-perl/2013/10/perl-catalyst-hamburg-development-release-4-on-cpan.html


Please test it out, we are getting close to a stable release so if there's 
something you object to, now is the time to speak up.

cpanm Catalyst::Runtime --dev

jnap

___
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] Latest blog post on the status of Perl Catalyst 'Hamburg' and the next release

[John Napiorkowski]

Hey All,

I had a bit of time over lunch to finish up a blog about the status of Catalyst 
development:

http://jjnapiorkowski.typepad.com/modern-perl/2013/09/perl-catalyst-hamburg-status-and-the-future.html


So take a look if you are into volunteering or just want to stay up to date!

Also, we released the third development distribution leading to the next stable 
Catalyst release.  This release includes stuff like native JSON parsing, PSGI 
middleware awareness and a ton of fixes aimed at future-proofing the 
distribution, so you really should take a look and kick the tires.

https://metacpan.org/release/JJNAPIORK/Catalyst-Runtime-5.90049_003


Thanks!

John Napiorkowski___
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 versioning

[John Napiorkowski]

On Tue, Sep 17, 2013 at 10:12 AM, John Napiorkowski jjn1...@yahoo.com wrote:




People seem to get religious over how to version their API.  I doubt I'd want 
to take sides on this but here's how I think we could do both side (URL 
version and content type versioning 


Ya, I'm swayed by the Accept: header approach because in my mind 
/api/v1/account/123 and /api/v2/account/123 seems like different resources.   
(Well, I guess they are.)  So, the versions are lazy way to make a new 
resource location.


I think the REST people would say yes, but I know a lot of APIs use URL 
versioning since its easy (or seems so off the top) and I also know there are 
some people that think it is clearly and absolutely the correct way to do it (I 
worked with one in a previous job).  Luckily Catalyst chaining and method 
matching I think makes this easy to do off the top.

I still think having it 'restfully correct' in your core code and then using 
some middleware for compatibility with dumb clients is probably safe.  I 
generally think its not a bad idea to have middleware for your APIs that map 
file extensions to accept types and map a query param for versioning.  For 
example

http://mycompany.com/api/user.json?v=1

would map internally a request like

http:://mycompany.com/api/user
http-accept application/vnd.mycompany.user.v1+json

or thereabouts.


And even more so, seems like a dark path to go down.  Is just that individual 
resource versioned or is the entire API versioned?   And if it's the entire 
API, and the app needs to support multiple versions at the same time, then 
need a way for methods to fall-back to v1 when only a few methods change.


Or maybe the client would have to know which methods are v2 vs. v1 and 
pick-and-choose.



yeah its a dark path I also agree.  This is why content negotiation and 
hyperlink driven application state is the most forward looking, but its not 
easy to do right and honestly what most people think of when they think of a 
web API is just an endpoint that takes and servers json data.  Application 
state is not important to that view (and is the common view for APIs that are 
driving a bit of interactivity on a webpage.




Realistically, the problem that would likely come up is more related to client 
versioning where an old client cannot support some new feature of the API.   


The idea with rest is that this should be part of the content negotiation.  A 
client asks for a particular acceptable media type and the server decides how 
best to respond.  At least for the common server side negotiation.  


For example,  say a service has a method to fetch a widget and a method to 
list them.


GET /widget/123  # get widget 124
GET /widget  # list all widgets.


So, some client app is designed to list the widgets and then fetch them (for 
display or whatever).


Later, the service is upgraded and adds a new type of widget -- and that is a 
type that the existing old client app cannot support.



Ideally you could properly support this backwardly if possible.  Generally you 
have two types of changes, one where you add in stuff, and that should be such 
that old clients shouldn't die.  but sometimes you need to really change things 
and that can get you into trouble.  I've noted this is worse when people are 
lazy and just think serializing the data structure to json and sending it over 
the wire is enough.  Like you have a version one user that gets serialized to 
json like

{ 
  'name': 'john',
  'phone': '22',
}

but then you suddenly realize you need more than one phone per person and so 
you do:

{ 
  'name': 'john',
  'phone': [111,222,33]
}

and of course that breaks the client.  either you are stuck doing

{ 
  'name': 'john',
  'phone': '22',
  'additional_phones': [ ... ]
}

if you want to preserve backcompat or you change the version.  My thinking 
would be to do both really.

Of course this is a place where it would have been smart for the developer to 
have used an existing standard that already thought of all this stuff.  But 
what I've seen is APIs tend to be lazily modeled.  People oftern just 
serialized the output of a database query because the tools make that easy and 
it seems fast.  But down the road you get a lot of pain.

funny enough, this is a case where the 'bloated' xml might have been better

contact
  namejohn/name
  phone111/phone
  phone/phone
/contact

If the client is smart and parsing the xml with something like css style 
selectors (or even xpath) then both versions should work.  If you are lazy and 
using something like XML-Simple then of course it will go bang just like with 
json.  But again I'd be likely to want to use something like chard instead.


Does the service need to know what the client can support?


The client ideally would specify in the http accept header what they want and 
the server can decide if its willing to play, or pick up the marbles and go 
home :)


sub widget_GET

Re: [Catalyst] REST and versioning

[John Napiorkowski]

Bill,

Great questions and thoughts, I've inlined comment below.  Sorry for the odd 
formatting, yahoo email just seems to get worse and worse...


From: Bill Moseley mose...@hank.org
To: The elegant MVC web framework catalyst@lists.scsys.co.uk 
Sent: Tuesday, September 17, 2013 10:52 AM
Subject: [Catalyst] REST and versioning


I've once again used up an hour or so reading Stack Overflow and blog posts on 
REST API versioning.   (And the arguments for and against.)


Perhaps extending the discussion on how Catalyst supports REST:


https://github.com/perl-catalyst/CatalystX-Proposals-REStandContentNegotiation


I'm wondering if Catalyst might help in supporting API versions.  Somewhat 
similar to how Catalyst::Action::REST will call methods based on the HTTP 
method, perhaps call actions based on some version (provided by some means -- 
like a version in the path or in an Accept header).


People seem to get religious over how to version their API.  I doubt I'd want 
to take sides on this but here's how I think we could do both side (URL version 
and content type versioning


Catalyst::Action::REST helps keep the actions tidy by calling methods specific 
to each method  (foo_GET, foo_PUT).  Obviously, we could simply check if ( 
$req-method eq 'GET' ) but would end up with pretty ugly actions and no 
automatic Allow header.


With versions I'm concerned about that my foo_GET method will end up with a 
bunch of if ( $version  1.1 ) {} elsif ($version 1.0 ) ...


So, running with the C::Action::REST approach, something like:


sub foo_GET { ... }  # Default
sub foo_GET : Version( 1.1 ) { ... }  # Use if client requests version is 1.1


Frankly, seems like maintenance nightmare and Action explosion.   Where that 
version comes from (url, Accpet header) is often debated (see links).



So the most recent stable Catalyst lets you declare http method matching 
natively, so here's how I might do this with Cat out of the box (untested code, 
but should serve the idea)

Lets say you want to match a url like /api/$version/...

package Myapp::Web::Controller::API;

use base 'Catalyst::Controller';

sub start : ChainedParent
 PathPrefix CaptureArgs(0)
{
  my ($self, $ctx) = @_;
}

  sub version_one : Chained('start') PathPart('1') Args(0) { ... }

  sub version_two : Chained('start') PathPart('2') Args(0) { ... }

1;

package Myapp::Web::Controller::API::1;

use base 'Catalyst::Controller';

sub start : ChainedParent
 PathPrefix CaptureArgs(0)
{
  my ($self, $ctx) = @_;
}

1;

package Myapp::Web::Controller::API::2;

use base 'Catalyst::Controller';

sub start : ChainedParent
 PathPrefix CaptureArgs(0)
{
  my ($self, $ctx) = @_;
}

1;

I guess you could use this with Catalyst:Action::REST based controllers as 
well.  There's probably a few ways you could do this. but I'd probably combine 
chaining with different ontrollers for different versions so that I could best 
group the common functionality.

If you wanted to take the content negotiation approach, this would fit right 
into the proposal

package MyApp::Web::Controller::User; use base 'Catalyst::Controller'; sub 
example :Local Provides('application/vnd.mycompany.user.v1+json') { my ($self, 
$ctx) = @_; } 1;
In this case the Provides attribute could be setup to match and route as 
expected.  We might want to consider allowing Regexp or some subset of regexp 
so that you could match more than one type of incoming requested response (for 
example you might care about the application/vnd.mycompany.user.v1 but not the 
JSON bit, and might use some other strategy, as best to avoid repeating 
yourself a lot.



Any better ideas how to support versioning in Catalyst actions?



Well, I think the two general approaches are outlined here.  some people like 
to version as part of the URL, others follow a more purely restful approach and 
insist it is a matter for content negotiation.  I imagine you could have some 
plack middleware to smooth this over, for example to use content accept 
introspection in your code, but allow people to have some tag as a query param 
or similar.  We do this with the HTTP method matching for the newer Catalyst, 
since most browsers only support GET and POST method verbs, you can set a 
custom http header to map POST to PUT or DELETE.  This might be a good approach 
when dealing with clients that are not smart about doing true  RESTful 
negotiation.

It might also be useful to take a look at what some other frameworks in the 
RUby and Python world are doing.





The subject of versioning is a bit overwhelming.  Here's some starting points, 
if curious:


* 
http://stackoverflow.com/questions/389169/best-practices-for-api-versioning


* http://www.lexicalscope.com/blog/2012/03/12/how-are-rest-apis-versioned/


* http://www.subbu.org/blog/2008/05/avoid-versioning-please


* 

Re: [Catalyst] Catalyst starter template

[John Napiorkowski]

 From: David Schmidt davew...@gmx.at
To: The elegant MVC web framework catalyst@lists.scsys.co.uk 
Sent: Tuesday, September 3, 2013 2:48 AM
Subject: Re: [Catalyst] Catalyst starter template
 

Quite late but when I read your email again i had to think of this
other module which does a similiar thing and thought I'd mention it
here.

https://github.com/marcelgruenauer/CatalystX-Crudite

CatalystX-Crudite is a framework for writing Catalyst-based CMS web
applications. It includes out-of-the-box user and role management and
many starter templates. It builds upon CatalystX-Resource and
CatalystX-SimpleLogin.

In order for crudite_starter to work, you need to install this
distribution. The starter templates are stored as per-dist shared
files using File::ShareDir, so they can't be found from the
uninstalled repository. I hope to improve this in a later version.


I used File::ShareDir::ProjectDistDir

to solve the 'make F:SD work the same in both dev and when installed.  You can 
see an example of my usage here

https://metacpan.org/module/DBIx::Class::Migration::ShareDirBuilder


I think this is going to be a case of ' the more the merrier'.  I think we all 
agree the one size fits all approach dating back to the dawn of Catalyst just 
is not going to work over the longer term. So lets all experiment!  Keep 
sending you ideas and code to this thread and I will blog about them in a bit.

John


On 17 August 2013 21:21, Ynon Perek ynonpe...@gmail.com wrote:
 Hi All,

 After working with catalyst for some time, I found catalyst.pl too
 minimalistic for my needs.

 So I created a small script called ctstarter.pl that adds some features to
 the base template you get for a new project. Currently it adds:

 1. A starter DB and migrations (using DBIx::Class::Migration)
 2. Code and DB tables for managing users and roles (using
 CatalystX::SimpleLogin)
 3. A Twitter Bootstrap web view with templates (using
 Catalyst::Helper::View::Bootstrap)
 4. Two helper scripts: one to upgrade the DB and the other to reset admin
 password.

 You can find the source and usage instructions here:
 https://github.com/ynonp/ctstarter.pl

 Any feedbacks is appreciated.

 Cheers,
   Ynon



 ___
 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/




___
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/