The RAILS generators add code to display error messages. For example:
<%= error_messages_for :model %>
may display:
There were problems with the following fields:
* field1 must be 4 characters
* field2 can't be blank
With the intention of keeping things DRY, is it possible to display
all error messages from a central location (e.g. /view/layouts/
application.html.erb)??
With the intention of keeping things DRY, is it possible to display
all error messages from a central location (e.g. /view/layouts/
application.html.erb)??
I don’t think this is really required and sounds like a case of
over-engineering. This isn’t a jab at you, I fall victim to this myself
from time-to-time.
Not all pages will have the need to show errors: list and show are
simple
examples. If you are looking to DRY up your views, take a look at a
generator I released yesterday. This may help you out some:
http://blog.stonean.com/2008/01/generator-stage.html
Even if you don’t use it, it may give you some ideas.
Hope this helps,
andy
–
Andrew S.
Andrew S. said the following on 01/02/08 10:38 AM:
If you are looking to DRY up your views, take a look
at a generator I released yesterday. This may help you out some:http://blog.stonean.com/2008/01/generator-stage.html
Even if you don’t use it, it may give you some ideas.
I’ve been looking to DRY up views and make use of a common partial for
the view-edit-new.
The
<% form_for(@record) do |f| %>
<%= render :partial => “data”, :locals => {:f => f} %>
<%= f.submit submit_label %>
is the key bit, the “_data.html.erb” being of the form
<!--[form:record]-->
<p><label for="record_bracket_only>Brackets only</label>
<%= f.check_box 'brackets_only' %></p>
...
<!--[eoform:record]-->
for umpteen fields of the record.
So I was interested when I saw your view that seemed to operate on
“|f|”, and was then disappointed to find that it didn’t, that every
field needed routine in the helper. I was disappointed because that
actually means there a lot of code, that its not DRY-by-design, that
all you’ve done is shifted the code into the helper.
I’m still trying to find something where I can define a layout once and
once only and use it for both show and edit.
It would be useful in this context if
<% fields_for(@record) do |f| %>
worked outside of a form, but it doesn’t.
–
“You bet on people, not on strategies”
Yes, it’s possible in a number of ways.
The simplest may be to use a ‘named’ yield in your /view/layouts/
application.html.erb. You’d add something like this:
Then, in your views, you’d add use content_for to render the errors
into the div:
<% content_for :error_list do %>
<% error_messages_for :model %>
<% end %>
If you want more control then the key is to understand the magic
behind error_messages_for. All it’s doing (assumption, I haven’t read
the code…) is iterating through the errors hash on the model
object. That hash is keyed by the field name and has a string or
array of strings with the associated error messages. If you really
wanted to you could probably create some kind of @errors structure
(hash?) and then iterate through it if it’s not empty in your target
error section.
HTH,
AndyV
So I was interested when I saw your view that seemed to operate on
“|f|”, and was then disappointed to find that it didn’t, that every
field needed routine in the helper. I was disappointed because that
actually means there a lot of code, that its not DRY-by-design, that
all you’ve done is shifted the code into the helper.
That’s interesting. I haven’t simply shifted code to the helper, at
least
that’s not my view. The duplication done in the show, edit and new is
now
combined into the data partial. This is not DRY how? I am curious.
I’m still trying to find something where I can define a layout once and
once only and use it for both show and edit.It would be useful in this context if
<% fields_for(@record) do |f| %>
worked outside of a form, but it doesn’t.
It seems that you’re looking to boil it down to an list (index) and a
data
view. Is this correct? You could do this with some modifications.
Create
a data partial and in your controller, render the partial instead of the
view for the action.
For example:
def new
render :partial => “data”, :locals => {:title => “Creating MyObject”}
end
…you get the idea. That’s one way to go about it and I have done
this.
It worked well for me.
–
Andrew S.
Andrew S. said the following on 01/02/08 11:23 AM:
That’s interesting. I haven’t simply shifted code to the helper, at
least that’s not my view. The duplication done in the show, edit and
new is now combined into the data partial. This is not DRY how? I am
curious.
For every field in the record you have to have an explicit routine in
the helper. Yes, at a reductionist level you’re not repeating
yourself. But look at the structure of those helper routines - and for
some records you’re going to need a LOT of them - that are all the same
except for the field names.
It seems that you’re looking to boil it down to an list (index) and a
data view. Is this correct?
No, its not.
What I’m trying to do is to use the same ‘form’ definition for both the
edit/new and the view, but with the minimum of code - make Rails do the
work.
…you get the idea. That’s one way to go about it and I have done
this. It worked well for me.
Obviously I’m not explaining this enough.
The ‘new’ has to have a ‘form_for’ in the partial “_data.html.erb”
<% form_for(@record) do |f| %>
and the fields then
f.first-name
and so on. With layout and labels and CSS tags.
Lets put that in a separate file, so that it is written ‘once and once
only’ and can be used by all of [‘new’, ‘edit’, ‘show’]. The ‘index’
doesn’t come into this.
Now, lets use that same file for ‘show’.
Which means there has to be
<% something_something_something_for(@record) do |f| %>
to match up the
f.first-name
and all the rest of the f.whatever_other_fields_there_are in the
partial. You get round this by using an almost identical function for
each field. I see that as a maintenance problem. I don’t see it as
DRY.
What is the "something_something_something_for’ ?
I’ve tried ‘fields_for’. It generates a form, still.Look at the code
for ‘field_for’ and you’ll see why its not suitable for ‘show’.
–
To invent, you need a good imagination and a pile of junk.
Thomas A. Edison
On Feb 1, 2008 11:52 AM, Anton J Aylward [email protected] wrote:
yourself. But look at the structure of those helper routines - and for
some records you’re going to need a LOT of them - that are all the same
except for the field names.
I do see your concern and I actually did think of this in the design.
It
just appears we have different goals in mind, or at minimum, a different
approach (that’s obvious). 
I wanted to create a way to hand off my view to a designer and let them
do
their magic while I do mine. So that’s why I went to the “data” partial
design. One file to control the view.
Now, what I noticed is that I was having to add additional code to test
what
to display for form mode or show mode. This littered the “data” partial
with Ruby code. I didn’t like that. So I then thought of using the
helper
as “presenters” of the data.
To your point of repeated “helper routines”, yes there may be a lot
depending on your form. I thought of doing something to generalize it,
one
method to present data regardless of the field, but the processing to do
so
seemed counter to the benefit. By having a method for each value, it’s
clean and simple and easy for someone using this plugin to understand
what
they need to do to customize it.
I’ve tried ‘fields_for’. It generates a form, still.Look at the code
for ‘field_for’ and you’ll see why its not suitable for ‘show’.
I took a look and agree. It seems your approach is similar to why I
didn’t
go with something like HAML. I don’t want more code dictating my view.
It’s
cool and slick and all that, but I want to use HTML as much as possible.
It
has to be faster than adding another layer of interpretation before HTML
is
rendered.
Good luck in your search. It sounds like you have a good idea what you
want. That is a better start than most people have.
Andrew S.
Andrew has the right idea. new/edit can be combined into a common
data partial that can be rendered by both (and if you don’t mind input
elements in your show you can combine that, too). The extra use of
helpers doesn’t make sense to me, though.
The main place I’d differ is in what’s passed to the partial. As
constructed it is passing the result of a fields_for call (there’s a
‘hidden’ one in the form_for call). I’d recommend just passing the
object in question instead. For example:
_data.html.erb
<% fields_for :person, person do |f| %>
First Name
<%= f.text_field :first_name %>
Middle Name
<%= f.text_field :middle_name %>
Last Name
<%= f.text_field :last_name %>
<% end %>
The following assume that you’re setting @person in the controller…
new.html.erb
<% form_for :person, :url=>people_path do |f| %>
<%= render :partial => ‘data’, :locals=>{:person=>@person} %>
<% end %>
edit.html.erb
<% form_for :person, :url=>person_path(@person), :method=>:put do |f|
%>
<%= render :partial => ‘data’, :locals=>{:person=>@person} %>
Special For Existing People
<% f.check_box :special_person %>
<% end %>
The last field in edit is simply to suggest that you can mix in fields
that are available only in certain contexts. The broader point is
that you’ve written one file that captures all the common input
elements and no longer have to worry about keeping the common set in
sync among the templates that use them.
If you really want to let Ruby/Rails do the work, you can iterate
over the attributes of the ActiveRecord object so that you don’t even
have to create the data partial. This is, in a sense, what the
generators do.
_data.html.erb
<% fields_for :person, person do |f| %>
<% person.attributes.each do |attr, val| %>
<%= attr.to_s.humanize %>
<%= f.text_field attr if val.is_a?(String) %>
<%= f.check_box attr if val.is_a?(Boolean) %>
<% end %>
<% end %>
I would not recommend the latter since you’re losing all control over
the rendering order, etc. but it’s fun to play with…
HTH,
AndyV
AndyV said the following on 01/02/08 04:24 PM:
Andrew has the right idea. new/edit can be combined into a common
data partial that can be rendered by both (and if you don’t mind input
elements in your show you can combine that, too). The extra use of
helpers doesn’t make sense to me, though.
Agreed. And they aren’t DRY.
The main place I’d differ is in what’s passed to the partial.
Agreed. See below.
As
constructed it is passing the result of a fields_for call (there’s a
‘hidden’ one in the form_for call). I’d recommend just passing the
object in question instead.
Agreed.
You’ve just described what I had a result of running the ‘scaffold_form’
generator.
I had the edit/new in one partial
_form.html.erb:
Name
<%= f.text_field ‘name’ %>
and
edit.html.erb
<% form_for(@person) do |f| %>
<%= render :partial => 'form' , :locals=>{:f => f}%>
<%= submit_tag 'Save' %>
<% end %>
new.html.erb
<% form_for(@person) do |f| %>
<%= render :partial => 'form' , :locals=>{:f => f}%>
<%= submit_tag "Add" %>
<% end %>
But ‘scaffold_form’ didn’t generate the details for the view.html.erb
I’ve tried ‘fields_for’:
<% fields_for(@web) do |f| %>
<% render :partial => 'form' , :locals=>{:f => f}%>
<% end %>
Please review the source for ‘field_for’.
It produces a FORM. That is the fields are editable, there just isn’t a
“submit” button.
The following assume that you’re setting @person in the controller…
new.html.erb
<% form_for :person, :url=>people_path do |f| %>
<%= render :partial => ‘data’, :locals=>{:person=>@person} %>
<% end %>
See above.
edit.html.erb
[…][…] The broader point is
that you’ve written one file that captures all the common input
elements and no longer have to worry about keeping the common set in
sync among the templates that use them.
Yes, I’ve understood and sought that from the beginning.
My point is trying to make that “one file that captures” all the fields,
regardless of whether they are being used in and input form or as a
display, in one file.
One file for layout for ALL of [‘new’, ‘edit’, ‘show’ ]
Please Andy, we’re just going over and over the same stuff. I know that
all this works for [‘edit’, ‘new’]; I’m trying to find out how to make
it work for ‘show’ as well.
Andrew S. had a way, but I didn’t like it
–
Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour, and it seems like a minute. THAT’S
relativity.
–Albert Einstein
Andrew S. said the following on 01/02/08 02:04 PM:
> new is now combined into the data partial. This is not DRY how? I amIt just appears we have different goals in mind, or at minimum, a
different approach (that’s obvious).I wanted to create a way to hand off my view to a designer and let them
do their magic while I do mine. So that’s why I went to the “data”
partial design. One file to control the view.
LotR?
Indeed, and that’s what I found interesting.
But it wasn’t quite it. Those helpers were the kicker.
Now, what I noticed is that I was having to add additional code to test
what to display for form mode or show mode. This littered the “data”
partial with Ruby code. I didn’t like that. So I then thought of using
the helper as “presenters” of the data.
I know ahead of time I’m going to have to litter it with
can_do(action, @current_user)
sometime in the future, so I too don’t want it littered here and now.
To your point of repeated “helper routines”, yes there may be a lot
depending on your form.
Oh, there will be! Not least of all because some forms are for more
than one record! What I’m striving for is consistency of the UI/layout
and pushing that back to the CSS. “Skinning”. Yes, I could use
in-place editing with javascript, but I’d rather not for a variety of
reasons that have been discussed here in the past. Having the same
partial for new-edit-show means that I’ll never have to worry about
re-editing the source in the development cycle to keep the
UI/look-and-feel in sync.
The real killer are the ‘super-parent’ records since they contain the
context and configuration information for their descendents. I’ve
thought of doing some sort of HABM but it always boils down to a STI and
trying to fight that is more code, more controllers…
On top of that, as the model changes I would have to update BOTH the
data and the helpers.
(I just know someone is going to ask why I don’t use active_scaffold.
I tried and found it confusing and limiting.
)
I took a look and agree. It seems your approach is similar to why I
didn’t go with something like HAML. I don’t want more code dictating my
view. It’s cool and slick and all that, but I want to use HTML as much
as possible. It has to be faster than adding another layer of
interpretation before HTML is rendered.
I very much agree. There are places for ‘code generation’ and
interpretation, and a lot of the Ruby DSL and widgets get it right, but
obsessing about it costs.
Where I differ from you is that I want the explicit form definition once
and once only. I think it can be done with partials without the helpers
you use. If anything, I want to reserve that all for the ‘next layer’
which will be fine grained access control at the field level 
Good luck in your search. It sounds like you have a good idea what you
want. That is a better start than most people have.
Indeed. many of my peers complain I’m too concerned with ‘requirements’
and ‘getting it right the first time’ :-/ However that ‘good idea what
I want’ can also be frustrating.
–
The eye sees only what the mind is prepared to comprehend.
—-- Henry Bergson, French Philosopher (1859-1941).
Hi Andrew.
Your statement about over-engineering is entirely fair. I think I’ll
take another look at “what am I trying to achieve?” to see if that is
the case.
Thank you for your feedback.
BTW - I look forward to reviewing your source code when I have a free
moment.
I am confused because it seems like you could easily take Andrew
approach and make it dry.
Assuming the proper conventions you could easily turn:
module AuthorsHelper
def first_name_value(f = nil)
if f
f.text_field :first_name
else
h @author.first_name
end
end
def last_name_value(f = nil)
if f
f.text_field :last_name
else
h @author.last_name
end
end
end
into a dynamically generated system in a number of a ways. For instance
iterate through all attributes in a model and dynamically define these
methods. The following is pseudo-code-ish and is not valid
@model_class.attributes.each do |attr_name|
define_method(attr_name) do |f|
if f
f.text_field attr_name.intern
else
h @model_class.send(attr_name)
end
end
as a quick and sloppy example would define all the helpers for the model
object automatically effectively DRY’ing up the code (at the obvious
expense of customizability). There are other, more elegant ways of using
metaprogramming to achieve your goal.
If you can, if you cannot come to an existing solution, consider writing
your own plugin so the world can benefit. You can even take andrew’s as
a starting point and move from there.
Thank you for your post. That is exactly what I was looking for. Now
it’s just a matter of “Is this the right solution for my project?”,
but I digress.
Cheers
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs