Hi Sawyer, Thanks for your nice email. On Mon, Aug 16, 2010 at 1:33 AM, sawyer x <xsawyerx@gmail.com> wrote:
On Sun, Aug 15, 2010 at 3:30 PM, P Kishor <punk.kish@gmail.com> wrote:
[...] did anyone actually do that deployment before writing the docs? Because, as the docs are, and given the current version of Dancer, that deployment would simply not work.
Most likely yes. However, Dancer is pretty volatile and even now had another serious overhaul. These are all blessed changes that mostly stem from user requests, listening to user feedback and taking that feedback and changing Dancer appropriately (even if it means major changes) to make users have something they enjoy working with.
..
Now that we're done with this, I want to thank you for opening the proper tickets in the correct place. That will definitely help track issues.
Would you like to help correct the docs? This is where user experience is the most important!
I will be very happy to. Once again, my apologies if I sounded harsh, but I want to emphasize, my intent is not to be the squeaky wheel that takes up all the available grease. My intent is to make Dancer better. Yesterday, I seriously waffled between trying other "promise the world but still at version 0.0012 alpha quality" web frameworks such as Mojo and Web::Simple, or going back to the "rock-solid but boring as heck" CGI::Application, but was loathe to give up on Dancer (craps, during a momentary lapse of reason, I even though chucking Perl and going with Sinatra, Dancer's original inspiration). There is something very elegant about Dancer's approach, and I didn't quite feel ready to wave it goodbye. Here is what I want to do -- I have three different apps, app1, app2, and app3. These can be placed anywhere on the filesystem. Heck, they could even be on three different computers eventually. That is how I want. Three apps capable of standing on their own. However, these apps are related. They are accessed like so: app1: http://server/app1 app2: http://server/app1/app2 app3: http://server/app1/app3 In that sense, app1 is kinda like a mother-app, and app2 and app3 "inherit" from app1. The child-apps look like app1, they have the same menus, just one level deeper (see below for an "image"), and share the authentication mechanism. When I created this set of applications with CGI::Application, I created a master app, and then inherited apps[1..3] from the master app. Anyway, that is the design. Now, wrt deployment, it has to work with Apache(2). There is no question about that. As I said before, even on my personally controlled servers, Apache is already installed, and is a prerequisite for a couple of other projects, so I just can't manage complexity by way of alternative web servers. Also, on my shared host web sites, Apache is the backbone. Also, for starters, it has to work with Apache CGI. Eventually, I will move to a more persistent environment such as mod_perl (most likely -- has anyone tried mod_psgi yet?). Soon, as I am completely successful in creating the above scenario, I will write detailed instructions that even a newbie like me would be able to follow. That is my promised contribution to the Dancer project. Many thanks for your help. And, hey, many thanks for the Dancer::Template::Tiny wrapper. That is what I am using. It is brilliantly simple and fast. -- Puneet Kishor http://www.punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Commons Fellow, http://sciencecommons.org/about/whoweare/kishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu ----------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science =======================================================================