Re: [Catalyst] Anybody who fancies some LWP poking ...
On Mon, May 5, 2008 at 11:12 PM, Daniel McBrearty [EMAIL PROTECTED] wrote: If you don't want new versions of modules, then *don't upgrade them*. and when you (or a total newcomer to the language/framework) do a *new* install? and the latest greatest is broken right out of the box? looks great, hey? The code may have been broken - but not so broken that it couldn't work (acceptably) well in the last N releases. But, hey, all of a sudden, it must be changed *now*. There is a proposal from Michael Schwern for a Debian-like releases (unstable, test, stable and old-stable) http://www.perlfoundation.org/perl5/index.cgi?cpan_stability_project . I just thought this might be interesting to you. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Basic CRUD Tutorial
I'm new to Catalyst, and am working my way through the tutorial. I'm
on the BasicCRUD section, and something is not behaving as it
should. I've gotten to the end of the FORMLESS SUBMISSION section,
and entering the URL
http://localhost:3000/books/url_create/TCPIP_Illustrated_Vol-2/5/4
works as advertised, entering an appropriate record into the database.
However, the link for Return to list (coming from the
'create_done.tt2' template) points to itself
(http://localhost:3000/books/url_create/TCPIP_Illustrated_Vol-2/5/4)
rather than (http://localhost:3000/books/list).
The 'create_done.tt2' template includes:
a href=[% Catalyst.uri_for('/books/list') %]Return to list/a/p
However, this function doesn't seem to be building the appropriate
URI. I'm on Mac OS X 10.5.2, and built Catalyst yesterday from CPAN
using the system Perl.
I can't rule out that I did something silly, but I went through this
twice, and twice got the same issue.
Does anyone know what might be the issue.
Thanks,
-albert
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] Basic CRUD Tutorial
On 6 May 2008, at 22:16, Albert Vernon Smith wrote:
I'm new to Catalyst, and am working my way through the tutorial. I'm
on the BasicCRUD section, and something is not behaving as it
should. I've gotten to the end of the FORMLESS SUBMISSION section,
and entering the URL
http://localhost:3000/books/url_create/TCPIP_Illustrated_Vol-2/5/4
works as advertised, entering an appropriate record into the database.
However, the link for Return to list (coming from the
'create_done.tt2' template) points to itself
(http://localhost:3000/books/url_create/TCPIP_Illustrated_Vol-2/5/4)
rather than (http://localhost:3000/books/list).
The 'create_done.tt2' template includes:
a href=[% Catalyst.uri_for('/books/list') %]Return to list/a/p
However, this function doesn't seem to be building the appropriate
URI. I'm on Mac OS X 10.5.2, and built Catalyst yesterday from CPAN
using the system Perl.
I can't rule out that I did something silly, but I went through this
twice, and twice got the same issue.
Please checkout the reference implementation for the tutorial from:
svn checkout http://dev.catalyst.perl.org/repos/Catalyst/tags/
examples/Tutorial/MyApp/5.7/
If the problem still exists then there's a problem with the code, or
your catalyst install. Please let us know if the reference
implementation is also doing the wrong thing.
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/
Re: [Catalyst] Basic CRUD Tutorial
The reference implementation works as it should. There are not diff
changes between my implementation and the tutorial for both
lib/MyApp/Controller/Books.pm, root/src/books/create_done.tt2.
-albert
On Tue, May 6, 2008 at 12:25 PM, Kieren Diment [EMAIL PROTECTED] wrote:
On 6 May 2008, at 22:16, Albert Vernon Smith wrote:
I'm new to Catalyst, and am working my way through the tutorial. I'm
on the BasicCRUD section, and something is not behaving as it
should. I've gotten to the end of the FORMLESS SUBMISSION section,
and entering the URL
http://localhost:3000/books/url_create/TCPIP_Illustrated_Vol-2/5/4
works as advertised, entering an appropriate record into the database.
However, the link for Return to list (coming from the
'create_done.tt2' template) points to itself
(http://localhost:3000/books/url_create/TCPIP_Illustrated_Vol-2/5/4)
rather than (http://localhost:3000/books/list).
The 'create_done.tt2' template includes:
a href=[% Catalyst.uri_for('/books/list') %]Return to list/a/p
However, this function doesn't seem to be building the appropriate
URI. I'm on Mac OS X 10.5.2, and built Catalyst yesterday from CPAN
using the system Perl.
I can't rule out that I did something silly, but I went through this
twice, and twice got the same issue.
Please checkout the reference implementation for the tutorial from:
svn checkout
http://dev.catalyst.perl.org/repos/Catalyst/tags/examples/Tutorial/MyApp/5.7/
If the problem still exists then there's a problem with the code, or your
catalyst install. Please let us know if the reference implementation is
also doing the wrong thing.
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/
Re: [Catalyst] Basic CRUD Tutorial
I have figured out the issue.
Since the reference installation worked, I obviously had no grander
software problem. I then replaced files one-by-one to find the issue.
By doing that, I could see that the file lib/MyApp/View/TT.pm was
missing a config definition for
CATALYST_VAR
Looking at the output from:
script/myapp_create.pl view TT TTSite
I can see the line was not added into this file. So, if I add
CATALYST_VAR, I can fix the issue updating to:
__PACKAGE__-config({
CATALYST_VAR = 'Catalyst',
...
Now, being new around here, I'm not sure if the non-inclusion of
CATALYST_VAR in VIew/TT.pm from TTSite output is a bug or a
feature. In any case, it does show an incosistecy between the
tutorial documentation and what is happening. I am working with
Catalyst 5.7012.
-albert
On Tue, May 6, 2008 at 1:09 PM, Albert Vernon Smith [EMAIL PROTECTED] wrote:
The reference implementation works as it should. There are not diff
changes between my implementation and the tutorial for both
lib/MyApp/Controller/Books.pm, root/src/books/create_done.tt2.
-albert
On Tue, May 6, 2008 at 12:25 PM, Kieren Diment [EMAIL PROTECTED] wrote:
On 6 May 2008, at 22:16, Albert Vernon Smith wrote:
I'm new to Catalyst, and am working my way through the tutorial. I'm
on the BasicCRUD section, and something is not behaving as it
should. I've gotten to the end of the FORMLESS SUBMISSION section,
and entering the URL
http://localhost:3000/books/url_create/TCPIP_Illustrated_Vol-2/5/4
works as advertised, entering an appropriate record into the database.
However, the link for Return to list (coming from the
'create_done.tt2' template) points to itself
(http://localhost:3000/books/url_create/TCPIP_Illustrated_Vol-2/5/4)
rather than (http://localhost:3000/books/list).
The 'create_done.tt2' template includes:
a href=[% Catalyst.uri_for('/books/list') %]Return to list/a/p
However, this function doesn't seem to be building the appropriate
URI. I'm on Mac OS X 10.5.2, and built Catalyst yesterday from CPAN
using the system Perl.
I can't rule out that I did something silly, but I went through this
twice, and twice got the same issue.
Please checkout the reference implementation for the tutorial from:
svn checkout
http://dev.catalyst.perl.org/repos/Catalyst/tags/examples/Tutorial/MyApp/5.7/
If the problem still exists then there's a problem with the code, or your
catalyst install. Please let us know if the reference implementation is
also doing the wrong thing.
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/
Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC
On 05/05/2008 02:33 PM, luke saunders wrote: On Mon, May 5, 2008 at 7:28 PM, Peter Karman [EMAIL PROTECTED] wrote: On 05/05/2008 12:16 PM, J. Shirley wrote: The discussions about a better CRUD base class with REST and RPC adapters is obviously the better (best?) solution, but I also think there will be significant disagreement between appropriate URI resource conventions (as my exchange with zby is an example of.) As has been mentioned before, there is an existing REST + CRUD implementation already on CPAN: http://search.cpan.org/dist/CatalystX-CRUD/lib/CatalystX/CRUD/REST.pm Out of interest, why did you not use Catalyst::Controller::REST here? A few reasons. One, the CRUD::REST primary design goal is to allow you to simply change your @ISA list in order to switch from RPC to REST style URIs. If you are already using a CX::CRUD::Controller-based class, you just put CX::CRUD::REST at the front of your @ISA list and voila. That goal would have required a bit more method aliasing and other hackery in order to support the *_VERB API in C::C::REST. Two, the C::C::REST module (and related Action class) have a lot of support for automatic serialization. CX::CRUD is completely agnostic about response type. Maybe it shouldn't be. But it is. Three, C::C::REST does not have real-world browser HTTP use in mind, as REST::ForBrowsers does. That's not bad; it's just more pure imo. CX::CRUD tries to support both, and as of yesterday, svn has support for the 'x-tunneled-method' param like REST::ForBrowsers does. Four, I didn't need the overhead. :) Having said all that, I expect that C::C::REST could work well with CX::CRUD::REST, and I'd love to see a patch that implements it, bearing in mind the points above. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Anybody who fancies some LWP poking ...
On Mon, May 05, 2008 at 03:46:09PM -0500, Jonathan Rockway wrote: * On Mon, May 05 2008, Daniel McBrearty wrote: tht's reasonable. what is not so reasonable is suddenly deciding that you are going to *croak* on something which you didn't even test for with previous releases. A warning would have been fine, at least for half a year or so. In that case we would be having this exact discussion 6 months from now. Breaking broken code is always good. +1 for HTTP::Message. Not when you're that far down the dependency chain. Anyway, this thread was started to try and help get the fallout fixed, not for you to posture. Either write code, shut up, or start a separate thread so I can safely killfile it. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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: Catalyst, utf8 in form element type text - Solved
On Tue, May 06, 2008 at 09:04:38AM +0200, Aristotle Pagaltzis wrote: * Bill Moseley [EMAIL PROTECTED] [2008-05-05 21:40]: form tags should have accept-charset Browsers tend to ignore that and send the form data in the same encoding as the page that the form was on. Browsers is a bit general. Yes, IE will use the HTTP Content-Type header over accpet-charset in the form tag (and over any meta tag as well). Firefox 2 will use accept-charset (even if its different from the HTTP charset). So, it's good to have an accept-charset and make sure it matches the page's Content-Type charset. At least, that's how I remember it. other screwy things. Overall this is an area of much hatefulness. For best results, http://search.cpan.org/perldoc?Encode::HEBCI is the way to go. But most of the time it’s overkill, since once you get your pages to be served as UTF-8 properly, you can pretty much forget the issue. That's what I do -- I set the Content-Type, meta http-equiv, and accept-charset on the form all to utf-8. Any browser that screws that up likely isn't supported in other ways, too. -- Bill Moseley [EMAIL PROTECTED] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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[2]: [Catalyst] uri_for() doesn't encode to utf8 first argument
The -diff
Index: Catalyst.pm
===
--- Catalyst.pm (revision 7629)
+++ Catalyst.pm (working copy)
@@ -54,7 +54,7 @@
__PACKAGE__-mk_classdata($_)
for qw/components arguments dispatcher engine log dispatcher_class
- engine_class context_class request_class response_class stats_class
+ engine_class context_class request_class response_class stats_class
setup_finished/;
__PACKAGE__-dispatcher_class('Catalyst::Dispatcher');
@@ -112,30 +112,30 @@
### in lib/MyApp.pm
use Catalyst qw/-Debug/; # include plugins here as well
-
+
### In lib/MyApp/Controller/Root.pm (autocreated)
sub foo : Global { # called for /foo, /foo/1, /foo/1/2, etc.
my ( $self, $c, @args ) = @_; # args are qw/1 2/ for /foo/1/2
$c-stash-{template} = 'foo.tt'; # set the template
# lookup something from db -- stash vars are passed to TT
-$c-stash-{data} =
+$c-stash-{data} =
$c-model('Database::Foo')-search( { country = $args[0] } );
if ( $c-req-params-{bar} ) { # access GET or POST parameters
$c-forward( 'bar' ); # process another action
-# do something else after forward returns
+# do something else after forward returns
}
}
-
+
# The foo.tt TT template can use the stash data from the database
[% WHILE (item = data.next) %]
[% item.foo %]
[% END %]
-
+
# called for /bar/of/soap, /bar/of/soap/10, etc.
sub bar : Path('/bar/of/soap') { ... }
# called for all actions, from the top-most controller downwards
-sub auto : Private {
+sub auto : Private {
my ( $self, $c ) = @_;
if ( !$c-user_exists ) { # Catalyst::Plugin::Authentication
$c-res-redirect( '/login' ); # require login
@@ -143,9 +143,9 @@
}
return 1; # success; carry on to next action
}
-
+
# called after all actions are finished
-sub end : Private {
+sub end : Private {
my ( $self, $c ) = @_;
if ( scalar @{ $c-error } ) { ... } # handle errors
return if $c-res-body; # already have a response
@@ -155,20 +155,20 @@
### in MyApp/Controller/Foo.pm
# called for /foo/bar
sub bar : Local { ... }
-
+
# called for /blargle
sub blargle : Global { ... }
-
+
# an index action matches /foo, but not /foo/1, etc.
sub index : Private { ... }
-
+
### in MyApp/Controller/Foo/Bar.pm
# called for /foo/bar/baz
sub baz : Local { ... }
-
+
# first Root auto is called, then Foo auto, then this
sub auto : Private { ... }
-
+
# powerful regular expression paths are also possible
sub details : Regex('^product/(\w+)/details$') {
my ( $self, $c ) = @_;
@@ -249,7 +249,7 @@
environment settings override the application, with MYAPP_STATS having the
highest priority.
-e.g.
+e.g.
use Catalyst qw/-Stats=1/
@@ -320,8 +320,8 @@
=head2 $c-detach()
-The same as Cforward, but doesn't return to the previous action when
-processing is finished.
+The same as Cforward, but doesn't return to the previous action when
+processing is finished.
When called with no arguments it escapes the processing chain entirely.
@@ -348,7 +348,7 @@
$c-stash-{foo} = $bar;
$c-stash( { moose = 'majestic', qux = 0 } );
$c-stash( bar = 1, gorch = 2 ); # equivalent to passing a hashref
-
+
# stash is automatically passed to the view for use in a template
$c-forward( 'MyApp::View::TT' );
@@ -456,7 +456,7 @@
return $comp;
}
-# Find possible names for a prefix
+# Find possible names for a prefix
sub _comp_names {
my ( $c, @prefixes ) = @_;
@@ -528,7 +528,7 @@
Any extra arguments are directly passed to ACCEPT_CONTEXT.
-If the name is omitted, it will look for
+If the name is omitted, it will look for
- a model object in $c-stash{current_model_instance}, then
- a model name in $c-stash-{current_model}, then
- a config setting 'default_model', or
@@ -542,7 +542,7 @@
@args )
if $name;
if (ref $c) {
-return $c-stash-{current_model_instance}
+return $c-stash-{current_model_instance}
if $c-stash-{current_model_instance};
return $c-model( $c-stash-{current_model} )
if $c-stash-{current_model};
@@ -573,7 +573,7 @@
Any extra arguments are directly passed to ACCEPT_CONTEXT.
-If the name is omitted, it will look for
+If the name is omitted, it will look for
- a view object in $c-stash{current_view_instance}, then
- a view name in $c-stash-{current_view}, then
- a config setting 'default_view', or
@@ -587,7 +587,7 @@
@args )
if $name;
if (ref $c) {
-return $c-stash-{current_view_instance}
+return $c-stash-{current_view_instance}
if $c-stash-{current_view_instance};
return
Re: [Catalyst] uri_for() doesn't encode to utf8 first argument
* On Tue, May 06 2008, Dmitriy S. Sinyavskiy wrote:
The -diff
Index: Catalyst.pm
===
Please regenerate this diff without the whitespace changes. It is
completely unreadable in the current form.
Examples:
- engine_class context_class request_class response_class stats_class
+ engine_class context_class request_class response_class stats_class
-
+
-$c-stash-{data} =
+$c-stash-{data} =
These spurious changes fuck up the history (when we apply the patch),
and they make it extremely difficult to review your changes.
GNU diff accepts an --ignore-space-change option that should remove
these extra changes.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] FastCGI: incomplete headers (0 bytes) received from server
I'm having an issue with my Catalyst app but I can only get it to break about 1 in 100 tries. The error log shows: [Tue May 06 11:02:46 2008] [error] [client 12.37.36.66] FastCGI: comm with server /u/lxlib/BookingEngine/script/bookingengine_fastcgi.pl aborted: idle timeout (60 sec), referer: http://be.genares.net/11 [Tue May 06 11:02:46 2008] [error] [client 12.37.36.66] FastCGI: incomplete headers (0 bytes) received from server /u/lxlib/BookingEngine/script/bookingengine_fastcgi.pl, referer: http://be.genares.net/11 The page does not show an error, but a new session is created instead of using the existing session. I'm using Session::State::Cookie, Session::State::URI, Session::Store::DBIC. All are on the latest versions. Any help would be appreciated. Ryan Pack Programmer Genares Worldwide Reservations P. 817-722-2834 F. 817-442-0600 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] FastCGI: incomplete headers (0 bytes) received from server
* On Tue, May 06 2008, Ryan Pack wrote: I?m having an issue with my Catalyst app but I can only get it to break about 1 in 100 tries. The error log shows: [Tue May 06 11:02:46 2008] [error] [client 12.37.36.66] FastCGI: comm with server /u/lxlib/BookingEngine/script/bookingengine_fastcgi.pl aborted: idle timeout (60 sec), referer: http://be.genares.net/11 [Tue May 06 11:02:46 2008] [error] [client 12.37.36.66] FastCGI: incomplete headers (0 bytes) received from server /u/lxlib/BookingEngine/script/ bookingengine_fastcgi.pl, referer: http://be.genares.net/11 The page does not show an error, but a new session is created instead of using the existing session. I?m using Session::State::Cookie, Session::State::URI, Session::Store::DBIC. All are on the latest versions. Any help would be appreciated. Do you have requests that are taking more than a minute? It looks like your frontend server is assuming the Catalyst app died, when in reality it might just be taking a long time. I'm not sure what would cause the session stuff to behave differently. Probably time to add some $c-log-debug messages to your app in key places. Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Dispatching with Chained vs HTTP method
On 07/05/2008, at 11:05 AM, Toby Corkindale wrote: Ah, I was thinking of transactions vs a REST API, eg: PUT /user/1234/account_balance?subtract=1 POST /user/4567/account_balance?add=1 Since those are two separate HTTP requests, and REST specifically states you cannot maintain state on the server, how would you perform those two operations inside a transaction? (My solution is to implement it in one request, like: PUT /user/1234/money_transfer?user=4567;amount=1 However that is not CRUD-like, nor a direct mapping of DBIC functionality to REST) The solution suggested in Restful Web Services is to POST to a factory resource which creates you with a transaction resource. e.g. POST /transactions/account-transfer returns Location: / transactions/account-transfer/11a5, where the 11a5 is a unique transaction identifier. Then PUT /transactions/account-transfer/11a5/accounts/checking/11, where 11 is the account identifier. The body carries the transaction details, in the example the balances are adjusted absolutely, i.e. balance=150. A similar PUT is sent for the other account. Once the required components of the transaction have been PUT it is possible to rollback by DELETEing the transaction resource or commit it by putting committed=true to the resource. While seeming a bit fiddly, it does keep the state on the client and allows the client to make (at least some of) the commit / rollback decision rather than (only) the server. -- 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/
