Re: [Catalyst] Announce: Instant AJAX web front-end for DBIx::Class
Ali M. wrote: DBIC is switching to Moose? Isn't everything? :-) signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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 site design drafts feedback thread
My bikeshed has blue shag carpets with a disco ball and tinted windows. :-) signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] REST, JSON and Content-Type
So, I'm trolling through the ASP.NET 3.5 docs on JSON and AJAX and it talks about GET not being enabled by default for a web service and that the mime type must be application/json Of course the REST package has this: 'text/x-json'= 'JSON', Near as I can gather, the official type is appliction/json: http://tech.groups.yahoo.com/group/json/message/337 http://www.iana.org/assignments/media-types/application/ http://www.ietf.org/rfc/rfc4627.txt And to make matters more fun, MIME::Types has neither. I know, I know. Well volunteered. :-) Before I go patching things and submitting RT bugs, what do we want to do with REST? I vote to support both mime types. Near as I figure, it can't hurt to do so. Perhaps a warning about using an outdated mime type? -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst site design drafts feedback thread
Dave Rolsky wrote: On Wed, 11 Jun 2008, Matt S Trout wrote: Simon Elliott: (1) http://www.browsing.co.uk/cat Overall my favorite. The white text against the bottom of the grey gradient starts to fade, but I'm sure that's easily fixed. I wouldn't mind making all the non-tab text a little larger, but maybe my eyes are a little older than our target audience ;) Speaking of gradient... I'd much rather see a footer more like this one: http://movabletype.org/ signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst / dbix-class / mysql / REST job
Mark Trostler wrote: The job description is kinda crapy: http://jobs.perl.org/job/8624 But you can work in Sunnyvale, CA or Carslbad, CA. The backend in Catalyst/REST/DBIx::Class/MySQL. Frontends are currently command line/library using Moose and lots of AJAXy Javascript (using ExtJS - yah should be YUI ideally...). Join the team! Mark Sure it's not a Catalyst/RPC/DBIx::Class/MySQL instead? :-) signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Multi-language and REST
Ian Docherty wrote: I have been pondering how to take an existing Catalyst application and make it multi-lingual. I would prefer to use a RESTful method, so this would translate /foo/bar to /en/foo/bar or /fr/foo/bar (for English and French respectively). The problem as I see it is how to do this. I don't want to move all my controllers, e.g. MyApp::Controller::Foo::Bar to MyApp::Controller::Lang::Foo::Bar What other alternatives are there? Regards Ian Well, I'm sure there's a somewhat elegant way to do this with Chained, but it the other controllers don't use Chained now, that could get fun. The brute force way is to inspect the request and rip out the language portion before sending it on to get dispatched...just like the Flavour plugin does with file extensions: sub prepare_path {} signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Multi-language and REST
Dave Rolsky wrote: On Fri, 25 Apr 2008, Ashley wrote: I agree that it's content, not formatting. If CSS/client-side-JS can (in a practical fashion) change it, it's formatting, otherwise, it's content. I should have used the word representation. With REST, you'd have the same URI for one resource, but you might offer it as HTML, JSON, and plain text based on what the client requests. Given the Accept-Language header, you could do the same thing with language. -dave Could and should. I've taken the approach using the REST controller that if anyone wants to get at a resource easier (easier to alter the uri than the headers), then use the content-type query param. I think the same should be true for language. If changing Accept-Language is too much, (or people want to view a language other than their native), then look at language= in the query params first..if it's empty...honor Accept-Language... rather than forcing /lang/ at the front of all urls. signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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: CatalystSites.org
Aristotle Pagaltzis wrote: * Chisel Wright [EMAIL PROTECTED] [2008-04-16 11:50]: Just for chuckles - does anyone have an idea of the pain-level involved in converting a non-Chained application to Chained? Or is it just not worth the effort for an established project? Totally depends. I ported an app to Catalyst that previously was basically one-action-per-controller. It cannot be called anything less than a lot of work, but it paid of royally. The code is as DRY as it was before, but it’s now far better structured. Previously it was blocks of if-elsif chains grouping together execution steps that are shared by some URIs but not others – now it’s Chained. A typical controller looks something like this: sub base : Chained PathPart('doc') CaptureArgs(0) { ... } sub list : Chained('base') PathPart('') Args(0) { ... } sub item : Chained('base') PathPart('') CaptureArgs(1) { ... } sub view : Chained('item') PathPart('') Args(0) { ... } sub edit : Chained('item') Args(0) { ... } Just a sidebar to this. Chained PathPart('') is your friend. It is NOT the friend of index : Private or default : Private If you make use of Chained, don't use index/default. They don't act properly when doing things like: -config( path = 'foobar' ) to put controllers into a different uri. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] RFC: Catalyst::View::Feed (Atom/RSS)
As I sat around last night refactoring the View::Feed/View::Feed::(Atom|RSS) code in Mango because critic told me process() was too complex (and it was), a little voice popped into my head and told me I should just release it as a new dist. Most of this is code from helpful others who have embarked down the same path. It's been mentioned a few times, and there are some variations on the code. In a nutshell, it supports creating a feed from: ## just hashed data { xml_feed_attribute = 'value', xml_feed_attribute = 'value', xml_feed_attribute = 'value', entries = [ xml_feed_item_attribute = 'value', xml_feed_item_attribute = 'value', xml_feed_item_attribute = 'value', ], } ## objects with as_feed returning XML::Feed $someobj-as_feed; ## objects with as_feed returning a hash $someobj-as_feed( return { xml_feed_attribute = 'value', xml_feed_attribute = 'value', xml_feed_attribute = 'value', entries = [ xml_feed_item_attribute = 'value', xml_feed_item_attribute = 'value', xml_feed_item_attribute = 'value', ], }) The entries key can also be an array of XML::Feed::Item objects, an array of objects that return hashes or XML::Feed::Item from as_feed_item methods. View::Feed::Atom and View::Feed::RSS simply use View::Feed and set the appropriate content-type. Nothing fancy, but enough code to share an not have to rewrite again somewhere else. If anyone thinks it's worth the effort, I'll kick out a dist this weekend. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Patch for Catalyst::View::Mason
David Jack Wange Olrik wrote: On 07/03/2008, at 22.22, Florian Ragwitz wrote: I want to keep the default behaviour to not break existing code and to be consistent with most other catalyst views. However I'll think about implementing a new configuration option that, when enabled, will always append template_extension. Great, then I hope the other View authors will consider being consistent with you ;) Ideally, this should be, and was started to be extraced out into a based class... http://search.cpan.org/~jrockway/Catalyst-View-Templated-0.02/lib/Catalyst/View/Templated.pm signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Catalyst + Class::Workflow
Anyone done any integration with Class::Workflow and mapping object states to actions? I need to get back on the Mango wagon this week and I'm toying with making checkout nothing more than configurable states of an order. My first question is me wondering if checkout states are the same as order states, or if they should/could be two separate workflows. For example, once the customer places an order, we could have the following rather common order states: new processed authorized declined packed shipped refunded returned delivered During the checkout process, we have things like: initialized (create an order from cart) addressed (enter billto/shipto) shipmethod(selected ship method) preview submitted These can technically be states of the order preceding 'new', but I could also envision them as states of the checkout process itself and not necessarily states of the order itself. My other goal is to simply have /checkout/state be the uri structure for checkout, using transitions to kick off various plugins acting against the order. Thoughts? Anyone been down this road with Workflow in Catalyst? -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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 return a 401 from Catalyst
Jason Kohles wrote: On Jan 29, 2008, at 3:18 AM, Kieren Diment wrote: On 27 Jan 2008, at 20:59, Ian Docherty wrote: p.s. I note that there is nothing in Test::WWW (that I can find) that tests return status's such as 200, 401 etc. From perldoc Test::WWW::Mechanize: ... From perldoc WWW::Mechanize: ... from perldoc HTTP::Response: ... from HTTP::Headers ... never mind, you get the idea ... Or you can take the easy approach, and stop with the first one... $mech-link_status_is( 'http://localhost/private/', 401, /private returns a 401 ); Or, if you've made the request already: $m-status signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Authentication for web services (slightly off topic)
Andrew Payne wrote: On Jan 23, 2008 2:30 PM, Ian Docherty [EMAIL PROTECTED] wrote: This might seem like a stupid question, and one that probably has a I could use Apache Basic Authentication, but I would prefer to hold usernames passwords in a database rather than a htpasswd file. Just do my ($username, $password) = $c-req-headers-authorization_basic; There's no need to have Apache handle it. I have an app with both an HTML and a REST/XML interface (under '/REST/'), and simply give the REST controller its own auto() sub, containing the above line. Works fine. Andrew I went down an similar somewhat evil path for Mango. Since Mango has a custom Auth store/user anyways, I make my authenticate forward to authorization_basic when no options were passed: ## uses Auth/Store $c-authenticate({ username = $user, password = $pass }); ## uses HTTP Auth plugin $c-authenticate(); signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Authentication for web services (slightly off topic)
Andrew Payne wrote: On Jan 23, 2008 4:28 PM, Matt Lawrence [EMAIL PROTECTED] wrote: WWW::Mechanize isa LWP::UserAgent. Ditto T::W::M::C, AFAIK. Yes, but how does that help when we're using get_ok(...) ? I accidently chopped too many lines from the previous snippet. print $ua-request($req)-as_string; Gives the LWP $ua the HTML::Request $req and executes it. I can't see a way to feed T::W::M such a request object. Sorry, we're straying a bit here. Andrew $m = Test::WWW::Mechanize::Catalyst-new; $m-credentials('admin', 'admin'); signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Why no extra attributes on Private actions?
Bill Moseley wrote: In Catalyst::Controller register_actions() there's this code: my $attrs = $self-_parse_attrs( $c, $method, @{ $cache-[1] } ); if ( $attrs-{Private} ( keys %$attrs 1 ) ) { $c-log-debug( 'Bad action definition ' . join( ' ', @{ $cache-[1] } ) . qq/ for $class-$method/ ) if $c-debug; next; } Why are no other attributes allowed if the action include the Private attribute? This came up because I'm using SSL to indicate actions that require SSL: sub secret : Local SSL {} But, it would also be handy to be able to protect all actions below a give controller via: sub auto : Private SSL { 1 } Why not just leave off Private altogether? I did that with index/default all the time until I weend myself off of them for Chained for just that reason. Now, about the sub named 'index' being a special name that does evil when you do sub index : Chained because is the most appropriate name.. that's another story... -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Mango, Catalyst and Class::Workflow
This is a plea from a drowning sailor for a life boat, or at least life vest and a pointer towards the nearest shore. It's that point in Mango where I need to start the really nasty bits: checkout. Since everyone wants something different, it seems that basing things on Class::Workflow at least makes this possible. Handel touched on checkout by not implementing one at all and instead just allowing a set of plugins to molest an order record one plugin at a time in an combination of groups of plugins. The problem of course, is that C::W makes my brain melt when I try to layer it on top of my old school views of checkout. I've started to look at http://is.tm.tue.nl/research/patterns/ which helps, but since there are far smarter people in here than I, now's the time for input. If you were in my shoes, what approach would you take? I'm envisioning some form of Class::Workflow (yaml from config) that defines each step in terms of what Cat Controller/actions and what plugins each action runs. That seems a bit too tied into Cat itself, and doesn't address the overall problem of what to display for each step (preview? shipping options? payment page, etc) if you seperate the workflow from the presentation. Anyone done heavy lifting of Class::Workflow inside of a Catalyst app before? -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst, REST and Firefox
Jonas Alves wrote: On Jan 17, 2008 2:32 PM, Christopher H. Laco [EMAIL PROTECTED] wrote: I've touched on this before, and posted about it on UP: http://use.perl.org/~jk2addict/journal/35411 In a nutshell, Firefox 2.x Accept header totaly screws with the REST controller when you use it as a base for View negotiations. If you have a default type of text/html pointed to a View::TT, REST will see text/xml from Firefox and try and send that instead, based on this header: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 What does everyone think about a config option/toggle to tell REST to ignore the Accept header, allowing it to fall back to the default content-type in config when no Cntent-Type header or content-type params are specified? -=Chris I have a subclass of Action::Serialize that does this: my $default = $controller-config-{serialize}{default}; my $pcontent_type = $c-req-preferred_content_type; my $content_types = $c-req-accepted_content_types_qvalue; my $ordered_content_types = $c-req-accepted_content_types; my $max_qvalue = $content_types-{$pcontent_type}; my %max_qvalue_content_types = map { $content_types-{$_} eq $max_qvalue ? ($_ = $default) : () } keys %$content_types; my $content_type = $max_qvalue_content_types{$default} || $pcontent_type || $c-req-content_type; And in a subclass of Request::REST mixed with Plugin::Flavour: sub preferred_content_type { my $self = shift; if ($self-flavour) { my $type = $self-{ext_map}{$self-flavour} || $self-_ext_to_type($self-flavour); return $type; } $self-accepted_content_types-[0]; } sub accepted_content_types_qvalue { my $self = shift; return $self-{content_types_qvalue} if $self-{content_types_qvalue}; my %types; if ($self-method eq GET $self-param('content-type')) { $types{ $self-param('content-type') } = 2; } # This is taken from chansen's Apache2::UploadProgress. if ( $self-header('Accept') ) { $self-accept_only(1) unless keys %types; my $accept_header = $self-header('Accept'); my $counter = 0; foreach my $pair ( split_header_words($accept_header) ) { my ( $type, $qvalue ) = @{$pair}[ 0, 3 ]; next if $types{$type}; $qvalue = 1 unless defined $qvalue; $types{$type} = sprintf '%.3f', $qvalue; } } return $self-{content_types_qvalue} = \%types; } That way all works fine. If you add an extension to the uri (like .json or .xml), it serves that content-type. Else it tries to find the greater qvalue on the Accept Header and tries to serve that. If it has more than one content-type with the same max qvalue it tries to find the default content-type in that list and serve it. If it isn't in the max qvalue list than it serves the first content-type on that list. I think that is a sane approach. Well volunteered! I can't speak for the flavour stuff, but I'd think the q value logic would be well served in the REST package. :-) I'd personally like the flavour stuff in there as well. In my case, I'm half way there. I have a type= that takes a friendly name (atom, rss, json) ... along wieh adding some of those content types to MIME::Types since it's missing a few of them for type-extension mapping. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Loading Plugins from lib/MyApp/Plugins
Ash Berlin wrote: On 18 Dec 2007, at 02:39, Christopher Laco wrote: I know I've been down this thread before. When writing a framework that generates customized Catalyst apps, it would be a whole lot easier (well, more proper) to add plugins in lib/MyApp/Plugins, just like we do with controllers/models/view, than it is to molest the MyApp.pm 'use Catalyst' line to include custom plugins. I don't quite see the point of this. Why not just add methods to MyApp.pm? (I'm guessing there might actually be a sane reason for you not wanting to do it this way, but I can't grok what it is) Ash Mainly, because there is no automated, programmatic way to add plug ins to a generated Cat app without editing code. The scenario is: mango.pl MyApp which in turn, uses $helper-mk_app, just like catalyst.pl MyApp does. After that point, my scripts can add models, view and controllers just dandy, but there's no way to add plugins unless I literally open MyApp.pm in the script, and do: s/ ConfigLoader StaticSimple / ConfigLoader MyApp::Plugin::Foo OtherApp::Plugin::Bar Static::Simple / That's nasty at best and will fail eventually when the defaults change. I can add models/view/controllers by dropping files in the correct directories, why not plugins? Aside from Mango, anyone who generates Cat based apps automatically when accounts are created (like virtual hosts...MediaTemple) may want or need to also install default plugins. Just dorpping them in a Plugins directory just like M/V/C makes more sens than trying to automatically edit code in my book. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [RFC] Loading Plugins from lib/MyApp/Plugins
Christopher Laco wrote: I know I've been down this thread before. When writing a framework that generates customized Catalyst apps, it would be a whole lot easier (well, more proper) to add plugins in lib/MyApp/Plugins, just like we do with controllers/models/view, than it is to molest the MyApp.pm 'use Catalyst' line to include custom plugins. I'm assuming that it's just a matter of tweaking the Module::Pluggable search paths at the appropriate time when Cat is starting up. Is this a planned feature for 5.8? Could it be? Yes, I'll volunteer to put some tuits on it if need be. -=Chris Just to keep the conversation rolling, let's put aside the Plugins directory for the moment. If you wanted to load plugins from config, what would you like to see? What would you need? 1. Load all plugins specifically from config, ignoring what's in MyApp.pm when specified? plugins: - ConfigLoader - Session - Session::State::Cookie - Session::Store::File - +MyApp::Plugin::Frobnisicate - Static::Simple 2. Load plugins from a location? plugins: path: __path_to(lib, MyApp, Plugins) 3. Prepend/Append plugins to be loaded around MyApp.pm? plugins: prepend: - Debug append: - Static::Simple - +MyApp::Plugin::Foo -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] ASP.NET MVC
I'm still holding hopes for: Chained('../') -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Setting the Catalyst Request object
Bill Moseley wrote: Yesterday I needed to add JSON support (both in the request and response) to a few actions. I decided to try Catalyst::Action::REST. Well, actually, I first tried using just C::A::Serialize and C::A::Deserialize -- but was not sure if those could be used separately. That didn't work so then I just tried using the full REST setup as described in the calendar. Well, that brings in C::Request::REST, which set the request object, and I already have C::P::Server which does the same thing. Is there a way that multiple add-ons can work better together when they need to add methods to the request object? I would think you could beat them at their own game. Make your own subclass, which inherits from both of their Request subclasses. Then, just have Cat use yours instead. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] C::P::Authentication - user not found debug info
Matt Lawrence wrote: Tobias Kremer wrote: Hey all, my log files are filling up with the following warning [debug] Unable to locate user matching user info provided This info is both annoying and not really helpful IMHO. I found out that it's issued via $c-log-debug() and immediately wondered why this produces output even when using catalyst in non-debug mode? Debugging in the logger is orthogonal to debugging in the application, AFAIK. $c-log-disable('debug', 'info'); or $c-log-levels(qw( warn error fatal )); Assuming you're using the default Catalyst::Log logger. Matt Of course, on top of that answer, there's this answer: It seems the 'preferred' way to debug output is: $c-log-debug('boo') if $c-debug; There's still a lot of code out there that doesn't do that. It's esp. noticeable when you're running a test suite with CATALYST_DEBUG=0 and you still get various straggler output. Patches welcome. :-) I've seen this issue in Auth, as well as the REST modules. Just haven't sent patches yet. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] catalystframework.org exired
Bernhard Weißhuhn wrote: Oh no! somebody renew catalystframework.org! Quick! Until *they* get it. regards, bkw Unfortunately...it appears the GoDaddy is one of the ones that doesn't allow anyone to renew a domain name. It only appears to allow the registrant to do so. At least with NetSol, I could pay for anyones renewal. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] catalystframework.org exired
Bernhard Weißhuhn wrote: Oh no! somebody renew catalystframework.org! Quick! Until *they* get it. regards, bkw Just called GoDaddy. This is so fucked up. They won't let anyone pay for renewal who isn't the last person/card on file with the 4 digit pin or the same credit card. That's retarded. They say it's because the person who last paid for it could move it and take control...aka, their system is fucking broken. That just makes me want to find another registrar that isn't so broken. :-( -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
Ashley Pond V wrote: That is really cool and answers something I've wanted to do for a long time (let the user define the URI to customize a package). I have a question. Using the PathPrefix seems to work as advertised but it does not replace the default path. So, in a test I just did, MyApp::Controller::Article with __PACKAGE__-config( path = 'a' ) gives the expected, new, result at path /a but also still responds at /article. Seems like this is not DWIW or M. (I'm using the sample sub in the post, not the trunk code). The others replace correctly though(?). /a == /article but /a/id works while /article/id fails as I'd like. -Ashley Someone correct me if I'm wrong, but I don't believe PathPrefix is in a release yet...only current source, which is probably going to be 5.9. I still, as of the latest release on CPAN, have to add the PathPrefix attr parsing sub. Good old LTjake. That post has save me many hours of crying...over, and over with chained. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PathPart help
Les Fletcher wrote: I have question about setting up PathPart's and Chaining. I am trying to set something that has the following look: /namespace/ = This lists out a list of objects /namespace/id = displays detail information about the object with the numeric id=id /namespace/id/edit = brings up a form to edit object with numeric id=id /namespace/create = brings up a form to create a new object When the Chained actions are printed out everything looks fine, but when I goto /namespace/create it matches the /namespace/id view action. Needless to say, there isn't an object with the numeric id of create. I would like for Catalyst to try and match the explicit PathPart before matching the wild card that is id. Any thoughts on best ways to get around this? A couple of ways I thought of were: I could make the view path be /namespace/id/view, it seems a little weird, but would be acceptable if need be. I could have an action that matches /namespace/* and then forward to the create action if * is create and to the view action other wise, but this could limit my ability to further chain from here. Catalyst just might not match the paths in a way that is conducive to this, but just thought I'd throw this out there. Les http://use.perl.org/~LTjake/journal/31738 -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Credential::HTTP vs. Controller::REST
I'm working with the REST action/controller to expose my app to browsers and to any remote client (json/xml, etc). For the browser stuff, I just use the regular Auth plugins with a database store tied to a user/pass login form. For remote clients, I wanted to tack on HTTP Auth using Basic/Digest. Lucky for me, we have C::P::A::Credential::HTTP, which can consume and create the proper Basic/Digest auth headers. Unfortunately, when this credential class creates the appropriate 401 response code and headers when auth is required, it assumes that the content-type is text/html, and the body() needs to contain text (Authorization Required). IMHO, this is bad. I don't believe the it's the responsibility of this credential to set/assume the content-type/body for me, but only to manage reading/writing the auth headers. Under normal operation, the REST controller receives a request for a certain content-type, and if I set the status code myself to 401 and detach, the outbound response is automatically set to that requested content-type with an empty serialized entity (empty YAML, null in JSON, etc) Since the HTTP auth credential assumes is needs to set content-type and body(), those trash what the REST controller is doing during serialization of the response. When it does that, response to clients that have requested yaml/json now get tesr/html and a body they can't consume. It mentioned in the HTTP Auth pod that one could override these in end(), but that means that I have to spend time in my end() sub reimplementing logic that is already handled by the REST controller, just to get the content-type/body back to the proper output. At this point, I just wanted to get the conversation started on what every thinks the correct behavior is, and if there are any work around for this type of problem. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Selective debug output
J. Shirley wrote: On Nov 6, 2007 5:47 PM, Jonathan Rockway [EMAIL PROTECTED] wrote: Joe Landman wrote: How do I selectively enable or disable debugging output? Specifically, FormBuilder debugging output is simply far to verbose to be meaningful to us. I suppose I could simply pass in a debug=0 when I create the form. Is there any global way? FWIW: I only want to surpress formbuilder output during debug. Unfortunately there is no way to do what you want. Most of the plugins (etc.) just check $c-debug to see whether or not to log via $c-log-debug. I suggest a filter in a custom log class (just regex the formbuilder crap out), or fixing the plugins/controllers to check $c-config-{pluginname_debug) or something. Maybe we can make this easier in 5.8; suggestions welcome. Regards, Jonathan Rockway I would prefer something like: MyApp-config( 'PluginName' = { debug = 0 } ); Thoughts? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/ On a somewhat related note. While writing REST tests thius weekend, I set CATALYST_DEBUG=0, yet C::A::REST insisted on debugging anyway. I guess I never realized that you always have to check $c-debug first, and assumed $c-log-debug would go to the bit bucket if CATALYST_DEBUG was false. In my case, I just cheated, and had MyApp::debug do the check first to squelch all of the non believers. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Preventing Catalyst from loading a Controller pm module
Oleg Pronin wrote: I put these things into MyApp::SAME_AS_CATALYST_BASE_CLASSES, i.e: MyApp::Catalyst::Controller MyApp::Catalyst::View::TT etc. It's clean and nice :) I do the same thing. It works out great if you have a lot og MyApp:: modules that have nothing to do with Catalyst, like fat or domain models, etc. -=Chris -- Let them eat cake and false positives. -BEGIN NSATT SNOOP BLOCK- building bomb tower terrorist grenade c4 explosive plot hijack plane police feds white house guns dirty device convoy president war chemical death drop off mule undercover launch rocket drug covert cell cerin mass infidel Allah package subway mass --END NSATT SNOOP BLOCK-- signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Chained Madness
What am I missing here. This passage from DispatchType/Chained.pm yields no public actions: Another interesting possibility gives :Chained('.'), which chains itself to an action with the path of the current controller's namespace. For example: # in MyApp::Controller::Foo sub bar : Chained CaptureArgs(1) { ... } # in MyApp::Controller::Foo::Bar sub baz : Chained('.') Args(1) { ... } This builds up a chain like /bar/*/baz/*. The specification of . as the argument to Chained here chains the baz action to an action with the path of the current controller namespace, namely /foo/bar. That action chains directly to /, so the /bar/*/baz/* chain comes out as the end product. When I create a fresh MyApp and the controllers/code above and load it, I get no Loaded Chain Actions in the debug output. Is this example incomplete? -=Chris -- Let them eat cake and false positives. -BEGIN NSATT SNOOP BLOCK- building bomb tower terrorist grenade c4 explosive plot hijack plane police feds white house guns dirty device convoy president war chemical death drop off mule undercover launch rocket drug covert cell cerin mass infidel Allah package subway mass --END NSATT SNOOP BLOCK-- signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] Firefox input type=image issues?
[EMAIL PROTECTED] wrote: Christopher, I have run into this issue as well, every time it appeared to be because one or more web developer extensions were loaded on the client and were causing the issue. I have not tracked it down to which ones or the settings that seem to cause it (greesemonky, firebug, etc), but removing firefox and doing a fresh install nix any extensions/plugins seems to fix it. -Wade Christopher H. Laco [EMAIL PROTECTED] wrote on 10/26/2007 10:04:36 AM: I posted this to UP, and wondered if anyone has run across this issue during their Catalyst hacking sessions. There's a long standing bug/feature with Firefox with input type=image elements. When the user has images turned off, the image is 404ed or just not loaded...when it's clicked, no x/y coords are sent to the server. Just this week, we've had complaints from users getting an error on our site they shouldn't. As it turns out, they get the error because we check to make sure button.x and button.y have values...but Firefox is passing them without values. Now, for the odd part. This is happening to people who by all appearances, have the image loaded. My Firefox 2/3 work just dandy, yet we have one internal user who gets the error (but the image is loaded via a provided screenshot). I have no idea what the hell is going on, but it's damn strange. This is about as much fun as the other gecko bug I found in the old Compuserve7 version, where if you used javascript to hide a button after it was clicked, the browser would post nothing with a Content-Length: 0. Anyone else seen this before? I can check the request elements to make sure button.x and butt.y were sent, even without values to fix the problem, but at this point I'd like to know what's really going on here. -=Chris -- Let them eat cake and false positives. -BEGIN NSATT SNOOP BLOCK- building bomb tower terrorist grenade c4 explosive plot hijack plane police feds white house guns dirty device convoy president war chemical death drop off mule undercover launch rocket drug covert cell cerin mass infidel Allah package subway mass --END NSATT SNOOP BLOCK-- [attachment signature.asc deleted by Wade Stuart/FALMSP/USA/NA/FALLON] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/ To make matters more interesting... Firefox2 will also not send coords if I hit Return when the image button is highlighted. Firefix3 does send coords if I hit the REturn button instead of clicking on it. On top of the, the internal user having the problem has a fresh 2.0.0.8 install...no extensions. -=Chris -- Let them eat cake and false positives. -BEGIN NSATT SNOOP BLOCK- building bomb tower terrorist grenade c4 explosive plot hijack plane police feds white house guns dirty device convoy president war chemical death drop off mule undercover launch rocket drug covert cell cerin mass infidel Allah package subway mass --END NSATT SNOOP BLOCK-- signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Handel Installation Problems
Collin Condray wrote: Christopher, It looks like DBD::SQLite 1.14 is installed. Do I need to use a different version? I don't believe so. This is a bug in DBD::SQlite 1.13/1.14 where the query immediately after a failing 'pk value already exists' error also failsand of course, I keep not writing a test and RT for this. The test suite skips thoses tests under 1.13, but I haven't updated them to skip for 1.14 now that I know the bug still exists. This only effects the tests in those .f files that actually do error checking around PK violations. If you're going to be using MySQL for your app, don't worry about it. If you're going to be using SQLite, I personally would stick with 1.12. -=Chris signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/