<br><br><div class="gmail_quote">On Fri, Jun 5, 2009 at 2:28 PM, Zbigniew Lukasiak <span dir="ltr"><<a href="mailto:zzbbyy@gmail.com">zzbbyy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Thu, Jun 4, 2009 at 4:51 AM, Devin Austin<<a href="mailto:devin.austin@gmail.com">devin.austin@gmail.com</a>> wrote:<br>
</div><div><div></div><div class="h5">> 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<br>
> formatted<br>
> version:<a href="http://www.codedright.net/2009/06/rfc-catalysthelper-api.html" target="_blank">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<br>
> 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>
><br>
> Intro:<br>
> This document is to get opinions on a new, up to date set up and<br>
> refactoring of the Catalyst::Helper API.<br>
><br>
> What We Have<br>
> Currently, all template/image data is hideously store inline with code in<br>
> the __DATA__ section of Catalyst::Helper.pm. The API is designed to handle<br>
> data this way, which is wrong wrong wrong for a number of reasons:<br>
><br>
> You have to actually delve into Catalyst internals to edit any of these<br>
> files<br>
> If you create a helper, your data must be inline as well.<br>
> Its current layout does not reflect the directory hierarchy of a Catalyst<br>
> application, thus making it pretty dang hard to expand upon/upgrade.<br>
><br>
> There are no methods to allow you to edit previously created files, unless<br>
> you want to create your own helper and feverishly create your own file<br>
> modification method(s).<br>
> I can attest to the stress this causes, as I've been doing a good deal of<br>
> yak shaving cleaning this code up and creating the proper tests for it.<br>
> It's not a very fun ordeal at this point.<br>
><br>
> What we want<br>
> From the feedback I've gathered thus far:<br>
><br>
> We do want previously created helper files to be modifiable via<br>
> Catalyst::Helpers. For instance, updating Makefile.PL, updating myapp.conf<br>
> to reflect changes, updating DBIC schema files to reflect database changes<br>
> (with minimal pain). Also, add an infrastructure for modifying existing<br>
> catalyst code, e.g. moving Catalyst::Helper::AuthDBIC from an experimental<br>
> proof of concept to something that people might actually want to use for<br>
> their own stuff.<br>
><br>
> We do want to be able to remove a good deal of the boilerplate code that<br>
> still seems to need to be created manually, for each app, even though it's<br>
> the exact same code for each instance.<br>
><br>
> We do want to set up the helper files in the hierarchy that a Catalyst<br>
> application is created in, thus cutting quickly to the chase in the way of<br>
> creating an app. It's a simple name and Template::Toolkit variable<br>
> translation, then writing the file to the filesystem process then. This<br>
> gets our binary data out of the API code, the template data out of the API<br>
> code, and generally makes every one more happy.<br>
><br>
> With this said, here are some more specific ideas that have been passed my<br>
> way that I think would really help further advance our precious Helper API:<br>
><br>
> Beat up MooseX::Getopt to deal with pass-through options, so you can deal<br>
> with passing data structures as arguments easier. Not to mention actually<br>
> start USING it in the Helper API.<br>
> Add a feature to write out DBIC schema files for deployment. Yes,<br>
> make_schema_at does this, but you have to write your own little script to<br>
> enjoy this morsel of functionality. It would be nice to have it packaged up<br>
> and ready to go for you.<br>
> Have something like TTSite, but less sucky. Perhaps there could be a<br>
> default layout that can be created, or you can create your own sort of skin<br>
> and have that the default generation. Or, better yet, packaged skins that<br>
> users can submit to $somewhere and have the author choose a "theme" for<br>
> their app. For instance, using $javascript framework and $css framework to<br>
> do so, like in chapt 11 of the upcoming book (Example usage:<br>
> <a href="http://www.uow.edu.au/%7Ekd21/" target="_blank">http://www.uow.edu.au/~kd21/</a>)<br>
><br>
> These are the current ideas I have, and that others have submitted. Sure<br>
> this RFC is a bit bare, but we don't have a whole ton to work with at the<br>
> moment with Catalyst::Helper, so we need more feedback to beef things up.<br>
<br>
</div></div>Hi,<br>
<br>
All that you mention above are great steps ahead - and it'll be<br>
wonderful if they are implemented. If I may add something to that<br>
list - it is a possibility to run the helpers in aggregation - so that<br>
you could define the configuration once for all the parts and then run<br>
catalyst.pl to generate the whole application in one step. Currently<br>
you run catalyst.pl from the outside - and then you go into the<br>
generated directory and use one of the generated scripts to generate<br>
the further components. In theory it should be possible that all that<br>
generation is done by catalyst.pl.<br>
<br>
Cheers,<br>
Zbigniew<br>
<a href="http://brudnopis.blogspot.com/" target="_blank">http://brudnopis.blogspot.com/</a><br>
<a href="http://perlalchemy.blogspot.com/" target="_blank">http://perlalchemy.blogspot.com/</a><br>
<br>
_______________________________________________<br>
Catalyst-dev mailing list<br>
<a href="mailto:Catalyst-dev@lists.scsys.co.uk">Catalyst-dev@lists.scsys.co.uk</a><br>
<a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev</a><br>
</blockquote></div><br>Hi Zbigniew,<br><br>Thanks for the input! (Thanks to <font style="color: rgb(0, 0, 0);" color="#888888">Francesc a</font>s well, I didn't thank you in my last email).<br><br>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.<br>
<br>Thanks again!<br><br>-Devin<br clear="all"><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>