Re: [Catalyst] Re: How to print/display some data in an end action
Aristotle Pagaltzis wrote:
Hi Emmanuel,
* Emmanuel Quevillon [EMAIL PROTECTED] [2008-04-30 16:30]:
Maybe I can clarify the situation.
OK; but all of that was already reasonably obvious. The issue is,
you are doing something to forward to ::View::TT automatically at
the end of a request. Catalyst does not do that by itself. So the
problem would have to be fixed there. First question: what does
the `end` action in your Root controller do? Do you have any other
`end`s? If so, what do those do?
Regards,
Hi Aristotle,
My Root::end action is simply :
sub end : ActionClass(RenderView) { }
And I don't have any other end action in other controllers.
Regards
Emmanuel
--
-
Emmanuel Quevillon
Biological Software and Databases Group
Institut Pasteur
+33 1 44 38 95 98
tuco at_ pasteur dot fr
-
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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: How to print/display some data in an end action
Aristotle Pagaltzis wrote:
* Andreas Marienborg [EMAIL PROTECTED] [2008-05-01 10:50]:
No point in forwarding to end, since that is done automaticly.
In which case it would run twice, actually. But maybe he has a
more specific `end` action and so forwarding to ::C::Root::end
is actually a useful thing to do in his app. As I said, we have
seen too little of the code to make any meaningful suggestions.
Regards,
Hi Aristotle,
You're right, Root/end action is called twice :
| /auto | 0.002877s |
| /admin/auto | 0.001081s |
| /admin/display | 0.136538s |
| - MycoBiblio::View::TT-process
| 0.098517s |
| /end| 0.000431s |
...
...
| /auto | 0.002108s |
| /admin/auto | 0.000884s |
| /admin/rg | 0.053757s |
| /end| 0.000521s |
We see that in the first call list, the template is well
called and process correctly as asked in the 'display' code
action method.
Then the first 'end' call.
Then as in the 'execute' method from C::A::RenderView, it is
forwarded to the appropriate view, so in 'display' to
'C::V::TT'.
Then, in the second 'end' call, nothing is forwarded to any
view as it is asked in C::A::RenderView 'execute' action.
So this is the behavior I wanted :) even if 'end' is called
twice.
From C::A::RenderView
-
sub execute {
my $self = shift;
my ($controller, $c ) = @_;
$self-NEXT::execute( @_ );
...
...
return 1 if $c-req-method eq 'HEAD';
return 1 if defined $c-response-body length(
$c-response-body );
return 1 if scalar @{ $c-error }
!$c-stash-{template};
return 1 if $c-response-status =~ /^(?:204|3\d\d)$/;
my $view = $c-view()
|| die Catalyst::Action::RenderView could not find
a view to forward to.\n;
$c-forward( $view );
};
--
-
Emmanuel Quevillon
Biological Software and Databases Group
Institut Pasteur
+33 1 44 38 95 98
tuco at_ pasteur dot fr
-
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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: How to print/display some data in an end action
On 5 May 2008, at 16:46, Emmanuel Quevillon wrote:
Aristotle Pagaltzis wrote:
Hi Emmanuel,
* Emmanuel Quevillon [EMAIL PROTECTED] [2008-04-30 16:30]:
Maybe I can clarify the situation.
OK; but all of that was already reasonably obvious. The issue is,
you are doing something to forward to ::View::TT automatically at
the end of a request. Catalyst does not do that by itself. So the
problem would have to be fixed there. First question: what does
the `end` action in your Root controller do? Do you have any other
`end`s? If so, what do those do?
Regards,
Hi Aristotle,
My Root::end action is simply :
sub end : ActionClass(RenderView) {
my ($self, $c) = @_;
my $whatever = do_stuff()
$c-stash-{whatever} = $whatever
}
And I don't have any other end action in other controllers.
Regards
Emmanuel
--
-
Emmanuel Quevillon
Biological Software and Databases Group
Institut Pasteur
Quesque c'es faire l'institute pasteur avec 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] Re: RFC: Catalyst::Controller::REST::DBIC
On Mon, May 5, 2008 at 1:20 AM, Patrick Donelan [EMAIL PROTECTED] wrote: No, but how you provide an alternative to full RESTness for clients that don't handle the full range of HTTP verbs -is- a matter for discussion. Which clients are we talking about here? I did a quick google search and could only find an off-hand remark along the lines of in 2006 safari had poor support for REST verbs. I'm interested because in my own personal experience I haven't run into any problems generating PUT/POST/GET/DELETE with IE/FF/Opera browsers. Or are you talking about the inability to specify anything other than GET or POST as a form method? I'm afraid I can't remember exactly, it was around two years ago and we needed to fire PUT requests using XHR in JS using Dojo and it just wasn't happening. Dojo has changed dramatically since then and now has an xhrPut method so I expect whatever the problem has been addressed. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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
* Matt S Trout [EMAIL PROTECTED] [2008-05-04 16:25]: On Sun, May 04, 2008 at 09:10:56AM +0200, Aristotle Pagaltzis wrote: * luke saunders [EMAIL PROTECTED] [2008-05-04 02:50]: Also it doesn't distinguish between POST, PUT, DELETE and GET HTTP requests favouring instead entirely separate endpoints, but that's up for discussion. Putting the verb in the URI is RPC, not REST. This is not a matter of discussion. No, but how you provide an alternative to full RESTness for clients that don't handle the full range of HTTP verbs -is- a matter for discussion. Or at least a matter for determining an architecture that allows you to use whatever alternative you like. Please don't let your obsessive REST advocacy blind you to pragmatic software development issues; it's starting to get boring. You are reading things into my post that aren’t there. I made a statement of fact about what REST is; there was no advocacy either way in it. Still, since you mention pragmatism, let me point out that I do not consider purely RESTful design an an ivory-tower pursuit; it has practical benefits, and if you understand what REST is and don’t dismiss the idea of complying with it out of hand, it’s not hard to come up with workarounds for limited clients, such as the excellent Catalyst::Request::REST::ForBrowsers. I have been thinking about changes I’d like to propose to Catalyst::Action::REST to make it less verbose in some circumstances, and I have some half-baked ideas regarding emulation of HTTP Auth using cookies. When I’m done I want to tie all this together by way of a controller base class. If anyone is thinking along the same lines, I shall be happy to talk in private, but before I run my mouth off too much in public I want to have code to show. None of this, btw, is specific to a CRUD interface, but could be a great foundation to build one with. 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] So, what do we want in the -next- book?
On Sun, May 04, 2008 at 07:28:46PM +0200, Marcus Ramberg wrote: On 4. mai. 2008, at 15.39, Matt S Trout wrote: Then again, I originally learned Catalyst by reading the source; took me about 8 hours. The only thing that confused me was the dispatcher, which is why I rewrote most of it later when I became a contrib :) And now it confuses the rest of us instead ;-) One day I'll finish rewriting the damn thing and it might actually make sense again. -- 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] modperl 1.3 wierdness
On Sun, May 04, 2008 at 11:19:24PM +1000, Toby Corkindale wrote:
On Sat, May 03, 2008 at 11:22:49PM +0100, Matt S Trout wrote:
On Mon, Apr 28, 2008 at 11:30:53AM +1000, Toby Corkindale wrote:
Unfortunately due to somewhat unusual app deployment tactics here, apps
get
installed manually, into their own little area, along with their
required
perl dependencies, thus losing the Makefile.PL, but also requiring that
the
config file lived in the same non-standard location.
How about using
__PACKAGE__-config(
'Plugin::ConfigLoader' = {
file = __PACKAGE__-path_to(...)
}
);
or setting an environment variable?
The location varies depending on build version and status, but could have been
solved with the env variable part combined with the loader options..
But at the time it was 8pm at night and I wanted to go home, and hacking up a
little DIY loader was quicker than trying to figure out what was going wrong
with the plugin.. You know how it gets sometimes?
Yes, but I've had hacked the app back out of whatever broken-ass deployment
system can't handle a checkout dir -and- doesn't use 'make install' so
Catalyst's find the config when installed as a normal perl/CPAN dist logic
didn't work either. Because really, if it can't handle a straight CPAN
module properly deploying perl stuff using it ain't a good idea.
--
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: How to print/display some data in an end action
On Wed, Apr 30, 2008 at 04:16:00PM +0200, Emmanuel Quevillon wrote:
Aristotle Pagaltzis wrote:
* Emmanuel Quevillon [EMAIL PROTECTED] [2008-04-30 15:05]:
Catalyst always try to wrap the action result 'display' into a
template.
No, it doesn’t. If that happens in your app, then you have set it
up to happen like that. But the code you pasted does not include
that portion, so no one will be able tell you what to do instead.
Regards,
Thanks Aristotle,
Maybe I can clarify the situation.
In controller Foo I have 2 methods:
sub bar : LocalRegex ('^(\d+)$') {
my($self, $c) = @_;
my $id = $c-req-captures-[0];
$c-detach(qw/Root _softwareError/,
[An id is required to get related genes.])
unless $id;
$c-stash()-{url} = $c-uri_for(/admin/rg/$id);
$c-stash()-{template} = 'admin/relatedgenes.tt2';
Delete this line, your end action will already do it.
$c-detach('View::TT');
}
sub rg : Local : Args(1) {
my($self, $c) = @_;
my $id = $c-req-args-[0];
$c-detach(qw/Root _softwareError/,
[An id is required to get related genes.])
unless $id;
my $gr = GeneRelations-new(
%{$c-config()-{dbinfos}},
org = $c-session()-{org}-{id_org},
);
my $t = $gr-display_graph(type = 'id_gene', value =
$id);
$c-res-write($t);
Delete this one too, that's going to make end() be run twice.
$c-forward('Root', 'end');
}
Once you've fixed those, all you should need to do is make sure there's
something in $t and RenderView won't call the TT view at all for rg.
--
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] Tutorial
On Thu, May 01, 2008 at 11:17:33AM -0700, gaurav001 wrote: Hello gurus, I am newb for Catalyst so forgive me if I ask stupid questions. I have Rockway's book. I followed it. All went good so far (ignore FormBuilder stuff ). Now i want to customize application. Lets say FormBuilder.render gives me submit button automatically (no idea how). But what if I want One Registration button and another Cancel Button. Also Controller file (.PM) file, how can i write my business logic. I know its perl but as I include Catalyst::Controller::FormBuilder...Anychange gives me error. Your business logic doesn't go in the controller, it goes in the model. Catalyst::Controller::FormBuilder just exposes the CGI::FormBuilder object; see its docs for details on that. Note that anychange gives me error isn't something we can help with. If you don't tell us the actual error message, we can't do anything - you're almost as vague as my uncle is when he says the internet is broken. Oh, and ignore Ali M. He likes telling people how awful their documentation is and how they should write more but hasn't sent a single patch himself. -- 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: Fw: high school reunion [Catalyst] (no subject)
On Mon, May 05, 2008 at 11:19:34AM +1930, Alejandro Imass wrote: Too bad one cannot unsubscribe them from the Internet altogether. Although breaking into their DSL router, reflashing the firmware with all zeros and then rebooting it is probably close enough. Not that I'd advocate such a thing, of course. -- 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] RFC: Catalyst::Controller::REST::DBIC
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
Sorry but I don't understand your point - so maybe first I'll restate
mine. If you have primary key in the database that is of type varchar
(or char or ...) then 'create' is a legitimage value for that primary
key.
If you just don't like the string 'id' in the URI - then I have not
any preference to that - it can be /foo/primary_key/ for me.
My point is that you do not have to use the primary key as the record
lookup identifier.
A user has no control over the record lookup identifier (ID) when you
do things like /user/{primary_key} (or /user/id/{primary_key}, which
is just converting named params to positional in a weird way). In a
lot of cases, the record lookup identifier makes more sense to be
somewhat bound to the user. As an example, lets say registering for a
web service where you have to have a unique login:
POST /user/jshirley
---
login: jshirley
first_name: Jay
last_name: Shirley
...
Now, it's a simple check here - does /user/jshirley exist? If so,
reject the request appropriately. If not, create the user at
/user/jshirley.
The primary key that the database uses is completely useless to the
user. /user/1634254 is silly, /user/jshirley is meaningful.
I fail to see how whether the PK is the lookup key or not has any
relevance at all to the original point, which was your lookup key and
names of actions might clash so it can be nice to have an extra path component
such as 'id' for the lookup part to disambiguate.
--
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: RFC: Catalyst::Controller::REST::DBIC
On Mon, May 05, 2008 at 10:46:56AM +0100, luke saunders wrote: On Mon, May 5, 2008 at 1:20 AM, Patrick Donelan [EMAIL PROTECTED] wrote: No, but how you provide an alternative to full RESTness for clients that don't handle the full range of HTTP verbs -is- a matter for discussion. Which clients are we talking about here? I did a quick google search and could only find an off-hand remark along the lines of in 2006 safari had poor support for REST verbs. I'm interested because in my own personal experience I haven't run into any problems generating PUT/POST/GET/DELETE with IE/FF/Opera browsers. Or are you talking about the inability to specify anything other than GET or POST as a form method? I'm afraid I can't remember exactly, it was around two years ago and we needed to fire PUT requests using XHR in JS using Dojo and it just wasn't happening. Dojo has changed dramatically since then and now has an xhrPut method so I expect whatever the problem has been addressed. Doubt it. The problem was the browsers gleefully threw out half the headers we were trying to send when we used a PUT request. Fuck all dojo can do about that so far as I can see. Of course I forget which browsers and which headers, but it sure as hell fucked our shit up but good. -- 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] How to print/display some data in an end action
Mitch Jackson wrote:
Emmanuel,
Your object is going to request the svg file from your display method,
just like a web browser would. When catalyst delivers the file, it
needs to look like an SVG to the browser. Some browsers look for
different things.
http://www.getsvg.com/implementation_issues/content_type_image_svg_xml
Looks like you need to end the URL with .svg, and also set the
content type. You may need to add a dummy parameter at the end of
your url, that you throw away and ignore, so the url looks like a
.svg. for example... http:///display/1/something.svg. Setting
the filename, as I recommended, may or may not replace the need for
this... however, it will make it so if you hit the URL in the web
browser that it behaves properly.
You also need to set the content type to image/svg+xml
sub end : Private {
my($self, $c) = @_;
my $g = $c-req-args()-[0];
$c-res-content_type( image/svg+xml );
$c-res-body( $g );
}
Good luck,
/Mitch
Hi Mitch,
You were right! Thanks a lot.
Adding the '.svg' in the end of my url :
http://.../rg/1.svg
displays correctly the image inside the template!
So I'd like to thank all people who have tried to help me
with this problem, thinking it is a Catalyst problem. It
looks like it is more a browser issue.
Cheers
Emmanuel
--
-
Emmanuel Quevillon
Biological Software and Databases Group
Institut Pasteur
+33 1 44 38 95 98
tuco at_ pasteur dot fr
-
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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
Problem solved. In my View class, like: package MyApp::View::TT; use strict; use warnings; use base 'Catalyst::View::TT'; replace the last line with: use base 'Catalyst::View::TT::ForceUTF8'; and everything works fine. I guess there was some confusion between Template Toolkit and non-utf8 stash strings or similar. Thanks, Marius K. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Let's port Twitter to Perl
Hey, I heard Twitter was abandoning RoR. It would be the coup of the year if we could bring them to Perl, but from what I understand it's not even on the consideration list. So why not give them a little help? We should have a hackathon to port Twitter to Catalyst using all our most timesaving and advanced tech, like Moose, DBIC, etc. It would be the best branding effort for our community and would be a great publicity stunt. Who's in :) John Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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 Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL PROTECTED] wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak [EMAIL PROTECTED]
wrote:
Sorry but I don't understand your point - so maybe first I'll restate
mine. If you have primary key in the database that is of type varchar
(or char or ...) then 'create' is a legitimage value for that primary
key.
If you just don't like the string 'id' in the URI - then I have not
any preference to that - it can be /foo/primary_key/ for me.
My point is that you do not have to use the primary key as the record
lookup identifier.
A user has no control over the record lookup identifier (ID) when you
do things like /user/{primary_key} (or /user/id/{primary_key}, which
is just converting named params to positional in a weird way). In a
lot of cases, the record lookup identifier makes more sense to be
somewhat bound to the user. As an example, lets say registering for a
web service where you have to have a unique login:
POST /user/jshirley
---
login: jshirley
first_name: Jay
last_name: Shirley
...
Now, it's a simple check here - does /user/jshirley exist? If so,
reject the request appropriately. If not, create the user at
/user/jshirley.
The primary key that the database uses is completely useless to the
user. /user/1634254 is silly, /user/jshirley is meaningful.
I fail to see how whether the PK is the lookup key or not has any
relevance at all to the original point, which was your lookup key and
names of actions might clash so it can be nice to have an extra path
component
such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't need to be there.
If we were talking about RPC, that would be a differently titled
thread and different arguments.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] Let's port Twitter to Perl
It'd be a good way to get Catalyst out there. I've experimented with different frameworks(RoR and Django) and Catalyst is the one I always wind up coming back to... probably mostly because of my familiarity with perl, but I love the way of thinking that Catalyst pushes you towards. The MVC in Django(they call it MTV, model-template-view) was nice but didn't feel like it made as much sense as Catalyst's solution. So I'm in if there's going to be a hackathon. On Mon, May 5, 2008 at 10:34 AM, John Napiorkowski [EMAIL PROTECTED] wrote: Hey, I heard Twitter was abandoning RoR. It would be the coup of the year if we could bring them to Perl, but from what I understand it's not even on the consideration list. So why not give them a little help? We should have a hackathon to port Twitter to Catalyst using all our most timesaving and advanced tech, like Moose, DBIC, etc. It would be the best branding effort for our community and would be a great publicity stunt. Who's in :) John Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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 Mon, May 5, 2008 at 8:18 AM, Andrew Rodland [EMAIL PROTECTED] wrote:
On Monday 05 May 2008 09:50:08 am J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL PROTECTED] wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
I fail to see how whether the PK is the lookup key or not has any
relevance at all to the original point, which was your lookup key and
names of actions might clash so it can be nice to have an extra path
component such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't need to be
there.
But those nouns you're talking about aren't verbs at all.
Andrew
How is /create, /edit or /delete not a verb?
My argument is separate to the /create is valid in the /foo/{token}
bit. I'm saying that /foo/create is silly to have in the first place,
and the /foo/id/{id} is nothing more than a conversion from named
parameters to positional, and ugly.
If you apply actual REST principles, you don't have such nonsense.
But again, as I said, this is if you are working with REST. If REST
doesn't fit your application model, don't use it. Just don't name
things REST when they are really CRUD.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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 Mon, May 5, 2008 at 6:19 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland [EMAIL PROTECTED] wrote:
On Monday 05 May 2008 09:50:08 am J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL PROTECTED] wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
I fail to see how whether the PK is the lookup key or not has any
relevance at all to the original point, which was your lookup key
and
names of actions might clash so it can be nice to have an extra path
component such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't need to be
there.
But those nouns you're talking about aren't verbs at all.
Andrew
How is /create, /edit or /delete not a verb?
My argument is separate to the /create is valid in the /foo/{token}
bit. I'm saying that /foo/create is silly to have in the first place,
and the /foo/id/{id} is nothing more than a conversion from named
parameters to positional, and ugly.
If you apply actual REST principles, you don't have such nonsense.
But again, as I said, this is if you are working with REST. If REST
doesn't fit your application model, don't use it. Just don't name
things REST when they are really CRUD.
The point is about having something that will work as REST for
automated agents and also work for browsers by some emulation or what
ever - so you'll have some additional actions on the controller as
well. Additionally if we really want to make this REST Role (assuming
Moose Catalyst by that time) - then the user of the library can have
his own actions. In both way you'll have a clash if we go your way.
Because /foo/id/{id} looks like a parameter - which is the only
argument agains it and is just a bit of pedantry on your side - you
would allow for broken logic?
--
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] RFC: Catalyst::Controller::REST::DBIC
On Mon, May 5, 2008 at 5:19 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland [EMAIL PROTECTED] wrote:
On Monday 05 May 2008 09:50:08 am J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL PROTECTED] wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
I fail to see how whether the PK is the lookup key or not has any
relevance at all to the original point, which was your lookup key
and
names of actions might clash so it can be nice to have an extra path
component such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't need to be
there.
But those nouns you're talking about aren't verbs at all.
Andrew
How is /create, /edit or /delete not a verb?
My argument is separate to the /create is valid in the /foo/{token}
bit. I'm saying that /foo/create is silly to have in the first place ...
Okay, let me clear this up. Originally the plan was to have a
centralised REST-style action which dispatched POST/PUT/GET/DELETE
requests to the appropriate actions while also providing RPC-style
verb actions as an alternative for use if the client didn't properly
support the REST request methods. Having listened to discussion in
this thread I think it would be better to make the module pure REST
and then provide the RPC alternative through a subclass, perhaps also
integrating Catalyst::Request::REST::ForBrowsers into the REST version
as suggested.
If you apply actual REST principles, you don't have such nonsense.
But again, as I said, this is if you are working with REST. If REST
doesn't fit your application model, don't use it. Just don't name
things REST when they are really CRUD.
Why can't CRUD be RESTful?
In fact my revised plan is to glue together a base REST module and a
base CRUD module and add the list method discussed somewhere else in
this thread to provide a complete default RESTful module. Ideally the
REST base module could be swapped for an RPC style base module to
easily provide an RPC alternative of the same thing.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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 Mon, May 05, 2008 at 07:50:08AM -0700, J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL PROTECTED] wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak [EMAIL PROTECTED]
wrote:
Sorry but I don't understand your point - so maybe first I'll restate
mine. If you have primary key in the database that is of type varchar
(or char or ...) then 'create' is a legitimage value for that primary
key.
If you just don't like the string 'id' in the URI - then I have not
any preference to that - it can be /foo/primary_key/ for me.
My point is that you do not have to use the primary key as the record
lookup identifier.
A user has no control over the record lookup identifier (ID) when you
do things like /user/{primary_key} (or /user/id/{primary_key}, which
is just converting named params to positional in a weird way). In a
lot of cases, the record lookup identifier makes more sense to be
somewhat bound to the user. As an example, lets say registering for a
web service where you have to have a unique login:
POST /user/jshirley
---
login: jshirley
first_name: Jay
last_name: Shirley
...
Now, it's a simple check here - does /user/jshirley exist? If so,
reject the request appropriately. If not, create the user at
/user/jshirley.
The primary key that the database uses is completely useless to the
user. /user/1634254 is silly, /user/jshirley is meaningful.
I fail to see how whether the PK is the lookup key or not has any
relevance at all to the original point, which was your lookup key and
names of actions might clash so it can be nice to have an extra path
component
such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't need to be there.
You'd never have a /user/recent or similar URL? I guess if you assume that
all views onto the collection are done via query parameters, or just
move that funcationality to /recent-users or similar then it doesn't matter.
But that's a different sort of uglification of the URL; it doesn't get rid
of it.
And it still doesn't help if you want to allow lookup by more than one
name so far as I can see.
--
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/
[Catalyst] Re: Let's port Twitter to Perl
* John Napiorkowski [EMAIL PROTECTED] [2008-05-05 16:45]: I heard Twitter was abandoning RoR. Except, they aren’t. http://twitter.com/ev/statuses/801530348 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] RFC: Catalyst::Controller::REST::DBIC
On Mon, May 5, 2008 at 9:49 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 6:19 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland [EMAIL PROTECTED] wrote:
On Monday 05 May 2008 09:50:08 am J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL PROTECTED]
wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
I fail to see how whether the PK is the lookup key or not has any
relevance at all to the original point, which was your lookup
key and
names of actions might clash so it can be nice to have an extra
path
component such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't need to
be
there.
But those nouns you're talking about aren't verbs at all.
Andrew
How is /create, /edit or /delete not a verb?
My argument is separate to the /create is valid in the /foo/{token}
bit. I'm saying that /foo/create is silly to have in the first place,
and the /foo/id/{id} is nothing more than a conversion from named
parameters to positional, and ugly.
If you apply actual REST principles, you don't have such nonsense.
But again, as I said, this is if you are working with REST. If REST
doesn't fit your application model, don't use it. Just don't name
things REST when they are really CRUD.
The point is about having something that will work as REST for
automated agents and also work for browsers by some emulation or what
ever - so you'll have some additional actions on the controller as
well. Additionally if we really want to make this REST Role (assuming
Moose Catalyst by that time) - then the user of the library can have
his own actions. In both way you'll have a clash if we go your way.
Because /foo/id/{id} looks like a parameter - which is the only
argument agains it and is just a bit of pedantry on your side - you
would allow for broken logic?
That's just one argument that is most obvious. The other argument is
that it adds additional entry points into an entity that you have to
keep in sync.
If you have /foo/id/{id} and /foo/name/{name} that are two paths to
the same entity, but {name} is not immutable you have broken
navigation at some point (bookmarks, etc). So you have two immutable
entities for the same thing? I fail to see why that works. Which
leads into my main argument that using the primary key as the record
lookup identifier (in many cases) is simply bad design.
This strategy is redundancy of the oddest form to me, and it yields
more complications down the road as applications become more complex.
If you remove the redundancy, and each object has a well-defined
identifier, a POST to /foo will create a new entity which redirects to
/foo/{identifier}. It's easy to duplicate functionality that a POST
to /foo/{identifier} works the same as a POST to just /foo, and can
generate $identifier. I fail to see why a /create action needs to
exist in the first place on /foo.
Now, for browser-compatibility methods it isn't a bad thing having
/foo/{identifier}/(edit|delete). The business with /foo/id/{ident}
there so that you don't conflict with a /create action on /foo is
just silly, and a sign of inadequate forethought into your resource
structure. But again, this has very little to do with REST and more
to do with a sane URI structure (although not having an explicit
/create action is more on the RESTful side, I never have encountered
an issue having POST /foo handle item creation).
So, yes, it is pedantic but I don't view it as broken logic. I view
it as tidy logic that doesn't employ the use of URI hacks to get
around browser deficiencies.
-J
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC
On Mon, May 5, 2008 at 10:02 AM, Matt S Trout [EMAIL PROTECTED] wrote:
On Mon, May 05, 2008 at 07:50:08AM -0700, J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL PROTECTED] wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak [EMAIL PROTECTED]
wrote:
Sorry but I don't understand your point - so maybe first I'll
restate
mine. If you have primary key in the database that is of type
varchar
(or char or ...) then 'create' is a legitimage value for that
primary
key.
If you just don't like the string 'id' in the URI - then I have not
any preference to that - it can be /foo/primary_key/ for me.
My point is that you do not have to use the primary key as the record
lookup identifier.
A user has no control over the record lookup identifier (ID) when you
do things like /user/{primary_key} (or /user/id/{primary_key}, which
is just converting named params to positional in a weird way). In a
lot of cases, the record lookup identifier makes more sense to be
somewhat bound to the user. As an example, lets say registering for a
web service where you have to have a unique login:
POST /user/jshirley
---
login: jshirley
first_name: Jay
last_name: Shirley
...
Now, it's a simple check here - does /user/jshirley exist? If so,
reject the request appropriately. If not, create the user at
/user/jshirley.
The primary key that the database uses is completely useless to the
user. /user/1634254 is silly, /user/jshirley is meaningful.
I fail to see how whether the PK is the lookup key or not has any
relevance at all to the original point, which was your lookup key and
names of actions might clash so it can be nice to have an extra path
component
such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't need to be
there.
You'd never have a /user/recent or similar URL? I guess if you assume that
all views onto the collection are done via query parameters, or just
move that funcationality to /recent-users or similar then it doesn't matter.
But that's a different sort of uglification of the URL; it doesn't get rid
of it.
And it still doesn't help if you want to allow lookup by more than one
name so far as I can see.
Search vs. Browse is separate user actions and deserves separate resource space.
/user implies a single user.
/users implies browsing.
So in this hypothetical case I would probably have a top level
namespace for /browse that had its own hierarchy (since most people
are going to browse more than just people)
/browse/users/recent
But... I also would do /browse/people/recent
Now you have a better (read-only) browse namespace on your site and it
descends into a hierarchy appropriately.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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 Mon, May 5, 2008 at 9:51 AM, luke saunders [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 5:19 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland [EMAIL PROTECTED] wrote:
On Monday 05 May 2008 09:50:08 am J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL PROTECTED]
wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
I fail to see how whether the PK is the lookup key or not has any
relevance at all to the original point, which was your lookup
key and
names of actions might clash so it can be nice to have an extra
path
component such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't need to
be
there.
But those nouns you're talking about aren't verbs at all.
Andrew
How is /create, /edit or /delete not a verb?
My argument is separate to the /create is valid in the /foo/{token}
bit. I'm saying that /foo/create is silly to have in the first place ...
Okay, let me clear this up. Originally the plan was to have a
centralised REST-style action which dispatched POST/PUT/GET/DELETE
requests to the appropriate actions while also providing RPC-style
verb actions as an alternative for use if the client didn't properly
support the REST request methods. Having listened to discussion in
this thread I think it would be better to make the module pure REST
and then provide the RPC alternative through a subclass, perhaps also
integrating Catalyst::Request::REST::ForBrowsers into the REST version
as suggested.
If you apply actual REST principles, you don't have such nonsense.
But again, as I said, this is if you are working with REST. If REST
doesn't fit your application model, don't use it. Just don't name
things REST when they are really CRUD.
Why can't CRUD be RESTful?
In fact my revised plan is to glue together a base REST module and a
base CRUD module and add the list method discussed somewhere else in
this thread to provide a complete default RESTful module. Ideally the
REST base module could be swapped for an RPC style base module to
easily provide an RPC alternative of the same thing.
REST and CRUD are not mutually exclusive, but implementations can be.
When I see things like /book/create, /book/1/edit I see CRUD (or RPC)
but not REST. REST also doesn't have to be CRUD. I have a REST
application that is more CR. It just posts immutable records and
provides findability on those records.
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.) I
haven't had enough time to actually proffer any code, but since this
is a central focus of my development as late I'm very opinionated in
these matters :)
I just want to be an advocate of standards and not slip into the
Internet Explorer Development Methodology. Eventually browsers will
support this stuff, in the mean time, using strict REST makes
webservices so much easier.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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 Mon, May 05, 2008 at 04:12:53PM +0200, Marius Kjeldahl wrote: Problem solved. In my View class, like: package MyApp::View::TT; use strict; use warnings; use base 'Catalyst::View::TT'; replace the last line with: use base 'Catalyst::View::TT::ForceUTF8'; That seems like the wrong approach. Data should be decoded on input from the outside and encoded on output. I'm not sure when it would be advisable to force utf8 flag on items in the stash, but I have not looked at that module in a while. form tags should have accept-charset C::P::Unicode::Encoding should be used (I suggest with reservations). That will decode parameters and encoding output. If your templates are UTF8 then ENCODING = 'UTF-8' when creating TT object. Do what's required for your database to handle utf-8. -- 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: [Catalyst] RFC: Catalyst::Controller::REST::DBIC
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 It definitely has URI styles in place already, though overriding fetch() to chain to a different root (like /id instead of /) seems trivial to me. There is also work started on a DBIC adapter, and existing model stores in place already for RDBO and filesystem (LDAP is on my TODO list). SVN is here: http://dev.catalyst.perl.org/repos/Catalyst/CatalystX-CRUD/ I hope to push a new release of CX::CRUD soon that will support the 'x-tunneled-method' syntax of drolsky's REST::ForBrowsers in addition to the '_http_method' syntax of prior CX::CRUD::REST releases. Please, consider building on existing code like CX::CRUD and/or suggesting changes to the current implementation, rather than starting a new project. There are already too many CRUD-style Catalyst modules on CPAN imho. -- 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/
[Catalyst] How to display a single HTML::Widget form field in a TT2 template?
Hello all, Sorry again if this is spelled out somewhere that I'm missing. I'm getting up to speed with HTML::Widget as used in the Catalyst Tutorial online in the Advanced CRUD section. I would like more control over the layout of my form so I'd like to build a more detailed template than what the examples show. I can't find how to display a certain form field in a TT2 template using the element's name. Can someone provide a quick example of displaying just a single element in a form by name? I think I'm missing something basic here... Thanks much, Ryan ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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 Mon, May 5, 2008 at 11:28 AM, 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 It definitely has URI styles in place already, though overriding fetch() to chain to a different root (like /id instead of /) seems trivial to me. There is also work started on a DBIC adapter, and existing model stores in place already for RDBO and filesystem (LDAP is on my TODO list). SVN is here: http://dev.catalyst.perl.org/repos/Catalyst/CatalystX-CRUD/ I hope to push a new release of CX::CRUD soon that will support the 'x-tunneled-method' syntax of drolsky's REST::ForBrowsers in addition to the '_http_method' syntax of prior CX::CRUD::REST releases. Please, consider building on existing code like CX::CRUD and/or suggesting changes to the current implementation, rather than starting a new project. There are already too many CRUD-style Catalyst modules on CPAN imho. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.com/ karpet++ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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: Let's port Twitter to Perl
--- On Mon, 5/5/08, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: From: Aristotle Pagaltzis [EMAIL PROTECTED] Subject: [Catalyst] Re: Let's port Twitter to Perl To: catalyst@lists.scsys.co.uk Date: Monday, May 5, 2008, 1:07 PM * John Napiorkowski [EMAIL PROTECTED] [2008-05-05 16:45]: I heard Twitter was abandoning RoR. Except, they aren’t. http://twitter.com/ev/statuses/801530348 Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ U, Let's do it anyway? Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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
Bill Moseley wrote: use base 'Catalyst::View::TT::ForceUTF8'; That seems like the wrong approach. Data should be decoded on input from the outside and encoded on output. I'm not sure when it would be advisable to force utf8 flag on items in the stash, but I have not looked at that module in a while. form tags should have accept-charset I tried this but couldn't get it working correctly, which may be entirely my fault of course. C::P::Unicode::Encoding should be used (I suggest with reservations). That will decode parameters and encoding output. I looked into this and related modules trying to figure out exactly where to do what, which lead me to the solution posted. If your templates are UTF8 then ENCODING = 'UTF-8' when creating TT object. Tried this as well. Didn't work. As far as I managed to figure out, that solution requires the plugin you mentioned, or a similar one (possibly ending in Encode instead of Encoding - I'm taking this from memory while googling for a solution to my problem). Do what's required for your database to handle utf-8. In my case, everything is utf8. The source code (with embedded strings), the database and I see no reason to start juggling back and forth between encodings unless there is a specific need. There may be one, which I'm sure further testing will demonstrate, but for now I'm ok. Actually, I found one place where it was actually needed already. I'm using some of the Yahoo YUI ajax components which didn't work great with utf8, and a simple decode (from utf8) before returning some values in a ajax component seemed to solve it just. There may be flags that can be set in the YUI library which enable utf8 encoding also, which would probably be a better solution. Thanks, Marius K. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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 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? It definitely has URI styles in place already, though overriding fetch() to chain to a different root (like /id instead of /) seems trivial to me. There is also work started on a DBIC adapter, and existing model stores in place already for RDBO and filesystem (LDAP is on my TODO list). SVN is here: http://dev.catalyst.perl.org/repos/Catalyst/CatalystX-CRUD/ I hope to push a new release of CX::CRUD soon that will support the 'x-tunneled-method' syntax of drolsky's REST::ForBrowsers in addition to the '_http_method' syntax of prior CX::CRUD::REST releases. Please, consider building on existing code like CX::CRUD and/or suggesting changes to the current implementation, rather than starting a new project. There are already too many CRUD-style Catalyst modules on CPAN imho. -- 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/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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 Mon, May 05, 2008 at 09:22:19PM +0200, Marius Kjeldahl wrote: form tags should have accept-charset I tried this but couldn't get it working correctly, which may be entirely my fault of course. What does couldn't get it working mean? You couldn't get an accept-charset on your form tags? C::P::Unicode::Encoding should be used (I suggest with reservations). That will decode parameters and encoding output. I looked into this and related modules trying to figure out exactly where to do what, which lead me to the solution posted. It's just a plugin in. You add it to the use Catalyst list of plugins. It only decodes $c-req-parameters (failing to decode body_parameters, btw) and then encodes the $c-req-body in finalize(). If your templates are UTF8 then ENCODING = 'UTF-8' when creating TT object. Tried this as well. Didn't work. As far as I managed to figure out, that solution requires the plugin you mentioned, or a similar one (possibly ending in Encode instead of Encoding - I'm taking this from memory while googling for a solution to my problem). Again, not sure what didn't work means, but it doesn't require any other modules -- it just says your templates should be decoded as the encoding you specify: perldoc -m Template::Provider search for ENCODING -- 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: [Catalyst] RFC: Catalyst::Controller::REST::DBIC
On Mon, May 5, 2008 at 6:16 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 9:51 AM, luke saunders [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 5:19 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland [EMAIL PROTECTED]
wrote:
On Monday 05 May 2008 09:50:08 am J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL PROTECTED]
wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
I fail to see how whether the PK is the lookup key or not has
any
relevance at all to the original point, which was your lookup
key and
names of actions might clash so it can be nice to have an
extra path
component such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't need
to be
there.
But those nouns you're talking about aren't verbs at all.
Andrew
How is /create, /edit or /delete not a verb?
My argument is separate to the /create is valid in the /foo/{token}
bit. I'm saying that /foo/create is silly to have in the first place
...
Okay, let me clear this up. Originally the plan was to have a
centralised REST-style action which dispatched POST/PUT/GET/DELETE
requests to the appropriate actions while also providing RPC-style
verb actions as an alternative for use if the client didn't properly
support the REST request methods. Having listened to discussion in
this thread I think it would be better to make the module pure REST
and then provide the RPC alternative through a subclass, perhaps also
integrating Catalyst::Request::REST::ForBrowsers into the REST version
as suggested.
If you apply actual REST principles, you don't have such nonsense.
But again, as I said, this is if you are working with REST. If REST
doesn't fit your application model, don't use it. Just don't name
things REST when they are really CRUD.
Why can't CRUD be RESTful?
In fact my revised plan is to glue together a base REST module and a
base CRUD module and add the list method discussed somewhere else in
this thread to provide a complete default RESTful module. Ideally the
REST base module could be swapped for an RPC style base module to
easily provide an RPC alternative of the same thing.
REST and CRUD are not mutually exclusive, but implementations can be.
When I see things like /book/create, /book/1/edit I see CRUD (or RPC)
but not REST. REST also doesn't have to be CRUD. I have a REST
application that is more CR. It just posts immutable records and
provides findability on those records.
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.) I
haven't had enough time to actually proffer any code, but since this
is a central focus of my development as late I'm very opinionated in
these matters :)
I think that the /foo/{token} vs /foo/id/{token} is the only point of
contention. And it would definitely be nice if an agreement could be
reached on this. Indeed, if I do develop this further it would make
sense if the REST base class is your own
Catalyst::Controller::REST::DBIC::Item.
To me the /foo/{token} URI is only acceptable if it is understood that
no further custom object level URIs can then be added
(/foo/{token}/disable for example) and that lookup can only ever be by
{token} rather than {name} or something else. For REST I can see that
this is possible but I do feel that putting something between the base
and the token to clearly identify it as object level is generally the
safest option.
Peter made a fair point that if you don't like it you can subclass and
change, but agreeing on a best practice and making that default is
obviously desirable.
I just want to be an advocate of standards and not slip into the
Internet Explorer Development Methodology. Eventually browsers will
support this stuff, in the mean time, using strict REST makes
webservices so much easier.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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 Mon, May 5, 2008 at 1:10 PM, luke saunders [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 6:16 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 9:51 AM, luke saunders [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 5:19 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland [EMAIL PROTECTED]
wrote:
On Monday 05 May 2008 09:50:08 am J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL
PROTECTED] wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
I fail to see how whether the PK is the lookup key or not
has any
relevance at all to the original point, which was your
lookup key and
names of actions might clash so it can be nice to have an
extra path
component such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't
need to be
there.
But those nouns you're talking about aren't verbs at all.
Andrew
How is /create, /edit or /delete not a verb?
My argument is separate to the /create is valid in the /foo/{token}
bit. I'm saying that /foo/create is silly to have in the first
place ...
Okay, let me clear this up. Originally the plan was to have a
centralised REST-style action which dispatched POST/PUT/GET/DELETE
requests to the appropriate actions while also providing RPC-style
verb actions as an alternative for use if the client didn't properly
support the REST request methods. Having listened to discussion in
this thread I think it would be better to make the module pure REST
and then provide the RPC alternative through a subclass, perhaps also
integrating Catalyst::Request::REST::ForBrowsers into the REST version
as suggested.
If you apply actual REST principles, you don't have such nonsense.
But again, as I said, this is if you are working with REST. If REST
doesn't fit your application model, don't use it. Just don't name
things REST when they are really CRUD.
Why can't CRUD be RESTful?
In fact my revised plan is to glue together a base REST module and a
base CRUD module and add the list method discussed somewhere else in
this thread to provide a complete default RESTful module. Ideally the
REST base module could be swapped for an RPC style base module to
easily provide an RPC alternative of the same thing.
REST and CRUD are not mutually exclusive, but implementations can be.
When I see things like /book/create, /book/1/edit I see CRUD (or RPC)
but not REST. REST also doesn't have to be CRUD. I have a REST
application that is more CR. It just posts immutable records and
provides findability on those records.
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.) I
haven't had enough time to actually proffer any code, but since this
is a central focus of my development as late I'm very opinionated in
these matters :)
I think that the /foo/{token} vs /foo/id/{token} is the only point of
contention. And it would definitely be nice if an agreement could be
reached on this. Indeed, if I do develop this further it would make
sense if the REST base class is your own
Catalyst::Controller::REST::DBIC::Item.
If people are ok with the verbs being in the URL as a sacrifice to
broken browsers, agreed :)
I'm going to be rounding out the tests for my work, and I'm giving a
talk on it at YAPC::Asia. It's mostly just my thoughts on how things
go, but the work is from a web-services point of view, with some
browser views. I'll post my slides up (and there may be video fo the
talk) afterwards.
To me the /foo/{token} URI is only acceptable if it is understood that
no further custom object level URIs can then be added
(/foo/{token}/disable for example) and that lookup can only ever be by
{token} rather than {name} or something else. For REST I can see that
this is possible but I do feel that putting something between the base
and the token to clearly identify it as object level is generally the
safest option.
I like to map my URLs out in a definitive hierarchy. If people want
an implicit create action, a /foo/-/create looks better to me than
having /foo/create, because I have the level of /foo to be the plural,
/foo/{id} to be the singular (in a simple CRUD example).
/foo/-/create is fine, because you can have a rule that - is never
an acceptable record identifier.
All of this stuff is mostly just standardizing on a set of
Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC
On 05/05/2008 03:29 PM, J. Shirley wrote:
My vote is hierarchy like:
/foo
/{token} # Can be pk1 if you so desire
/- # - is never acceptable as an identifier
/create # if you want an empty action here
Now, I do vote against having an explicit create action, since POST
/foo (or POST /foo/{token}) seems to be a more reasonable create
action.
fwiw, CX::CRUD::REST uses:
http://search.cpan.org/~karman/CatalystX-CRUD-0.25/lib/CatalystX/CRUD/REST.pm#SYNOPSIS
I use 0 (zero) as my reserved PK value since seq PKs start at 1 and zero
evaluates as
false in Perl.
my ($self, $c, $oid) = @_;
if (!$oid) {
# could be absent or zero, either is fine
# ...
}
Also, I adopted drolsky's suggestion of /create_form instead of /create in
order to keep
the RESTful no-verb style URIs.
--
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] Let's port Twitter to Perl
On Mon, May 5, 2008 at 3:29 PM, John Napiorkowski [EMAIL PROTECTED] wrote: I heard Twitter was abandoning RoR. It would be the coup of the year if we could bring them to Perl, but from what I understand it's not even on the consideration list. So why not give them a little help? We should have a hackathon to port Twitter to Catalyst using all our most timesaving and advanced tech, like Moose, DBIC, etc. Knock yourselves out, but I remain to be convinced that the scalability of RoR is anything but a red herring. The bottom line is that the design decisions you make at the very beginning of a project tend to be the limiting factor in this area. Sure, your choice of implementation language might not be the fastest, but is it the bottleneck? It strikes me that an awful lot of what makes Twitter 'Twitter' are the heavy-lifting processes that caching and implementation-language choice have very small amounts of influence over. Without fully understanding those, there's the distinct possibility of falling into the same traps. One thing I do know though: As much as OR-mapping systems are lovely and all for the most part, that's the first part I'd ditch if I was all out for screaming performance. Yes, it's possible to code around this by binning and balancing and other techniques, but it's a potentially enormous tradeoff between ease of development vs. sheer unadulterated speed (where all the clever binning, balancing and other techniques still apply). So to conclude: Twitter is a typical prototype that didn't scale. No shame in that. Mitigation can only get you so far, and it's really, REALLY tough to migrate and swap out something as complicated whilst making sweeping changes and still maintaining uptime. None of this is intended as a slight on any of the magnificent work that's been done, it's insanely good, and I'm happy to stick my hand out, wave it around and say 'Thanks!' to everyone's CPAN code I rely on for my day-to-day job. But hubris, however well-intentioned, is still hubris unless you pay particular attention to the lessons learned. This post is not intended to be pooh-poohing or flamebait, I'd personally love to see some kind of scalable twitteresque application to come out of this, it's just that I've yet to see anyone point out the enormity of such a task. :-) Chris ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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 ...
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*. Dogmatism. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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 display a single HTML::Widget form field in a TT2 template?
2008/5/5 Ryan Grace [EMAIL PROTECTED]: Hello all, Sorry again if this is spelled out somewhere that I'm missing. I'm getting up to speed with HTML::Widget as used in the Catalyst Tutorial online in the Advanced CRUD section. I'm surprised the tutorial still uses HTML::Widget - as it's docs state, it's no longer being developed - it's effectively been replaced by HTML::FormFu (which I wrote). Other form-generation or -processing modules very popular with the Catalyst community which you'll also see mentioned on this list are CGI::FormBuilder and Rose::HTML::Form Carl ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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 Mon, May 5, 2008 at 9:29 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 1:10 PM, luke saunders [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 6:16 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 9:51 AM, luke saunders [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 5:19 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland [EMAIL
PROTECTED] wrote:
On Monday 05 May 2008 09:50:08 am J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL
PROTECTED] wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley
wrote:
I fail to see how whether the PK is the lookup key or not
has any
relevance at all to the original point, which was your
lookup key and
names of actions might clash so it can be nice to have
an extra path
component such as 'id' for the lookup part to
disambiguate.
Because I'm talking about REST and a verb in the URI
doesn't need to be
there.
But those nouns you're talking about aren't verbs at all.
Andrew
How is /create, /edit or /delete not a verb?
My argument is separate to the /create is valid in the
/foo/{token}
bit. I'm saying that /foo/create is silly to have in the first
place ...
Okay, let me clear this up. Originally the plan was to have a
centralised REST-style action which dispatched POST/PUT/GET/DELETE
requests to the appropriate actions while also providing RPC-style
verb actions as an alternative for use if the client didn't properly
support the REST request methods. Having listened to discussion in
this thread I think it would be better to make the module pure REST
and then provide the RPC alternative through a subclass, perhaps
also
integrating Catalyst::Request::REST::ForBrowsers into the REST
version
as suggested.
If you apply actual REST principles, you don't have such
nonsense.
But again, as I said, this is if you are working with REST. If
REST
doesn't fit your application model, don't use it. Just don't
name
things REST when they are really CRUD.
Why can't CRUD be RESTful?
In fact my revised plan is to glue together a base REST module and a
base CRUD module and add the list method discussed somewhere else in
this thread to provide a complete default RESTful module. Ideally
the
REST base module could be swapped for an RPC style base module to
easily provide an RPC alternative of the same thing.
REST and CRUD are not mutually exclusive, but implementations can be.
When I see things like /book/create, /book/1/edit I see CRUD (or RPC)
but not REST. REST also doesn't have to be CRUD. I have a REST
application that is more CR. It just posts immutable records and
provides findability on those records.
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.) I
haven't had enough time to actually proffer any code, but since this
is a central focus of my development as late I'm very opinionated in
these matters :)
I think that the /foo/{token} vs /foo/id/{token} is the only point of
contention. And it would definitely be nice if an agreement could be
reached on this. Indeed, if I do develop this further it would make
sense if the REST base class is your own
Catalyst::Controller::REST::DBIC::Item.
If people are ok with the verbs being in the URL as a sacrifice to
broken browsers, agreed :)
I think the consensus is probably the opposite. I already agreed that
the verbs shouldn't be in the REST module but there should be an RPC
variant.
I'm going to be rounding out the tests for my work, and I'm giving a
talk on it at YAPC::Asia. It's mostly just my thoughts on how things
go, but the work is from a web-services point of view, with some
browser views. I'll post my slides up (and there may be video fo the
talk) afterwards.
Nice.
To me the /foo/{token} URI is only acceptable if it is understood that
no further custom object level URIs can then be added
(/foo/{token}/disable for example) and that lookup can only ever be by
{token} rather than {name} or something else. For REST I can see that
this is possible but I do feel that putting something between the base
and the token to clearly identify it as object level is generally the
safest option.
I like to map
Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC
The only header I've found you can't always set via xhr.setRequestHeader() is WWW-Authenticate because the browser thinks it should be responsible for HTTP Authentication. Which is why the last 2 optional arguments to xhr.open() are username and password, to effectively let you set these headers (it does the base64 encoding for you too which is handy). If anyone manages to remember any specific browser limitations or can find any references please let me know since it would be important for any RESTful design. Patrick On Mon, May 5, 2008 at 9:34 PM, Matt S Trout [EMAIL PROTECTED] wrote: On Mon, May 05, 2008 at 10:46:56AM +0100, luke saunders wrote: On Mon, May 5, 2008 at 1:20 AM, Patrick Donelan [EMAIL PROTECTED] wrote: No, but how you provide an alternative to full RESTness for clients that don't handle the full range of HTTP verbs -is- a matter for discussion. Which clients are we talking about here? I did a quick google search and could only find an off-hand remark along the lines of in 2006 safari had poor support for REST verbs. I'm interested because in my own personal experience I haven't run into any problems generating PUT/POST/GET/DELETE with IE/FF/Opera browsers. Or are you talking about the inability to specify anything other than GET or POST as a form method? I'm afraid I can't remember exactly, it was around two years ago and we needed to fire PUT requests using XHR in JS using Dojo and it just wasn't happening. Dojo has changed dramatically since then and now has an xhrPut method so I expect whatever the problem has been addressed. Doubt it. The problem was the browsers gleefully threw out half the headers we were trying to send when we used a PUT request. Fuck all dojo can do about that so far as I can see. Of course I forget which browsers and which headers, but it sure as hell fucked our shit up but good. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Director http://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/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
