It cleans up the html generated by the scaffold generator. It doesn't
change anything major about the structure of the generated code, just
mainly ads id's and classes to the tr's using content_tag_for and
humanizes some labels that weren't there before.
I would like to further add a patch after consulting with you guys
first about further possibly controversial changes I'd like to add to
it.
Firstly I would like to remove the following fields from the generated
new and edit forms:
* created_at, updated_at
* any foreign key field following standard ar foreign id naming
My main reason for this is during rails conf I discovered that more
and more people are using the scaffold resource for creating code.
Almost everyone I talked to had these (well at least the date fields)
as pet pieves.
My suggestion on how to do this is to add a method editable? to the
GeneratedAttribute class. This could then be simply tested in the
generators erb files.
The scaffold UI is great for learning how the routes work, and so on.
But I don't think anyone should be encouraged to take the scaffolding
views and morph them into production-quality views. I always end up
deleting most of the generated code because my projects always need
something different.
It cleans up the html generated by the scaffold generator.
I think this is a great idea. Alas, if I understand correctly, it
isn't being accepted by core. Is that true?
If so, I'd love to see this made into a plug-in, so we could work on
it further, and at least make it available to people who want it.
Have you considered that?
It seems like this would be a great compromise; it's relatively easy
to create a generator within a plugin. I imagine that many people
would find scaffolding that highlights some best practices a useful
educational tool.
Exactly!
+1 for plugin with awesome scaffolding code.
Rails professionals will always write their own code, naturally. But let us not forget how most of us learned ERB and form helpers through scaffolding code. Controller scaffold code is really useful to learn REST and respond_to, also.
One thing about the edge scaffold (or the previous resource_scaffold)
is that many rails professionals use it now, just to create the basic
outline of a controller, model etc. Which we probably never would have
with the old scaffold generator.
I agree that if the main purpose from the core team with scaffold
still is educational, then it should remain simple. However I still
think that the code could be improved somewhat in the existing
version.
I never used scaffolds in the pre-1.2.3 days. But now, especially for little internal utilities, they’re quite useful.
And to expand upon Pelle’s point, yes, simple is good… But simple does not have to mean wrong. Theres no reason that things like label tags should not be included… -especially- if its for educational purposes.
Is that true?