What's the best way to DRY between edit and show?

Maybe I'm misguided, but I'd like to be able to share formatting and
layout between the editing and viewing of an object - for instance,
re-use a single _form.rhtml whether an item is being viewed or edited.
The alternative strikes me as redundant.

What I'm doing now, but don't like, is adding a "disabled" attribute to
editable fields if the action is "show".

Does anyone have a better strategy, or advice to the effect of: "don't
do that"?

thanks in advance...

Most applications I don't even do show.
Recipe 33 in the rails recipes book shows you how to combine
edit/create/new and update into one action. Unless you need it you can
also dispense with 'show'

Ross

joeb,

Ross Riley's suggestion is good if you hare having issues with your
controller's, but I believe your are talking about your VIEW. I had
this same problem as well. I have a MASSIVE form, some several hundred
lines and I found myself updating my edit form but forgetting to make
coresponding changes in my show. So I came up with a hack.

First, I create a partial and try to follow this convention:

_form.rthml

thanks corporate_hippy for such a thorough response, and it's great to
know that others (well at least one) are dealing with the same issue.

I'm not going to be looking at this in detail until Tuesday, but one
thought occurs to me off the top of my head. I'm no expert, but unless
I'm missing something I'd think it would be possible to toggle the
hiding and displaying with CSS only, without having to resort to
javascript. Much in the way you can use the media attribute to toggle
style sheets for printing and the screen, perhaps your views can select
the approprate style sheet based on action. Make sense?

I think I understand what you're saying, but maybe you can flesh the
idea out a bit more - I'd like to hear what you have in mind.

I posted a very similar question a couple of days ago without any response.

Basically what I’ve been thinking is to use in place editors in my show
action that are active if someone is allowed to edit. That way no
edit view is needed at all, and users only need to identify with one
data layout for each type of information, in terms of editing and
viewing.

I don’t know if it’s a good idea, that was basically my question to everyone or is it a don’t do this kind of thing?

Daniel,

This is an interesting approach, but how does it work when you are
creating a new entry into the system? For me, I'd find it a pain in
the ass to have to click "edit" for every field in a new entry to the
system. You know what I mean? I think it's a good strategy though.

Another part of this question that I think needs attention is, how to
make forms dynamic. For example, if user chooses A, then B appears.
If user chooses C then D appears. I've ended up using Javascript to
show and hide elements based on the selection. I think an observe_form
in conjunction with AJAX is the way to go on this, but I haven't worked
it out yet. Any experience in this area???

Daniel,

This is an interesting approach, but how does it work when you are
creating a new entry into the system? For me, I’d find it a pain in
the ass to have to click “edit” for every field in a new entry to the

system. You know what I mean? I think it’s a good strategy though.

This was the part that I got stuck on as well. I have been
thinking of wrapping the in_place_editor up into a helper, that puts in
some blank text if there is no data yet, and some logic to swap between editing and showing only.

Another part of this question that I think needs attention is, how to
make forms dynamic. For example, if user chooses A, then B appears.

If user chooses C then D appears. I’ve ended up using Javascript to
show and hide elements based on the selection. I think an observe_form
in conjunction with AJAX is the way to go on this, but I haven’t worked

it out yet. Any experience in this area???

I have done some of this before with radio buttons and check boxes etc
very basic tho. I also used javascript to hide / show
elements. From what I’ve read on the list over a while,
some people also use this method for wizard type behaviour.

One other point that I raised in another thread, was regarding
validations. The in_place_editor uses update_attriburte.
This method does not use validations!! I cannot understand why
validations aren’t used with update_attribute but IMHO it renders the
use of in_place_edit_field useless. The update_attribute method
initially does validations but it’s overwritten in the validations
module so that validations aren’t applied.

I don’t understand why this is. I’m hopeing that there is a good reason for it.

I think there really needs a framework for this kind of wizard-based
form building. It's such a critical part of creating
information-intensive apps. The problem that I find with taking
Microsoft's wizard approach is that many times, users want to be able
to edit many parts different "sections" of the data and a wizard can
end up slowing them down. This is why I think the show/hide approach
is much better. The problem is that if you need complex show/hide
rules, Javascript quickly becomes a nightmare. This is a top priority
for me in terms of improving my codebase.

Any ideas how to move this out of Javascript? I think observe_form +
RJS may be the key.

I think you answered your own question with this Carl...using the same
forms that you have for input is probably not what most users expect.
They might be confused when they see they can edit the fields in the
page, but there is no save button. Although, perhaps there is a way
around this as well using Javascript, but like I said above, I think
it's best to get away from that idea.

I’ve also thought a bit about this but I havn’t come up with anything concrete yet.

I’ve used check boxes with observe_field to hide and show and this worked ok.

I’ve also used links that fire javascript to show a fieldset. So
there is like a heading that you can click to show the relevant part of
the form. Like personal information in a user form.
Although required data I don’t really hide.

I guess the way I’m thinking at the moment is that anything that is not
a required field, I put in a fieldset (or many) and show it with
a link that fires javascript. Anything that is conditionally
required I use an observe_field to check when the right conditions are
reached to show it. I’m still not completely sold on this idea
though. All that hiding and showing could get tedious for the
user.

I’ve used RJS up to this point for conditional logic, but I’m beginning
to think that a pure client side js option would be the way to
go. It would be way more responsive, and unless there is really a
need to go to the server, it just seems like a waste. You can
make use of the rails helpers to generate the js for you.

I’d still like to find a way to use in_place editors though…

I hope this may give you some ideas…

My problem with using client side javascript for mangaging show/hide
logic is that I have complex rules to determine what to show/hide. I
feel like RJS would allow me to code this much more elgantly in Ruby
avoiding nasty, ugly Javascript. But you are right, the performance
might become a problem.

I've managed to do it with Javascript this far....maybe I just need to
learn how to write Javascript better so I can turn it into a library
that others can use. Ideally, I'd like to use Helpers to write the
Javascript, similar in the way to how link_to_remote or observe_field
works. Would you like to collaborate on that with me perhaps? It'd my
first attempt at a collabrative effort, but I'd be willing to give it a
try.....

corporate_hippy wrote:

I think I understand what you're saying, but maybe you can flesh the
idea out a bit more - I'd like to hear what you have in mind.

Still a bunch more thinking to do, but here's a simple test I just
tried and it worked.

Taking your form as a starting point:

_form.rthml

That really makes a lot more sense! Good thinking. What I'm going to
try to do next is encapsulate that functionality using helpers. So for
example.....

app/views/user/_form.rhtml

Not sure I get where you're trying to go with this, corporate_hippy.