[Catalyst-dev] RFC: new helper api

[Devin Austin]

On Fri, Jun 5, 2009 at 2:28 PM, Zbigniew Lukasiak <zzbbyy at gmail.com> wrote:

> On Thu, Jun 4, 2009 at 4:51 AM, Devin Austin<devin.austin at gmail.com>
> wrote:
> > Howdy all,
> >
> > I've put together an RFC for the new Catalyst::Helper API.
> > The body text is located below, but it is also available here in a pret=
ty
> > formatted
> > version:http://www.codedright.net/2009/06/rfc-catalysthelper-api.html
> >
> > For the improvement of the Catalyst::Helper API and Catalyst development
> in
> > general, comments are of the utmost importance.  The more feedback
> > I can get, the better and quicker the API will be completed.
> >
> > Thank you kindly!
> >
> > -dhoss
> >
> > Intro:
> > This document is to get opinions on a new, up to date set up  and
> > refactoring of the Catalyst::Helper API.
> >
> > What We Have
> > 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:
> >
> >  You have to actually delve into Catalyst internals to edit any of these
> > files
> >  If you create a helper, your data must be inline as well.
> >  Its current layout does not reflect the directory hierarchy of a
> Catalyst
> > application, thus making it pretty dang hard to expand upon/upgrade.
> >
> > 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).
> > 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.
> >
> > What we want
> > From the feedback I've gathered thus far:
> >
> > We do 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.
> >
> > We do 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.
> >
> > We do 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.
> >
> > 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:
> >
> >  Beat up MooseX::Getopt to deal with pass-through options, so you can
> deal
> > with passing data structures as arguments easier. Not to mention actual=
ly
> > start USING it in the Helper API.
> > 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 packag=
ed
> up
> > and ready to go for you.
> > 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:
> > http://www.uow.edu.au/~kd21/ <http://www.uow.edu.au/%7Ekd21/>)
> >
> > These are the current ideas I have, and that others have submitted.  Su=
re
> > this RFC is a bit bare, but we don't have a whole ton to work with at t=
he
> > moment with Catalyst::Helper, so we need more feedback to beef things u=
p.
>
> Hi,
>
> All that you mention above are great steps ahead - and it'll be
> wonderful if they are implemented.  If I may add something to that
> list - it is a possibility to run the helpers in aggregation - so that
> you could define the configuration once for all the parts and then run
> catalyst.pl to generate the whole application in one step.   Currently
> you run catalyst.pl from the outside - and then you go into the
> generated directory and use one of the generated scripts to generate
> the further components.  In theory it should be possible that all that
> generation is done by catalyst.pl.
>
> Cheers,
> Zbigniew
> http://brudnopis.blogspot.com/
> http://perlalchemy.blogspot.com/
>
> _______________________________________________
> Catalyst-dev mailing list
> Catalyst-dev at lists.scsys.co.uk
> http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
>

Hi Zbigniew,

Thanks for the input!  (Thanks to Francesc as well, I didn't thank you in my
last email).

Perhaps you could flesh out your idea some? Give me an example of how it
would look in usage, I think I'm visualizing it properly, but some concrete
examples would be superb.

Thanks again!

-Devin

-- =

Devin Austin
http://www.codedright.net
http://www.dreamhost.com/r.cgi?326568/hosting.html - Host with DreamHost!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst-dev/attachments/20090605/b=
cecfdde/attachment-0001.htm