Re: [Catalyst] REST-like url question
On Wed, May 18, 2011 at 9:22 AM, Bill Moseley mose...@hank.org wrote: Other options would be: GET /user/1234/sessions_attending GET /user/1234/sessions_presenting What would you use? Could you pull this off? GET /user/1234/sessions GET /user/1234/sessions/attending GET /user/1234/sessions/presenting GET /user/1234/sessions/attending+presenting This is similar to how del.icio.us handles tags. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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: fcgid
On Wed, Oct 1, 2008 at 4:15 AM, Pedro Melo [EMAIL PROTECTED] wrote: Hi, On Sep 30, 2008, at 1:14 AM, Aristotle Pagaltzis wrote: * John Lee [EMAIL PROTECTED][EMAIL PROTECTED] [2008-09-29 16:05]: What's the general concensus in the catalyst community nowadays? Is mod_fastcgi preferred at large over mod_fcgid these days? Personally? ::Engine::HTTP::Prefork + ::Plugin::Static::Simple. +1 for ::Engine::HTTP::Prefork. Have any of you ::Engine::HTTP::Prefork users written init scripts for starting and stopping your Catalyst apps? --beppu ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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: [SOT] cat webmail app?
On Fri, Aug 8, 2008 at 3:20 PM, Ashley [EMAIL PROTECTED] wrote: I CAN HAZ EEMAEL™ I expect full faith and credit, residuals, points on gross not net, et cetera and so on and so forth. Ashley wins. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Squatting::On::Catalyst
On Tue, Jul 29, 2008 at 5:21 AM, Daniel McBrearty [EMAIL PROTECTED] wrote: my 0.05 (possibly a bit OT) : Off-topic or not, I think these are interesting and valid questions. I looked previously at a few ways of adding forums etc to the site using 3rd party code, indeed there are many possibilites (some perl, some not) The thing that was always a sticker for me was getting some kind of logical integration, ie: 1. letting users keep existing member and login creds Now that composition and embedding of web apps is becoming a reality, we have to start anticipating needs like this. For example, the documentation for an app that's built to be embedded could state that: - It expects a user object to be in its session's u key. - The app will expect to be able to call the -name method on this user object. (Some apps may want more... others less... this is just a hypothetical example.) - If that key is undef, the app will assume the current session is not in a logged in state. I think being up-front about login policy would be enough to share users across multiple web apps joined together as one cohesive unit. 2. being able to cross ref to other parts of the site eg. for a certain node, easily have a discussion link, and the reverse link from the forum I haven't thought about this problem much at all. My initial thought is that (again) the app that's going to be embedded would have to be written to anticipate this kind of need. Perhaps the app-to-be-embedded could provide a configuration option for the embedder to fill in with an appropriate value. This option would control how links would be generated in key portions of the app. I haven't yet seen a way to do this that looks easier than doing it from scratch (well, lets say some heavy porting of existing db structures and code from existing stuff ...) IMO getting these kind of features right are where the real meat is. Looking at the summary, I guess that's not what the focus of this project is, so if this is post is basically just noise, please forgive that. No need for apologies. The questions that you bring up have definitely crossed my mind. It's true that my work so far does not address these questions at all, but at the same time, this kind of work is a sort of prerequisite for these questions. (You couldn't even ask questions about mixing sites together cohesively if you couldn't mix them together at all, right?) --beppu ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/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] Squatting::On::Catalyst
On Mon, Jul 28, 2008 at 2:40 PM, Matt S Trout [EMAIL PROTECTED]wrote: On Mon, Jul 28, 2008 at 08:27:27AM -0700, John Beppu wrote: Imagine if you could install a blog, a wiki, a forum, or a store just as easily. Yeah, we'll be doing that for arbitrary Catalyst components for 5.80, I hope. This is still really cool, mind. Good luck w/ that. I don't know the guts of Catalyst too well, but I have a feeling it could be tricky. In the meantime, please have a look at the HTTP::Engine project so that you can share HTTP code with other frameworks, and consider joining the catalyst-dev list since we're planning to kick off a project to see about sharing dispatchers with other projects as well. HTTP::Engine was exactly what I needed when I started the project. I'm glad I know about it, now. -- 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/
