Re: [Catalyst] Squatting::On::Catalyst
* On Tue, Jul 29 2008, John Beppu wrote: 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: Expectations suck. Use Ernst, tag your attributes and classes with the necessary metadescription, and introspect. The user should tell the computer what to do, not the other way around. * It expects a user object to be in its session's u key. The Session should be a class of course, and the class should have an attribute with a metadescription that does Squatting::Description::User, or whatever. * 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.) The User class should have a class metadescription that describes what methods return what data. * If that key is undef, the app will assume the current session is not in a logged in state. Why not force the class to implement a role that provides a user_is_logged_in method? Then there is no need to guess. Just call the method and see. (Actually, it would be better to be able to meta-describe methods... but I haven't implemented this yet.) - Someone else mentioned in another post how this sort of thing is impossible with forms, but it's actually not. Ernst and Reaction have solved this problem. We generate the DBIC files from the row class's metadescription, and we generate the form handling code from the same metadescription. Unfortunately all of my examples are locked up in internal code right now (very experimental), and I think mst's code is mostly in the same state :) Anyway, here is an old Ernst demo: http://git.jrock.us/?p=Ernst.git;a=tree;f=prototype/catalyst/TestApp;hb=HEAD The important part: http://git.jrock.us/?p=Ernst.git;a=blob;f=prototype/catalyst/TestApp/lib/TestApp/Backend/Record.pm;hb=HEAD Anyway, it turns out that this is a simple problem, but just needs some tweaking for maximum enjoyment and ease of use. (We've gotten rid of TT in the production version, for example, because the fragments are too hard for designers to work with. Instead, we are using Template::Refine.) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Squatting::On::Catalyst
--- On Fri, 8/1/08, Jonathan Rockway [EMAIL PROTECTED] wrote: From: Jonathan Rockway [EMAIL PROTECTED] Subject: Re: [Catalyst] Squatting::On::Catalyst To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Friday, August 1, 2008, 2:57 AM * On Tue, Jul 29 2008, John Beppu wrote: 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: Expectations suck. Use Ernst, tag your attributes and classes with the necessary metadescription, and introspect. The user should tell the computer what to do, not the other way around. * It expects a user object to be in its session's u key. The Session should be a class of course, and the class should have an attribute with a metadescription that does Squatting::Description::User, or whatever. * 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.) The User class should have a class metadescription that describes what methods return what data. * If that key is undef, the app will assume the current session is not in a logged in state. Why not force the class to implement a role that provides a user_is_logged_in method? Then there is no need to guess. Just call the method and see. (Actually, it would be better to be able to meta-describe methods... but I haven't implemented this yet.) - Someone else mentioned in another post how this sort of thing is impossible with forms, but it's actually not. Ernst and Reaction have solved this problem. We generate the DBIC files from the row class's metadescription, and we generate the form handling code from the same metadescription. Unfortunately all of my examples are locked up in internal code right now (very experimental), and I think mst's code is mostly in the same state :) Anyway, here is an old Ernst demo: http://git.jrock.us/?p=Ernst.git;a=tree;f=prototype/catalyst/TestApp;hb=HEAD The important part: http://git.jrock.us/?p=Ernst.git;a=blob;f=prototype/catalyst/TestApp/lib/TestApp/Backend/Record.pm;hb=HEAD Anyway, it turns out that this is a simple problem, but just needs some tweaking for maximum enjoyment and ease of use. (We've gotten rid of TT in the production version, for example, because the fragments are too hard for designers to work with. Instead, we are using Template::Refine.) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ So, you're suggesting that the shared interfaces, such as User, ect., be defined via MetaDescription Roles and then having some sort of interpreter? I think I can see how this buys flexibility. If you could help me understand I bit I'd be grateful. I was thinking at first we could do this like (Entities and fields purely for example) ## Common Interface CatalystX::Common::Role::User; use Moose:Role; requires qw(name dob ...); ## Application implementation MyApp::Role::User; use Moose::Role; with 'CatalystX::Common::Role::User'; requires qw(my domain specific stuff); MyApp::Storage::Schema::Result::User; use Moose; with 'MyApp::Role::User'; extends 'DBIx::Class'; all the rest of your storage implementation But if this was MetaDescription the implementation would be more like? MyApp::Role::User; use Moose::Role; requires qw(my domain specific stuff); __PACKAGE__-meta-metadescription-apply_role( 'CatalystX::Description::Trait::User', ); I guess then you'd need something to interpret the MetaDescription at the Storage level. To be honest, I can see how this is very useful for declaring UI behaviors, but not completely seeing how it can play the role of a business logic interface. Am I on a totally wrong track here? --jjnapiorkowski ___ 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 Wed, Jul 30, 2008 at 12:02:08PM +0100, Ash Berlin wrote: On 30 Jul 2008, at 02:27, John Beppu wrote: 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. I dont. Lets take the example of embedding a forum. It will most likely store its data in a DB of its own design. It will also quite likely have its own user table, and have FKs referencing that table see the problem? There's more to sharing users than just logging. I can't really see any way around that other than on a case-by-case basis sadly. Someone please feel free to correct me. Assume all apps use (uid, username, password). Then if they're all also using DBIC, it's fairly easy. Each sub-app uses the same credential and a store that maps to -its- user class. We need to have attribute names and column names truly separated though, which means DBIC 09 most likely. -- 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] Squatting::On::Catalyst
On Tue, Jul 29, 2008 at 02:08:21PM +0100, Chisel Wright wrote: On Tue, Jul 29, 2008 at 02:21:10PM +0200, Daniel McBrearty wrote: 1. letting users keep existing member and login creds 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 If you ever think of a good way of doing this, please let me know! Starter for 10. Controller Page discussion_controller MyForum::Thread discussion_action view discussion_field thread_id /Controller $c-uri_for( $c-controller($self-discussion_controller) -action_for($self-discussion_action), [ $current_page-id ] ); -- 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] Squatting::On::Catalyst
On 30 Jul 2008, at 02:27, John Beppu wrote: 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. I dont. Lets take the example of embedding a forum. It will most likely store its data in a DB of its own design. It will also quite likely have its own user table, and have FKs referencing that table see the problem? There's more to sharing users than just logging. I can't really see any way around that other than on a case-by-case basis sadly. Someone please feel free to correct me. -ash___ 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 Wed, 7/30/08, Ash Berlin [EMAIL PROTECTED] wrote: From: Ash Berlin [EMAIL PROTECTED] Subject: Re: [Catalyst] Squatting::On::Catalyst To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Wednesday, July 30, 2008, 7:02 AM On 30 Jul 2008, at 02:27, John Beppu wrote: 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. I dont. Lets take the example of embedding a forum. It will most likely store its data in a DB of its own design. It will also quite likely have its own user table, and have FKs referencing that table see the problem? There's more to sharing users than just logging. I can't really see any way around that other than on a case-by-case basis sadly. Someone please feel free to correct me. -ash --- On Wed, 7/30/08, Ash Berlin [EMAIL PROTECTED] wrote: From: Ash Berlin [EMAIL PROTECTED] Subject: Re: [Catalyst] Squatting::On::Catalyst To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Wednesday, July 30, 2008, 7:02 AM On 30 Jul 2008, at 02:27, John Beppu wrote: 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. I dont. Lets take the example of embedding a forum. It will most likely store its data in a DB of its own design. It will also quite likely have its own user table, and have FKs referencing that table see the problem? There's more to sharing users than just logging. I can't really see any way around that other than on a case-by-case basis sadly. Someone please feel free to correct me. -ash I'm not sure we can have a fully sharable system for the reasons you mentioned. Everyone has particular needs and desires in the way they will name things, normalize/denormalise a database, etc. However I think it might be possible to define common functionality using Moose Roles and then letting people write their custom code against that. Then we could actually build shared bits that require models that do those roles. Something like: CatalystX-CommonModels /lib /CatalystX /CommonModels /Role User.pm /Provider Users.pm ..and so on for defining Controllers and commone View types, even Action objects. The common Role stuff would be defined by the community to have the minimal requirements. So then I could write a custom application, like say an addressbook app that expects a model that does the User Role. That User role could be defined by some existing other set of components, from maybe a Forum Application or just a roll your own application. This would enable interoperability without forcing a particular implementation. Your local implementation
Re: [Catalyst] Squatting::On::Catalyst
The usual way to make things like this work is by having a standardised api. In the case of membership for a website, it might look something like: get_unique_user_id # of logged in user get_username_for_id( id ) Then if a forum has tables such as: thread - references username post - ditto and maybe methods like send_pm( user ) find_posts( user ) if you are prepared to sacrifice the actual foreign key relationship, not that big a thing IMHO, you can do it all through the API. The person that writes the forum code/schema can actually have two install options - with and without the user table. Cat almost has this in place at present. -- There's an infinite supply of time, we just don't have it all yet. ___ 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 Wed, 7/30/08, Bruce Keeler [EMAIL PROTECTED] wrote: From: Bruce Keeler [EMAIL PROTECTED] Subject: Re: [Catalyst] Squatting::On::Catalyst To: The elegant MVC web framework catalyst@lists.scsys.co.uk Date: Wednesday, July 30, 2008, 3:38 PM Daniel McBrearty wrote: The usual way to make things like this work is by having a standardised api. In the case of membership for a website, it might look something like: get_unique_user_id # of logged in user get_username_for_id( id ) Then if a forum has tables such as: thread - references username post - ditto and maybe methods like send_pm( user ) find_posts( user ) if you are prepared to sacrifice the actual foreign key relationship, not that big a thing IMHO, you can do it all through the API. The person that writes the forum code/schema can actually have two install options - with and without the user table. Cat almost has this in place at present. Seems to me the easiest way would be to have the forum module have it's own user table, keyed by the same user id as the core user table. Then it can store whatever it wants in there, like signatures, posting preferences or whatever. The core user table/object could have a few well-known attributes like real name, email address and so on, but not much else. If we could identify the core entities and attributes, we could write the generic interface and then write a default implementation in one or two of the popular or viable storage systems (DBIC comes to mind because that would be easy for me, as well as MooseX::Storage since that looks like it could be fun :) ) Then when someone creates a their Catalyst application, we say it's best practice that their User model either follow the interface (if they have to write their own, or have very custom needs) or extend one of the popular existing sample implementations. If they do that, what they get is the ability to just plug and run with any extended framework that needs that standard User object interface. Then we don't have to worry at all about how the implementation achieves it's ends, or if the developer has very custom needs. As long as the model implements the interface all will work as desired. After we had some common domain models we could move on and have similar for some basic things we all implement over and over, like a Login Controller, etc. We could stick all this under CatalystX namespace. How about 'CatalystX::DNA' or similar? Besides a User entity, what others do you all think we need? --jjnapiorkowski ___ 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] Squatting::On::Catalyst
On Mon, Jul 28, 2008 at 09:36:44PM -0700, John Beppu wrote: 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. Most interesting features are at least somewhat tricky. Anyway, non-tricky code is boring to write :) 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. Please do pop onto irc.perl.org#http-engine if you need to suggest anything to the devs - they're very happy to hear wishlist stuff from potential users. -- 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] Squatting::On::Catalyst
my 0.05 (possibly a bit OT) : 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 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 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. ___ 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 02:21:10PM +0200, Daniel McBrearty wrote: 1. letting users keep existing member and login creds 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 If you ever think of a good way of doing this, please let me know! -- Chisel Wright e: [EMAIL PROTECTED] w: http://www.herlpacker.co.uk/ What do you call a chav in a box? Innit. ___ 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
I've been meaning to dig into the everything2 code (which powers perlmonks I think, amongst other things ..) and see how they do the cross ref stuff. They seem to have a pretty nice node abstraction which is the core of the problem, I think. the membership stuff relies on a common API, I guess. Doesn't claco have a project that addresses that? On Tue, Jul 29, 2008 at 3:08 PM, Chisel Wright [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 02:21:10PM +0200, Daniel McBrearty wrote: 1. letting users keep existing member and login creds 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 If you ever think of a good way of doing this, please let me know! -- Chisel Wright e: [EMAIL PROTECTED] w: http://www.herlpacker.co.uk/ What do you call a chav in a box? Innit. ___ 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/ -- There's an infinite supply of time, we just don't have it all yet. ___ 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 08:27:27AM -0700, John Beppu wrote: *Squatting::On::Catalyst* Squatting is a web microframework for Perl that's based on Camping from the Ruby world. During the transition from Ruby to Perl, Squatting gained some mutant powers which is why I'm writing to you today. One of Squatting's mutant powers is its ability to embed itself into other frameworks (like Catalyst). You can take whole Squatting apps, and embed them into your existing web application with just a few lines of glue code. Allow me to demonstrate. Assuming Squatting supports CGI, Catalyst::Controlle::WrapCGI enabled this already. Your code is almost certainly more efficient though. *What Are The Implications of This?* Right now, anyone who is developing a web app with Catalyst can install Pod::Server from CPAN and embed it directly into their web app. However, this is just the beginning. 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. 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. -- 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] 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/
