--- /dev/null
+15:36 <t0m> right. so the first thing to do is probably write a test to check
+ generating an application doesn't change.
+15:37 <dhoss> per app?
+15:38 <t0m> no, I mean whilst you're ripping ::Helper apart.
+15:38 <dhoss> OH
+15:38 <dhoss> gotcha
+15:38 <t0m> if you install your branch.. Then catalyst.pl t/TestAppForComparison
+15:39 <dhoss> so we have the same results now as before, yes?
+15:39 <t0m> then you write a test which says catalyst.pl /tmp/TempTestApp; my
+ $diff = `diff -urN t/TestAppForComparison /tmp/TempTestApp`; ok
+ !length($diff) or warn $diff;
+15:40 <t0m> exactly. and that'll test you rip all of the files out of Helper.pm
+ correctly..
+15:40 <dhoss> okay, TestAppForComparison created. i'll commit that initial
+ version
+15:40 <t0m> you'll probably want to nuke it after that, as testing the
+ generated strings of an entire app dir is gonna be a PITA
+15:41 <t0m> to maintain
+15:41 <dhoss> i could see that
+15:41 <t0m> But it's totally the right solution whilst you're trying to rip
+ stuff out without changing it
+15:41 <dhoss> temp testing :-D
+15:44 <t0m> I've got some ideas on doing better testing that the TestApp we
+ generate is good.
+15:44 <t0m> but they're a bit more involved, and not needed for this at all ;)
+15:45 <dhoss> this being this refactor, or this bit of the refactor?
+15:45 <t0m> the latter.
+15:45 <dhoss> okay - got it
+15:46 <t0m> and once this is done - you can branch again to work on the code,
+ and again to work on the generated app templates (as we'll want to
+ moosify those, so your app is moosetastic by default
+15:46 <t0m> and as it's all in different files - you can do both in parallel as
+ you feel like and safely merge back
+15:47 <t0m> did you get to grips with MX::GetOpt and do you have a plan for
+ that yet?
+15:48 <dhoss> so one branch for helper_refactor, one for code (which code?),
+ and one for app templates
+15:48 <t0m> As I guess catalyst.pl should be taught to use it, and so should
+ the generated scripts :)
+15:48 <dhoss> i've been playing with MX::GetOpt, i need a few more details on
+ what exactly needs to be beat up
+15:48 <t0m> yy, but you branch from completed helper_refactor :)
+15:49 <t0m> and 'code' is the actual refactor / api changes for helpers
+15:49 <t0m> bletch
+15:50 <dhoss> okay, so the 'code' branch will be simply the C::H code branched
+ from helper_refactor
+15:50 <t0m> get_file has to keep working as everything using ::Helper needs it
+15:50 <t0m> yes, exactly.
+15:51 <t0m> so you need to make a get_file_from_sharedir function or something
+15:51 <dhoss> okay, making sense now :-)
+15:51 <t0m> and change things over to use that.
+15:51 <t0m> that's fine though - means you can extract 1 file at a time
+15:52 <dhoss> which would be better, no? better atomicity and for testing
+15:52 <t0m> yy
+15:52 <t0m> bletch was at the fact that 'get_file' is a good method name, and
+ it's now deprecated
+15:53 <dhoss> is that in C::H?
+15:53 <t0m> yy
+15:53 * dhoss is a little behind in my api knowledge
+15:53 <dhoss> off the top of my head at least
+15:53 <t0m> it's the 'get me a file out the <DATA> section' method
+15:53 <dhoss> aha right
+15:54 <t0m> which you're replacing in favour of 'get me a file out of the share
+ dir'
+15:54 <t0m> and 'copy file out of sharedir' methods.
+15:54 <t0m> The former for templates
+15:54 <t0m> the latter for binaries, which gets rid of the hateful decoding and
+ writing out business
+15:54 <dhoss> get -> we're going to interpolate shit, copy -> we're giong to
+ use directly?
+15:55 <t0m> just so
+15:55 <t0m> eliminating the 'please turn this giant hex string back into
+ binary' thing
+15:55 <dhoss> definitely :-P
+16:00 <t0m> sub _mk_favicon {
+16:00 <t0m> my ( $self ) = @_;
+16:00 <t0m> $self->copy_share_file(
+16:00 <t0m> File::Spec->catfile( ( caller(0) )[0], 'favicon.ico' ),
+16:00 <t0m> File::Spec->catfile( $self->{root}, "favicon.ico" )
+16:00 <t0m> );
+16:00 <t0m> }
+16:00 <t0m> sumfin like dat
+16:01 <dhoss> easy enough
+16:01 <t0m> the actually, all the caller crap dies too
+16:02 <dhoss> hrm, i suppose we have to keep the atrocious
+ Class::Accessor::Fast method name artifacts?
+16:02 <t0m> that's to clue get_file what file to borg crap out off
+16:03 <t0m> I vote that most of them can burn, as we'll be working out what
+ shit to copy a lot more dynamically
+16:03 <t0m> and the ones which can't get deprecated, but preserved.
+16:04 <dhoss> so that's just for the current get_file, right?
+16:04 <t0m> yy
+########################################################################
+## done
+16:04 <t0m> $self->copy_share_file(
+16:04 <t0m> 'favicon.ico',
+16:04 <t0m> File::Spec->catfile( $self->{root}, "favicon.ico" )
+16:04 <t0m> );
+#########################################################################
+16:05 <t0m> more like it
+16:05 <t0m> so we have sub mk_foo { shift->generate_foo(@_); }
+
+====
+5-28
+03:04 < dhoss> SO. official next step: 1) #done trim crap out 2) #done write test for how
+ helpers are invoking Catalyst::Helper 3)??? 4) profit!
+03:05 < t0m> 3)#done Re arrange files in sharedir so we can make the comversion guts
+ totally generic
+03:05 < t0m> 4) merge&profit
+03:05 < t0m> *conversion
+03:05 < dhoss> rearrange meaning mv foo MyApp?
+03:06 < t0m> erm, yes, as described above, so that the contents of share/ is
+ laid out the same as a newly generated MyApp
+03:06 < dhoss> OH
+03:06 < dhoss> okay
+03:06 < dhoss> instead of my current fuckery :-)
+03:06 < dhoss> autarch: btw if you have an idea for that i'd love an email to
+ the one in topic
+03:06 < t0m> cause then the entire generate application becomes 'copy this
+ directory from X => Y, applying some file mangling rules)
+
+=============================================================================
+04:26 < t0m> dhoss: erm, yeah - so the two things to do is: unit tests for the
+ methods like get_file which we're not actually using any more..
+04:27 < t0m> (do that by making t/lib/ExampleHelper.pm - copy the TT one from
+ CPAN or something, and then write some tests that get_file can
+ successfully pull chunks out the __DATA__ segment
+04:28 < t0m> and rename everything in the sharedir to be named as-per where it
+ ends up in your app, but suffixed by .tt or .bin
+04:29 < t0m> e.g. share/Makefile.PL.tt share/root/favicon.ico.bin
+ share/lib/MyApp.pm.tt
+04:30 < t0m> the exact reasons for this nameing scheme become aparent post
+ first merge, when we remove most of the code :)
+04:30 < t0m> but all of share/ needs to be in it's final resting place pre-merge
+04:31 < marcus> http://lumberjaph.net/blog/index.php/2009/05/30/catalystxdispatcherasgraph/ # <3 lazyweb
+04:31 < t0m> so tests the stuff we're no longer using in Helper.pm (e.g.
+ get_file) still works. Rename share/ bits
+04:31 < t0m> marcus: Indeed :)
+04:31 < t0m> ^^ those two, then first merge.
+23:36 <@kd> dhoss: just found a bug in ::Devel ...
+23:36 <@kd> we're using #!/usr/bin/env perl now
+23:36 <@kd> that means we have to add the use warnings; pragma beneath it
+23:37 <@kd> that doesn't appear to be happeining in the scripts
+23:37 <@kd> please fix
+23:38 <@kd> dhoss: i.e. http://gist.github.com/122081
+==============================================================================
+
+# DONE
+1. Rename everything into final layout:
+ . tt files all named .tt
+ . none tt files all named .bin
+ . directory structure as generated, e.g. share/lib/MyApp.pm.tt, share/root/favicon.ico.bin
+
+2. get new layout working
+
+
+# DONE
+3. get tests for back compat - i.e. the methods no longer used in Helper.pm like 'get_file'
+ . copy Catalyst::Helper::View::TT into t/lib/TestBackCompat.pm
+ . write test t/deprecated_methods_backcompat.t which says:
+ use FindBin qw/$Bin/;
+ use lib "$Bin/lib";
+ use Test::More tests => 1;
+
+ my $helper = TestBackCompat->new( %maybe_some_params_here );
+ my $a_section = $helper->get_file('FileName');
+ is $a_section, 'FILECONTENTSFROM__DATA__';
+
+3. RFC - DONE
+
+Looking ahead
+
+MooseX::Getopt
+
+################################################################################
+17:46 < t0m> dhoss: erm, oh, so the _other_ thing I didn't think of
+17:46 < t0m> Is Cat works on windows
+17:46 < t0m> I have stuffed loads of "t/foo.t"
+17:46 < t0m> into strings.
+17:46 < t0m> which will break win
+17:47 < t0m> so, all those places where I just "string/append/a/file.name"
+17:47 < t0m> you need to use Path::Class qw/file/; file(qw/ string append a
+ file.name /);
+17:47 < t0m> like ^^^
+17:48 < t0m> then it will still work on win32
+17:48 < dhoss> noted
+17:48 < t0m> There is already File::Spec->catfile
+17:48 < t0m> which does the same thing
+17:48 < t0m> but more ugly
+17:48 < t0m> either/or
+17:48 < purl> either/or is "public load_first_existing_class" or "load_class
+ passes multiple args to load_first_existing_class"
+17:48 < t0m> don't care...
+17:49 < t0m> Just "file/name" is BAD
+17:49 < t0m> and will hate windows users
+
+Summary:
+17:43 < dhoss> 1. fix pod coverage, 2. remove TestAppForInvocation 3. ???
+17:43 < t0m> 3. merge
+
+
+
+