Re: [Catalyst] Anybody who fancies some LWP poking ...
Hi!
On Thu, May 15, 2008 at 10:20:23AM -0400, John Goulah wrote:
Since these fix tests, will these modules get patched and released
with this applied?
Hm, actually I only notified Leon about the patches. I will also submit
the patches directly to Andy (for WWW::Mechanize)
--
#!/usr/bin/perl http://domm.plix.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC
* Zbigniew Lukasiak [EMAIL PROTECTED] [2008-05-16 06:25]: Hmm - frankly I have never thought out REST entirely - but I have the feeling that it is always better to be cautious (and you know - be liberal in what you receive). It’s like Turing completeness: you can do everything RESTfully that you can do in any other way, you just have to model the problem in a way that fits the constraints. REST doesn’t restrict what you can achieve at all, it just imposes some requirements on how you go about it. Some ideas top of my head: - a login method (the advantage would be that it does not need to redirect) I’m not sure I follow. You mean you want to have something like `/api/rest/cd/login`? And how do you avoid redirecting from that if you have `login` in the URI, which isn’t where the client needs to be looking at? - a search I tend to prefer expressing searches with query parameters… hm. - exposing some class data (as opposed to instance data) and maybe class methods? Example? I can’t quite imagine what you would want to do here. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC
On Fri, May 16, 2008 at 12:06 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: * Zbigniew Lukasiak [EMAIL PROTECTED] [2008-05-16 06:25]: Hmm - frankly I have never thought out REST entirely - but I have the feeling that it is always better to be cautious (and you know - be liberal in what you receive). It's like Turing completeness: you can do everything RESTfully that you can do in any other way, you just have to model the problem in a way that fits the constraints. REST doesn't restrict what you can achieve at all, it just imposes some requirements on how you go about it. Some ideas top of my head: - a login method (the advantage would be that it does not need to redirect) I'm not sure I follow. You mean you want to have something like `/api/rest/cd/login`? And how do you avoid redirecting from that if you have `login` in the URI, which isn't where the client needs to be looking at? Yeah - I think you are right, that was just a quick one. - a search I tend to prefer expressing searches with query parameters… hm. I understand that what you propose is '/cd?year=1968', is that right? I really don't know - but some people would prefer to do the search by POST, or might just like to have the uri as '/cd/search?year=1968'. - exposing some class data (as opposed to instance data) and maybe class methods? Example? I can't quite imagine what you would want to do here. Hmm - how about a help screen - conveniently at '/cd/help'? In short I think '/cd/instance/1' style of URIs is less interferring with how people think about structuring their uris. If you do '/cd/1' then you force them to choose one way of doing everything - even if it is a Turing complete way and you can do everything in that style. -- 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/
Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC
On Fri, 16 May 2008, Zbigniew Lukasiak wrote: - a search I tend to prefer expressing searches with query parameters… hm. I understand that what you propose is '/cd?year=1968', is that right? I really don't know - but some people would prefer to do the search by POST, or might just like to have the uri as '/cd/search?year=1968'. Why would anyone care about GET vs POST? I guarantee most users don't care. If you mean they want to use a form, that has nothing to do with the method. Forms can submit GET requests. The URI you propose could be RESTful, if you think of search as a noun, maybe short for search results. Example? I can't quite imagine what you would want to do here. Hmm - how about a help screen - conveniently at '/cd/help'? Again, could be RESTful. One part of REST is that URIs contain nouns, period. The type of nouns, the path hierarchy, all that is irrelevant, the key is that the URI never contains a verb like submit or edit. Note that edit_form is a noun, and is perfectly RESTful, and _necessary_ if you plan to have browsers interact with a set of RESTful URIs. -dave /*== VegGuide.Org Your guide to all that's veg ==*/___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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: RFC: Catalyst::Controller::REST::DBIC
Hi, I don't know what to do with this thread. On Fri, May 16, 2008 at 6:31 PM, Dave Rolsky [EMAIL PROTECTED] wrote: On Fri, 16 May 2008, Zbigniew Lukasiak wrote: - a search I tend to prefer expressing searches with query parameters… hm. I understand that what you propose is '/cd?year=1968', is that right? I really don't know - but some people would prefer to do the search by POST, or might just like to have the uri as '/cd/search?year=1968'. Why would anyone care about GET vs POST? I guarantee most users don't care. If you mean they want to use a form, that has nothing to do with the method. Forms can submit GET requests. It might need to be a POST if you need to download a file as one of the search arguments (for example for searching for a similar picture). The URI you propose could be RESTful, if you think of search as a noun, maybe short for search results. OK - what I was argumenting about is that sometimes it is convenient to have an URI like that. The other part of the argument is that if you have an uri '/cd/search' - then you should not use '/cd/1' to retrieve the CD object - because then you mix data with commands (id with actions). Example? I can't quite imagine what you would want to do here. Hmm - how about a help screen - conveniently at '/cd/help'? Again, could be RESTful. Great. I am only argumenting that sometimes you need such an uri - see above. One part of REST is that URIs contain nouns, period. The type of nouns, the path hierarchy, all that is irrelevant, the key is that the URI never contains a verb like submit or edit. Note that edit_form is a noun, and is perfectly RESTful, and _necessary_ if you plan to have browsers interact with a set of RESTful URIs. As above. -- 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/
Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC
On Fri, 16 May 2008, Zbigniew Lukasiak wrote: Why would anyone care about GET vs POST? I guarantee most users don't care. If you mean they want to use a form, that has nothing to do with the method. Forms can submit GET requests. It might need to be a POST if you need to download a file as one of the search arguments (for example for searching for a similar picture). I think you mean _upload_, right? The URI you propose could be RESTful, if you think of search as a noun, maybe short for search results. OK - what I was argumenting about is that sometimes it is convenient to have an URI like that. The other part of the argument is that if you have an uri '/cd/search' - then you should not use '/cd/1' to retrieve the CD object - because then you mix data with commands (id with actions). I have no strong opinion on this. I was just pointing out which URIs were RESTful and which weren't. -dave /*== VegGuide.Org Your guide to all that's veg ==*/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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: RFC: Catalyst::Controller::REST::DBIC
I'm sorry but something just feels wrong about your approach - feels like your mixing at matching REST a UI on top. Get the REST part down first, then worry about something the browser can see on top of it. I don't think you should let 'what a browser can see' to influence the REST design. Get the primitives, GET to search, POST to insert, PUT to update, and DELETE to remove working. Then you, or someone else, can layer something nice for the browser on top of that. Letting what the 'browser can see (or do)' influence your RESTful design is just a bad idea I think if you're trying to create a REST controller. Now if you wanted to create just a generic CRUD controller that sort of looked like REST or borrowed some ideas from it, then fine. I guess the problem myself ( others perhaps) are having is calling what I think you're proposing 'REST'. Mark Dave Rolsky wrote: On Fri, 16 May 2008, Zbigniew Lukasiak wrote: Why would anyone care about GET vs POST? I guarantee most users don't care. If you mean they want to use a form, that has nothing to do with the method. Forms can submit GET requests. It might need to be a POST if you need to download a file as one of the search arguments (for example for searching for a similar picture). I think you mean _upload_, right? The URI you propose could be RESTful, if you think of search as a noun, maybe short for search results. OK - what I was argumenting about is that sometimes it is convenient to have an URI like that. The other part of the argument is that if you have an uri '/cd/search' - then you should not use '/cd/1' to retrieve the CD object - because then you mix data with commands (id with actions). I have no strong opinion on this. I was just pointing out which URIs were RESTful and which weren't. -dave /*== VegGuide.Org Your guide to all that's veg ==*/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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[2]: [Catalyst] uri_for() doesn't encode to utf8 first argument
Hello, J..
You write 16 мая 2008 г., 4:27:07:
JS On Thu, May 15, 2008 at 11:50 PM, Dmitriy S. Sinyavskiy [EMAIL PROTECTED]
wrote:
So what about my patch and test?
Is it right or someone can correct it?
The silence is here for a week or more (
JS Jonathan Rockway asked you to regenerate without whitespace changes.
JS Just waiting on that from you to properly review it.
JS -J
It strange I haven't got received letter with this...may be deleted
by antispam (
Nevertheless I've done it now:
Index: Catalyst.pm
===
--- Catalyst.pm (revision 7759)
+++ Catalyst.pm (working copy)
@@ -948,10 +948,12 @@
my $params =
( scalar @args ref $args[$#args] eq 'HASH' ? pop @args : {} );
+$path =~ s!/+!/!g; # strip extra slashes '///'
+unshift(@args, split('/', $path));
carp uri_for called with undef argument if grep { ! defined $_ } @args;
s/([^$URI::uric])/$URI::Escape::escapes{$1}/go for @args;
-unshift(@args, $path);
+
unless (defined $path $path =~ s!^/!!) { # in-place strip
my $namespace = $c-namespace;
--
dreelmailto:[EMAIL PROTECTED]
Dmitriy S. Sinyavskiy
Web-developerPerl, Catalyst, MSSQL
FGUE EZANTelecommunication, data transfer networks and
devices.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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 ...
2008/5/15 John Goulah [EMAIL PROTECTED]: Since these fix tests, will these modules get patched and released with this applied? Thanks for the investigation Thomas, but I'd like to hold off until someone actually fixes the real problems and quietens the warnings using understanding. For now just downgrade LWP. Regards, Leon ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] uri_for() doesn't encode to utf8 first argument
* On Sat, May 17 2008, Dmitriy S. Sinyavskiy wrote:
It strange I haven't got received letter with this...may be deleted
by antispam (
Yes, your mailserver rejected my reply. However, the list did receive
it.
Nevertheless I've done it now:
Index: Catalyst.pm
===
--- Catalyst.pm (revision 7759)
+++ Catalyst.pm (working copy)
@@ -948,10 +948,12 @@
my $params =
( scalar @args ref $args[$#args] eq 'HASH' ? pop @args : {} );
+$path =~ s!/+!/!g; # strip extra slashes '///'
+unshift(@args, split('/', $path));
carp uri_for called with undef argument if grep { ! defined $_ } @args;
s/([^$URI::uric])/$URI::Escape::escapes{$1}/go for @args;
-unshift(@args, $path);
+
unless (defined $path $path =~ s!^/!!) { # in-place strip
my $namespace = $c-namespace;
OK, but it looks like you forgot the tests. :) However, I think the
patch is sound. Please check that things like:
uri_for('/controller/ほげ')
*click that link*
dispatch correctly, though.
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/
