Andrew Stone said the following on 01/02/08 02:04 PM:
On Feb 1, 2008 11:52 AM, Anton J Aylward <email@example.com
Andrew Stone 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
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.
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.
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
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
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 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.
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.