Re: [Rails-core] Namespaced actions in Rails 1.1?
On Feb 26, 2006, at 6:29 PM, David Heinemeier Hansson wrote: The problem is what a mess that'll make of "rake -T". So before making such a mess, I want to have some good reasons for doing so ;) I thought the Rails 1 series was supposed to maintain compatibility. Apart from being cool, what benefits to these changes bring to the _users_ of Rails? Dave ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
[Rails-core] Confused about the new generator behavior with migrations
Gentle Core Folk: I'm started trying to work with edge Rails, documenting how you'd create a Depot application with them. I'm probably missing something here, but as far as I can see, the new generator that creates the migration whenever your create a scaffold or model is not particularly useful (and in fact is actually counter productive). Let's take the scaffolding case. If I run script/generate scaffold product admin I expect it to generate a _form that lets me edit the fields in an _existing_ product table. However, by default, the generator also creates a db/migration/xxx_add_products.rb migration. This scaffold contains up and down methods with create and drop table method calls. But... for me to be using static scaffolds, I _already have_ a products table. This migration code will actually fail when I type 'rake migrate' , leaving me in an inconsistent state. So... maybe the idea is to create the scaffold prior to creating the table, then add the table definition to the migration, and run rake migrate. But, no, that doesn't work either, as the scaffold generator blows up if the table isn't there. (In fact, it's worse than that, as it also leaves the empty migration file lying around before it exits, so I can't add the table and rerun the generator--I have to run destroy first). So, all things considered, I'd like to suggest that we probably want to lose this feature--I just don't see how it fits into any reasonable workflow. It seems to me the workflow is - create the table with a migration then, either - create the model and controller and start hacking, or - create the scaffold then - add migrations, alter the models and controllers - repeat until IPO Now, I know you can skip scaffold generation in the generators. But surely this should be the default, and the current condition just doesn't seem to be useful in practice. (On a tangential note, if the model and scaffold generators _do_ have to create migrations, they should really be called 'create_tablename', not 'add_tablename', just to be consistent.) Dave (who's just trying to keep up). smime.p7s Description: S/MIME cryptographic signature ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Confused about the new generator behavior with migrations
On Mar 4, 2006, at 18:43, David Heinemeier Hansson wrote: The auto-migration feature is really nice in a non-scaffolding workflow, though. The way I use and work with a Rails application is by creating one model at the time as they're needed to make the application work. So with a shop, I'd start by creating the product model, making it work, and then moving on to the cart or the order, and every step of the way making it all work. This is in contrast to, say, creating the entire schema first, then starting to work on the model or the controller. And that's why the current scaffolding approach is broken. It assumes that I create my database first while the new model of migrations encourage a concurrent approach. That's the way I create them too. I create an empty database, then create my first migration. From there, I may generate a migration, or create a scaffold (static or dynamic). Then maybe create a migration to modify the original table, or create a new table, etc etc.I think that there's nothing intrinsically wrong with scaffolding. It's just that in general, decoupled workflows are more flexible than ones that do too much at a time.Dave smime.p7s Description: S/MIME cryptographic signature ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Confused about the new generator behavior with migrations
On Mar 4, 2006, at 19:00, David Heinemeier Hansson wrote:So let's think about how we can fix scaffolding in a way that it doesn't require the database to exist before running. My first proposal for how to fix this is simply to have script/generate scaffold return to doing <%= form(@product) %> instead of writing out the individual lines. Yes, it is kinda neat to have that, but the pain is not worth it.Except... it's really nice to be able to modify the generated form when you're demoing the application. If you went this approach, why not just use a dynamic 'scaffold :product' line ?Maybe the step is to break the form stuff out from the restI'm not sure what pain you're trying to save, though. This affects page 98 of the book, but that should probably be rewritten using form_for instead anyway. Don't worry about the book: the first half is a total rewrite anyway... :)Dave smime.p7s Description: S/MIME cryptographic signature ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Confused about the new generator behavior with migrations
Additionally, I think a significant amount of people like to design their dbs first, or in chunks instead of 1 model -> 1 migration. This is the case for myself. That's great. We still allow for that. There's all the opportunity in the world to go chasing waterfalls with --skip-migration, but it's certainly not an approach that I want to encourage. The current approach embeds the opinion that developing your application model-by-model is preferable over chunk-by-chunk, but still allows you to do the latter at the cost of configuration. Why not make the generator clever: if there's no existing table, and no existing migration named create_xxx, create the migration. Otherwise, don't create it. smime.p7s Description: S/MIME cryptographic signature ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] Confused about the new generator behavior with migrations
On Mar 4, 2006, at 19:52, David Heinemeier Hansson wrote: I agree that it's kinda nice, though. I just don't think its worth the pain. Where the pain being that 1) you can't run scaffold before setting up database (and it dies mid-air if you do), 2) the flow is backwards for migrations, 3) the form doesn't update if you add additional columns, and 4) the code to make this work is convoluted. I see that, and (FWIW) I agree. Except...From the point of someone who trains newcomers to Rails, the fact that the scaffolding generates a form means that they can see what a form looks like. When they have to add a column, they can cut and paste a 2 lines from the existing form to make the new field work. If there's no form code there, there's nothing to copy.So, there's a kind of breakpoint: during the rock-and-roll phase of development, I recommend folks use dynamic scaffolds, so they can concentrate of checking their model contains the fields it needs. Then, at some point, I suggest they generate a static scaffold. At that point, if they add stuff to the schema, they'll need to edit _form.rhtml. But, at this point, they don't mind this, because they're also interested in changing the look of the forms. To be honest, they normally don't get into the controller code at all.The other changes at this point will be adding validations and behaviors to the models. (This can be problematic, as it breaks the unit tests, but that's a good excuse to explain that tests must be kept up to date.)So, what I'm thinking is that, based on my experience with with training side, there's not must point in static scaffolding with no _form.rhtml. Without that feature, we may as well just use dynamic scaffolding.So, is that significant? I think it is. Earlier, I remember folks saying that experienced Rails developers don't often use scaffolding. So, if scaffolding is a feature aimed at folks just starting out, then perhaps we need to give these folks what they need out of the feature.I don't think there's a clear good answer here. In the absence of something that's obviously a lot better, I'd suggest we hold off making changes until we have that blinding flash of inspiration. Lets drop the migration creation from 'generate scaffold'.Dave smime.p7s Description: S/MIME cryptographic signature ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] [PATCH] Giving acts_as_nested_set some love and moving nodes around in a tree
On Aug 2, 2006, at 9:43 AM, Julian 'Julik' Tarkhanov wrote: Particularly given the few people using it, and the 'fragility' of the code.. I don't think it's really "few". I still can't get it to work for my simple examples in the book, and I'm not documenting it in the second edition because of that. I've tried to find folks to look at the problems I'm seeing, but to no avail, so as far as it seems from the outside (to me at least) this is unworking and unmaintained code. Dave ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
