Thanks for the help. My 'newbie question' was more related to the fact when I call merb, the request goes through the gem and not my local repo, I was wondering what was the official procedure to avoid that behaviour without breaking my other merb projects. I guess I can just call my generator directly.
About the suggested structure, I was thinking more about creating a generic generator class and having many sub classes so we keep our code consistent and we make things easier for developers wanting to write new generators. I'll try to work on that asap -Matt On 7/30/07, Chris McGrath <[EMAIL PROTECTED]> wrote: > > On 30 Jul 2007, at 07:26, Matt Aimonetti wrote: > > > Sounds good to me. > > I'm willing to try working on the generator. > > > > This is what I had in mind: > > > > $ merb -g app bookshop > > $ merb -g model Book name:string author:string published_at:date > > > > After a collision check, merb would automatically generate: > > - an Active Record Model > > - a migration file > > - a fixture file > > - a rspec example > > - a unit test > > > > I would personally stick to only rspec but I'm fine with adding a unit > > test template and generate a test and an example per model. > > > > I like the idea of having a separate script to generate AR/rspec > models, which merb -g might call by default. We can then have other > scripts for AR/test-spec, ruby-sequel/rspec etc. if people want them > enough to write them. They could also be installed as plugins. > > So you'd be able to do something like: > > merb -g model -t test-spec -o ruby-sequel name:string author:string > > but so we don't have to have merb -g know all this stuff before we > can test / use it, you should be able to do something like: > > merb_ar _rspec -g model ... > > etc. > > > Regarding using ruby-sequel instead of Active Record, I think that's a > > good idea. I would probably have to modify the actual generator and we > > could add an option for the ORM you want to use. When the developer > > decides to generate a model, the generator could check on the ORM used > > and use the proper template. > > > > What do you think? > > > > Having it autodetect which ORM / BDD library would be cool, but not > as important as being able to generate the stuff first. > > > > Also, I have few newbie questions. How's your development/testing > > environment like? I guess you don't package/install the gem every > > time, do you? Do you just work on the files directly in your gems > > folder? I'm sorry, I never worked on a gem and I couldn't find the > > rubygems developer guide. (and I prefer to sound ignorant than to > > waste my time not doing things properly :) ) > > > > > > You want to checkout merb trunk somewhere locally on your machine > using svn. > > Where $ is your terminal prompt > > $ svn co http://svn.devjavu.com/merb/trunk merb > $ cd merb > $ rake specs > > This makes sure everything is working on your machine. > > For the merb_ar script I mentioned above, I'd break it down into > something like the following: > > bin/merb_ar > lib/merb/merb_activerecord_generator/merb_activerecord.rb > lib/merb/merb_activerecord_generator/templates/model.erb > lib/merb/merb_activerecord_generator/templates/rspec.erb > lib/merb/merb_activerecord_generator/templates/test-spec.erb > specs/merb/merb_active_record_generator/merb_activerecord_spec.rb > specs/merb/merb_active_record_generator/fixtures/model.rb > specs/merb/merb_active_record_generator/fixtures/rspec.rb > specs/merb/merb_active_record_generator/fixtures/test-spec.rb > > bin/merb_ar is a simple script which processes command line options > and calls the appropriate methods in the merb_activerecord.rb lib. > The specs would make sure that calling the methods on the lib > generated the correct output by comparing with the expected output in > the fixtures dir. You'd possibly need more than the fixtures I've > listed here of course :) > > I'd start with the specs and a simple model fixture, make the lib > create the fixture, then move on to the creating the rspec file the > same way. You could leave off test-spec for now if you don't know it > and someone else can add that. When the lib is producing what it > should then you can write the bin/merb_ar script to call it. > > svn add all the files you've created as part of this, then run svn > diff > merb_ar_generator_1.diff and upload that to a new ticket on Trac > > > -Matt > > HTH, Cheers, > > Chris > _______________________________________________ > Merb-devel mailing list > [email protected] > http://rubyforge.org/mailman/listinfo/merb-devel >
_______________________________________________ Merb-devel mailing list [email protected] http://rubyforge.org/mailman/listinfo/merb-devel
