Howdy all,<br><br>I've put together an RFC for the new Catalyst::Helper API. <br>The body text is located below, but it is also available here in a pretty formatted version:<a href="http://www.codedright.net/2009/06/rfc-catalysthelper-api.html">http://www.codedright.net/2009/06/rfc-catalysthelper-api.html</a><br>
<br>For the improvement of the Catalyst::Helper API and Catalyst development in general, comments are of the utmost importance. The more feedback<br>I can get, the better and quicker the API will be completed.<br><br>Thank you kindly!<br>
<br>-dhoss<br clear="all"><br><b>Intro:<br></b>This document is to get opinions on a new, up to date set up and refactoring of the Catalyst::Helper API.<br><br><b>What We Have</b><br>Currently,
all template/image data is hideously store inline with code in the
__DATA__ section of Catalyst::Helper.pm. The API is designed to handle
data this way, which is wrong wrong wrong for a number of reasons:<br><ol><li> You have to actually delve into Catalyst internals to edit any of these files</li><li> If you create a helper, your data must be inline as well.</li>
<li> Its
current layout does not reflect the directory hierarchy of a Catalyst
application, thus making it pretty dang hard to expand upon/upgrade.</li></ol>There
are no methods to allow you to edit previously created files, unless
you want to create your own helper and feverishly create your own file
modification method(s).<br>I can attest to the stress this causes, as
I've been doing a good deal of yak shaving cleaning this code up and
creating the proper tests for it. It's not a very fun ordeal at this
point.<br><br><b>What we want</b><br>From the feedback I've gathered thus far: <br><br>We <b>do</b>
want previously created helper files to be modifiable via
Catalyst::Helpers. For instance, updating Makefile.PL, updating
myapp.conf to reflect changes, updating DBIC schema files to reflect
database changes (with minimal pain). Also, add an infrastructure for
modifying existing catalyst code, e.g. moving
Catalyst::Helper::AuthDBIC from an experimental proof of concept to
something that people might actually want to use for their own stuff.
<br><br>We <b>do</b> want to be able to remove a good deal of the
boilerplate code that still seems to need to be created manually, for
each app, even though it's the exact same code for each instance. <br><br>We <b>do</b>
want to set up the helper files in the hierarchy that a Catalyst
application is created in, thus cutting quickly to the chase in the way
of creating an app. It's a simple name and Template::Toolkit variable
translation, then writing the file to the filesystem process then.
This gets our binary data out of the API code, the template data out of
the API code, and generally makes every one more happy. <br><br>With
this said, here are some more specific ideas that have been passed my
way that I think would really help further advance our precious Helper
API:<br><br><ol><li> Beat up MooseX::Getopt to deal with pass-through
options, so you can deal with passing data structures as arguments
easier. Not to mention actually start USING it in the Helper API.</li><li>Add
a feature to write out DBIC schema files for deployment. Yes,
make_schema_at does this, but you have to write your own little script
to enjoy this morsel of functionality. It would be nice to have it
packaged up and ready to go for you.</li><li>Have something like
TTSite, but less sucky. Perhaps there could be a default layout that
can be created, or you can create your own sort of skin and have that
the default generation. Or, better yet, packaged skins that users can
submit to $somewhere and have the author choose a "theme" for their
app. For instance, using $javascript framework and $css framework to do
so, like in chapt 11 of the upcoming book (Example usage: <a href="http://www.uow.edu.au/%7Ekd21/">http://www.uow.edu.au/~kd21/</a>)</li></ol>These
are the current ideas I have, and that others have submitted. Sure
this RFC is a bit bare, but we don't have a whole ton to work with at
the moment with Catalyst::Helper, so we need more feedback to beef
things up.<br><br><br>-- <br>Devin Austin<br><a href="http://www.codedright.net">http://www.codedright.net</a><br><a href="http://www.dreamhost.com/r.cgi?326568/hosting.html">http://www.dreamhost.com/r.cgi?326568/hosting.html</a> - Host with DreamHost!<br>