<br style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><br><div class="gmail_quote">2009/6/5 Francesc Romā i Frigolé <span dir="ltr"><<a href="mailto:francesc.roma%2Bcatalyst@gmail.com">francesc.roma+catalyst@gmail.com</a>></span><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">
<br><div class="gmail_quote">On Thu, Jun 4, 2009 at 4:51 AM, Devin Austin <span dir="ltr"><<a href="mailto:devin.austin@gmail.com" target="_blank">devin.austin@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>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" target="_blank">http://www.codedright.net/2009/06/rfc-catalysthelper-api.html</a></div>
</blockquote></div><br><br></div>Hi Devin,<br><br>Thanks for working on this. I think you are on the right path :)<br><br>This are two examples of things I think Catalyst::Helper should do, and it looks like it would, if your RFC where implemented:<br>
<br>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;"<br>
<br>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. <br><br>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 <a href="http://wrapper.tt" target="_blank">wrapper.tt</a> 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.<br>
<br>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:<br><br>rm seminar.db<br>sqlite3 seminar.db < seminar.sql<br>
./script/seminar_create.pl model DB DBIC::Schema Seminar::Schema create=static components=InflateColumn::FS dbi:SQLite:seminar.db <br><br>What are you proposing to change/improve?<br><br>regards,<br><font color="#888888">Francesc<br>
<br><br>
</font><br>_______________________________________________<br>
List: <a href="mailto:Catalyst@lists.scsys.co.uk">Catalyst@lists.scsys.co.uk</a><br>
Listinfo: <a href="http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst" target="_blank">http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst</a><br>
Searchable archive: <a href="http://www.mail-archive.com/catalyst@lists.scsys.co.uk/" target="_blank">http://www.mail-archive.com/catalyst@lists.scsys.co.uk/</a><br>
Dev site: <a href="http://dev.catalyst.perl.org/" target="_blank">http://dev.catalyst.perl.org/</a><br>
<br></blockquote></div><br><blockquote>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:<br><br>rm seminar.db<br>sqlite3 seminar.db < seminar.sql<br>
./script/seminar_create.pl model DB DBIC::Schema Seminar::Schema
create=static components=InflateColumn::FS dbi:SQLite:seminar.db <br><br>What are you proposing to change/improve?<br><br></blockquote>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.<br>
<br>I also like your idea about themes, that's a little more structured than I was even thinking :-)<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>