P
peter.cutting
I have alot of questions and (daft) opinions which I will place in this
thread and hopefully I will get some answers. Thanks alot. Peter
1) is the "list" really necessary in the following code example taken
from
http://dev.rubyonrails.org/svn/rails/trunk/actionpack/lib/action_controller/scaffolding.rb
# def list
# @entries = Entry.find_all
# render_scaffold "list"
# end
2) It would be nice if the command
ruby script\generate scaffold <model>
also embedded comments in the generated code which described what name
is what how the name variations are related to one another. Superfluous
for the experts, I know. But since the code is so tight already why not
give the newbies some help
3) 2) is especially important since the naming is a bit of nightmare.
eg all sorts of implicit messing around with leading capitals,
camelcase, underscores, pluralisations, and other (eg person->people)
transformations going on. This is all very difficult for mere mortals
(with shitty memories) to grok
4) what is going on with new and create. Do they work togeather. If so
how?
(example taken from same place as above)
# def new
# @entry = Entry.new
# render_scaffold
# end
#
# def create
# @entry = Entry.new(@params["entry"])
# if @entry.save
# flash["notice"] = "Entry was succesfully created"
# redirect_to :action => "list"
# else
# render "entry/new"
# end
# end
5) What is going on in the generated edit view template?
<%= error_messages_for 'project' %>
<%= form 'project', :action => 'update' %>
The error_messages_for bit I dont understand at all.
Editing a record initiates the edit action which which default renders
the edit view which seems to (based on the above) start of a update
action ??? and now I am lost
6) the list template scaffolding iterates thru columns. Wouldnt it be
better to inline the columns since they will almost certainly be
customised later. A lot easier to read and mess about with. (the
iterated alternative could also be included but switched off and the
developer could then quickly switch it on to see all the available
columns).
<% for project in @projects %>
<tr>
<% for column in Project.content_columns %>
<td><%=h project[column.name] %></td>
Thats enough for now.
thread and hopefully I will get some answers. Thanks alot. Peter
1) is the "list" really necessary in the following code example taken
from
http://dev.rubyonrails.org/svn/rails/trunk/actionpack/lib/action_controller/scaffolding.rb
# def list
# @entries = Entry.find_all
# render_scaffold "list"
# end
2) It would be nice if the command
ruby script\generate scaffold <model>
also embedded comments in the generated code which described what name
is what how the name variations are related to one another. Superfluous
for the experts, I know. But since the code is so tight already why not
give the newbies some help
3) 2) is especially important since the naming is a bit of nightmare.
eg all sorts of implicit messing around with leading capitals,
camelcase, underscores, pluralisations, and other (eg person->people)
transformations going on. This is all very difficult for mere mortals
(with shitty memories) to grok
4) what is going on with new and create. Do they work togeather. If so
how?
(example taken from same place as above)
# def new
# @entry = Entry.new
# render_scaffold
# end
#
# def create
# @entry = Entry.new(@params["entry"])
# if @entry.save
# flash["notice"] = "Entry was succesfully created"
# redirect_to :action => "list"
# else
# render "entry/new"
# end
# end
5) What is going on in the generated edit view template?
<%= error_messages_for 'project' %>
<%= form 'project', :action => 'update' %>
The error_messages_for bit I dont understand at all.
Editing a record initiates the edit action which which default renders
the edit view which seems to (based on the above) start of a update
action ??? and now I am lost
6) the list template scaffolding iterates thru columns. Wouldnt it be
better to inline the columns since they will almost certainly be
customised later. A lot easier to read and mess about with. (the
iterated alternative could also be included but switched off and the
developer could then quickly switch it on to see all the available
columns).
<% for project in @projects %>
<tr>
<% for column in Project.content_columns %>
<td><%=h project[column.name] %></td>
Thats enough for now.