FAQ
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 pretty
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:

1. You have to actually delve into Catalyst internals to edit any of
these files
2. If you create a helper, your data must be inline as well.
3. 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:


1. 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.
2. 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.
3. 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. 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.


--
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/attachments/20090603/2b7a3069/attachment.htm

Search Discussions

  • Francesc Romà i Frigolé at Jun 5, 2009 at 11:00 am

    On Thu, Jun 4, 2009 at 4:51 AM, Devin Austin 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 pretty
    formatted version:
    http://www.codedright.net/2009/06/rfc-catalysthelper-api.html

    Hi Devin,

    Thanks for working on this. I think you are on the right path :)

    This are two examples of things I think Catalyst::Helper should do, and it
    looks like it would, if your RFC where implemented:

    1) It should be possible to create an application with catalyst version X
    and then run the catalyst helper again on catalyst version < X (assuming it
    doesn't use any feature of the newer version). Right now if an application
    has been created with Catalyst 5.8, running it with 5.7 is not just a matter
    of changing the line "use Catalyst::Runtime 5.80;"

    2) It should be possible to incrementally change parts of the themes both
    for a specific application, or in general, for all the applications that I'm
    developing.

    For example, a possible approach could be, if I do catalyst.pl MyApp -theme
    cheesy, and I have a local theme configuration, let's say I have the files
    wrapper.tt and css/forms.css in the directory ~/.catalyst/themes/cheesy. In
    this case it should use the default catalyst configuration files for the
    theme "cheesy" except for my local theme files. Also, if MyApp already
    exists, it should respect the local changes made to the theme for that
    application.

    I don't understand the part about generating DBIC schemas. Right now when I
    need to change the schema because the sql has changed during development I
    do this:

    rm seminar.db
    sqlite3 seminar.db < seminar.sql
    ./script/seminar_create.pl model DB DBIC::Schema Seminar::Schema
    create=static components=InflateColumn::FS dbi:SQLite:seminar.db

    What are you proposing to change/improve?

    regards,
    Francesc
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20090605/3df725b0/attachment.htm
  • Devin Austin at Jun 6, 2009 at 3:20 am
    2009/6/5 Francesc Romà i Frigolé
    <francesc.roma+catalyst@gmail.com<francesc.roma%2Bcatalyst@gmail.com>
    >
    On Thu, Jun 4, 2009 at 4:51 AM, Devin Austin 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 pretty
    formatted version:
    http://www.codedright.net/2009/06/rfc-catalysthelper-api.html

    Hi Devin,

    Thanks for working on this. I think you are on the right path :)

    This are two examples of things I think Catalyst::Helper should do, and it
    looks like it would, if your RFC where implemented:

    1) It should be possible to create an application with catalyst version X
    and then run the catalyst helper again on catalyst version < X (assuming it
    doesn't use any feature of the newer version). Right now if an application
    has been created with Catalyst 5.8, running it with 5.7 is not just a matter
    of changing the line "use Catalyst::Runtime 5.80;"

    2) It should be possible to incrementally change parts of the themes both
    for a specific application, or in general, for all the applications that I'm
    developing.

    For example, a possible approach could be, if I do catalyst.pl MyApp -theme
    cheesy, and I have a local theme configuration, let's say I have the files
    wrapper.tt and css/forms.css in the directory ~/.catalyst/themes/cheesy.
    In this case it should use the default catalyst configuration files for the
    theme "cheesy" except for my local theme files. Also, if MyApp already
    exists, it should respect the local changes made to the theme for that
    application.

    I don't understand the part about generating DBIC schemas. Right now when I
    need to change the schema because the sql has changed during development I
    do this:

    rm seminar.db
    sqlite3 seminar.db < seminar.sql
    ./script/seminar_create.pl model DB DBIC::Schema Seminar::Schema
    create=static components=InflateColumn::FS dbi:SQLite:seminar.db

    What are you proposing to change/improve?

    regards,
    Francesc



    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/
    I don't understand the part about generating DBIC schemas. Right now when I
    need to change the schema because the sql has changed during development I
    do this:

    rm seminar.db
    sqlite3 seminar.db < seminar.sql
    ./script/seminar_create.pl model DB DBIC::Schema Seminar::Schema
    create=static components=InflateColumn::FS dbi:SQLite:seminar.db

    What are you proposing to change/improve?

    Basically, and forgive me for speaking the heretic "R" word, but something
    more like the ruby on rails database migrations stuff. Instead of having to
    do all of that ^^^, something a little more sane like perl script/*schema.pl
    update/drop $table/alter $blah, etc. Mainly allowing you to control your db
    and schema from one script. Note that this is obviously not the *exact*
    implementation that will take form, but something along those lines.

    I also like your idea about themes, that's a little more structured than I
    was even thinking :-)

    --
    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/attachments/20090605/8c1827d5/attachment.htm
  • Marcus Ramberg at Jun 7, 2009 at 7:20 am

    2009/6/5 Francesc Rom? i Frigol? <francesc.roma+catalyst@gmail.com>:
    1) It should be possible to create an application with catalyst version X
    and then run the catalyst helper again on catalyst version < X? (assuming it
    doesn't use any feature of the newer version). Right now if an application
    has been created with Catalyst 5.8, running it with 5.7 is not just a matter
    of changing the line "use Catalyst::Runtime 5.80;"
    This would mean that we could never use new features from newer
    Runtime distributions in newer skeletons. That seems like a
    restriction that would be counter-productive to me. If you want to
    develop to target older Runtimes than the current one, I suggest using
    matching -Devel helpers.

    Marcus
  • Devin Austin at Jun 8, 2009 at 1:11 am

    On Sun, Jun 7, 2009 at 1:20 AM, Marcus Ramberg wrote:

    2009/6/5 Francesc Romà i Frigolé <francesc.roma+catalyst@gmail.com<francesc.roma%2Bcatalyst@gmail.com>
    :
    1) It should be possible to create an application with catalyst version X
    and then run the catalyst helper again on catalyst version < X (assuming it
    doesn't use any feature of the newer version). Right now if an
    application
    has been created with Catalyst 5.8, running it with 5.7 is not just a matter
    of changing the line "use Catalyst::Runtime 5.80;"
    This would mean that we could never use new features from newer
    Runtime distributions in newer skeletons. That seems like a
    restriction that would be counter-productive to me. If you want to
    develop to target older Runtimes than the current one, I suggest using
    matching -Devel helpers.

    Marcus

    _______________________________________________
    List: Catalyst@lists.scsys.co.uk
    Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
    Dev site: http://dev.catalyst.perl.org/

    Yea, we'd end up having to do a lot of backcompat checking to see what
    version we need to dish up, if it's not going to be the current one. That,
    imho, would be very counterproductive as Marcus stated and would increase
    the time it takes us to get this finished many fold.
    --
    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/attachments/20090607/99f721d1/attachment.htm

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJun 4, '09 at 2:51a
activeJun 8, '09 at 1:11a
posts5
users3
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2021 Grokbase