---
title:         Status Report for Week #4
date:          2011-06-21
layout:        post
category:      gsoc
---
Week #4 was more about writing what I investigated from week #3 into
the module. It felt like a continuation of week #3, but this time what
was studied, it was written. But again, I was lost with what was the
best implementation to take from =Catalyst::Scripts=. Again that doubt,
was the one that made me analyze what I was doing. After a failed
approach to what my mentors were asking for, I came to the solution,
thanks to the help of =sawyer=. After a while, =franck=, gave a review
on what I thought was the correct route. Which is what I needed, an
approach to what I needed to code. If you don't know what you're
doing, you don't know what to code.

*** What I worked on week #4
I added the method =run_scaffold= which will select between to helper
methods, =cgi= & =fastcgi=. Each =run_scaffold_*= is part of
=Dancer::Script=, and are called by =run_scaffold=. Before getting to
this point, I tried a string-to-string comparison, that ended up in a
fail attempt to modify the real issue. You can find the failed attempt
here: [[https://gist.github.com/1038873][https://gist.github.com/1038873]] What I was trying to do, was to
create a new MyApp.pm.new file, scrape the file while looking for the
deprecated functions, as listed in the hash file. This was obviously a
complex approach to a simple solution like
=Dancer::Script->run_scaffold($method)=.

Now that was for =Dancer::Script=, to the actual files dispatch.cgi
and dispatch.fcgi, I just added the following:

#+BEGIN_SRC perl
#!/usr/bin/env perl
use Dancer::Script;

Dancer::Script->run_scaffold($method);
#+END_SRC

Where =$method= can be cgi for =CGI=, and fcgi for =FastCGI=. The last
was influenced by [[http://beta.metacpan.org/module/Catalyst::ScriptRunner#___pod][Catalyst::ScriptRunner]]. That script runner works
just like the method I implemented for the module, but it's more
specific on the App and what process to run or deploy. Which is more
complex than what =Dancer::Script= implements.

This way the core developers or any one contributing to Dancer's
deployment will only have to upgrade the methods =run_scaffold_*=
without needing to touch the code to write the files
=dispatch.{cgi,fcgi}= or any new deployment file.

*** What I learned on week #4
Basically, I moved from thinking that an upgrade process can be
handled by string-to-string comparison, or other read-and-write
algorithms. This is the main advantage behind removing the necessity
of an actual read-and-write upgrade, that way you have a file that
works with the code on a module, but that it doesn't change with newer
versions of Dancer. What really changes, is the module that runs the
deployment code. This will help if any new addition of a major feature
or fix to [[http://plackperl.org/][Plack/PSGI]] is needed on Dancer's deployment. Quickly, any
developer can add the fix to =Dancer::Script::run_scaffold_*= without
touching any dispatch.* file. So for any old Dancer application we
will only need the user to write a new dispatch.* file with the the
=dancer= script without removing the other files in the Dancer app
structure.

*** What's next?
For week #5, the following are the key points:

- Add the module to Dancer's core.
- Run it against several outdated setups.
- Review the results and calibrate the tests to the resulting patterns.

So now it's time to test everything back and test roughly, so my code
doesn't screw up anything. I think this will be the most rough weekend
due to the fact that, I have to do several tasks that aren't relate it
to each other, but with the help of my mentors I guess I can be back
on track. Not that I'm off the track, but I always seem to go ahead of
schedule or go to a different route. My bad.

So the Shout'out is to the Catalyst team and [[http://search.cpan.org/~bobtfish/][Tomas Doran]] for writing
the =Catalyst::ScriptRole= and =Catalyst::ScriptRunner= modules.
(Please do correct me if I'm wrong.)