[Dancer-users] dancer bug

P Kishor punk.kish at gmail.com
Mon Aug 16 16:38:12 CEST 2010


Hi Sawyer,

Thanks for your nice email.

On Mon, Aug 16, 2010 at 1:33 AM, sawyer x <xsawyerx at gmail.com> wrote:
> On Sun, Aug 15, 2010 at 3:30 PM, P Kishor <punk.kish at 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
=======================================================================


More information about the Dancer-users mailing list