Hi people, just thought I''d mumble out my thoughts on merb''s apps directory structure and config concepts and see what other people are feeling... the app dir: mvc/application is layed out as expected....maybe without the mailer by default (another discussion) the config dir: I really think that it''s confusing to have such a mixture of ways to configure some of the settings merb.yml, 3xenvironment .rb files, a dependancies.rb an init file and potenially an upload.conf. wouldn''t it be nicer to just have a very well commented init.rb to contain ALL the app setup and options? the well commented options in merb.yml works well as a quick stop for what can be tweaked, but that same concept would work equally well in an .rb file and make merb''s startup sequence obvious and clear without any special knowledge. the deps & lib dirs: Almost every ruby library, gem, or application has a lib dir to contain the required files. This is a kind of standard by consistantcy. Why does the "deps" dir exist?. A /plugins dir would feel equally at home in lib/plugins and it would solve the minor dilemor of "does my little extension count as a "dependancy" or as a "lib" the log dir: can''t argue there. the public dir: that''s a given. the schema dir: I think this should be created by whichever ORM plugin/lib you have chosen to use. Not all merb apps will even need a database. the spec dir: perfect, one single obvious place to get your mocks/specs in order the scripts dir: this should be removed. Raketasks are to "scripts" as merb is to actionpack ;) ....and "rake -T" is your friend. Regards chrisfarms. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070922/fe58afde/attachment-0001.html
On Sep 22, 2007, at 6:53 AM, Chris Farmiloe wrote:> the deps & lib dirs: > Almost every ruby library, gem, or application has a lib > dir to contain the required files. This is a kind of standard > by consistantcy. Why does the "deps" dir exist?. A /plugins > dir would feel equally at home in lib/plugins and it would > solve the minor dilemor of "does my little extension count > as a "dependancy" or as a "lib""deps" is now (r671) "gems", and it exists because it is a Gem Home you can actually install gems into if you want to keep them close to the app. It functions exactly like the system gems path, but doesn''t require root. So, the minor dilemma is solved: If it is packaged as a gem, install it to gems/, otherwise put it in lib/
On Sep 22, 2007, at 6:53 AM, Chris Farmiloe wrote:> the schema dir: > I think this should be created by whichever ORM plugin/lib > you have chosen to use. Not all merb apps will even need > a database.+1 ... I assume this is just a leftover. Anyone see a reason to keep schema in generated apps?
On 22 Sep 2007, at 14:45, Wayne E. Seguin wrote:
>> config/environments/{production,staging,testing,development,...}.rb
Reading over my post it did seem I implied that I wanted to scrap the
environments.
Sorry, that''s not what I meant ... the environment structure is very
useful.
I was more talking about combining all the others.
basically leaving us with.
router.rb
init.rb
environments/development.rb
environments/production.rb
environments/stage.rb
environments/test.rb
if some options [ala Merb.add_mime_type] are to be set via ruby code,
then lets set them ALL via ruby code and make init a nice linear file
that is clearly the app''s boot script.
I thought it very odd to follow the execution path around these files
(especially when a line in merb.yml specifies the location of another
yaml file for the upload.conf!)
Regards
Farms.
Design & Dev
Oxygen.
http://www.oxdi.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/merb-devel/attachments/20070922/0ae05d13/attachment.html
> > "deps" is now (r671) "gems", and it exists because it is a Gem Home > you can actually install gems into if you want to keep them close to > the app. It functions exactly like the system gems path, but doesn''t > require root. > > So, the minor dilemma is solved: If it is packaged as a gem, install > it to gems/, otherwise put it in lib/ >cool that makes more sense
Where would migrations go if schema is not there? Speaking of migrations, what should happen to script/new_migration? Right now it only generates ActiveRecord migrations, and I''m trying to use Sequel instead. On 9/22/07, Michael D. Ivey <ivey at gweezlebur.com> wrote:> On Sep 22, 2007, at 6:53 AM, Chris Farmiloe wrote: > > the schema dir: > > I think this should be created by whichever ORM plugin/lib > > you have chosen to use. Not all merb apps will even need > > a database. > > +1 ... I assume this is just a leftover. > > Anyone see a reason to keep schema in generated apps? > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel >-- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/
On Sep 22, 2007, at 2:21 PM, Kevin Williams wrote:> Where would migrations go if schema is not there?Wherever your ORM plugin puts it. Probably schema, but the ORM plugin should create it.> Speaking of migrations, what should happen to script/new_migration? > Right now it only generates ActiveRecord migrations, and I''m trying to > use Sequel instead.It should be a rake task or generator provided by the ORM plugin.
Sounds good. On 9/22/07, Michael D. Ivey <ivey at gweezlebur.com> wrote:> On Sep 22, 2007, at 2:21 PM, Kevin Williams wrote: > > Where would migrations go if schema is not there? > > Wherever your ORM plugin puts it. Probably schema, but the ORM > plugin should create it. > > > Speaking of migrations, what should happen to script/new_migration? > > Right now it only generates ActiveRecord migrations, and I''m trying to > > use Sequel instead. > > It should be a rake task or generator provided by the ORM plugin. > > > _______________________________________________ > Merb-devel mailing list > Merb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/merb-devel >-- Cheers, Kevin Williams http://kevwil.com/ http://www.almostserio.us/ http://kevwil.jaiku.com/
On Sep 22, 2007, at 9:27 AM, Chris Farmiloe wrote:> > > > On 22 Sep 2007, at 14:45, Wayne E. Seguin wrote: > >> config/environments/{production,staging,testing,development,...}.rb > > Reading over my post it did seem I implied that I wanted to scrap > the environments. > Sorry, that''s not what I meant ... the environment structure is > very useful. > > I was more talking about combining all the others. > > basically leaving us with. > > router.rb > init.rb > environments/development.rb > environments/production.rb > environments/stage.rb > environments/test.rb > > > > if some options [ala Merb.add_mime_type] are to be set via ruby > code, then lets set them ALL via ruby code and make init a nice > linear file that is clearly the app''s boot script. > > I thought it very odd to follow the execution path around these > files (especially when a line in merb.yml specifies the location of > another yaml file for the upload.conf!) >I agree about the difficulty of following the execution path-- ideally, we should make this as straight-forward as possible by defaulting to a single init.rb or merb_init.rb file. For example, why not use a case/when statement instead of the environments/*.rb situation? Just a thought. The only exception I can think of is keeping the dependencies.rb file around--as has been discussed before, we need some way to keep this separate so that "rake" has a way of knowing what to load (without loading the whole application) and can thus add all rake tasks from the dependencies. Duane Johnson (canadaduane) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070923/913ac07c/attachment.html
> we need some way to keep this separate so that "rake" has a way of > knowing what to load (without loading the whole application)there are other ways to solve this issue.. for instance the merb_init.rb file could have some form of namespacing: # dependacies are loaded first, you should # place everything your application needs to # run in this block # configure :dependancies do |config| Gem.path.unshift(MERB_ROOT / "deps") config.after_app_loads do # something end end # server options are set in this block # configure :server do |server| server.host = ''127.0.0.1'' server.port = 4000 end # configure your session store here # configure :session do |session| session.store = ''cookie'' end # add additional mime types # configure :mime_types do |mime| mime.type ''text'', ''text/html'' end looks pretty but might just be adding to much complexity. Regards Farms. Design & Dev Oxygen. http://www.oxdi.eu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/merb-devel/attachments/20070924/7a021e62/attachment-0001.html