Rails - Dec 2009 - Looking for insight into the Rails Way of handling views

I''ve been developing rails apps for a couple of years now and I must
say that I think it is a great way to build web apps.  Rails is
constantly evolving as are the lines of thinking / features /
practices / conventions, etc.  As Rails evolves, it is important to
decide what to adopt.  Some things I adopt right away and others I try
to monitor and see what happens.  Historically, I have found that
views / erb have been the one area leaving me scratching my head on
the approach to development and more importantly the maintenance of an
app.  Especially large applications.  My current method is using a
custom scaffold generator to generate views that utilize a custom code
base that helps deliver the html.  The code in the views adheres to
The Rails Way and works great, but, I have been building apps this way
for a while and have kept a close eye on how things have evolved.

I''m at a point where I need to make a decision on how to design views
for my apps moving forward.  I''m looking for insight as to the current
line of thinking / convention for handling views in rails.

What is the current "Rails Way" to design views?

What direction is Rails moving with regard to views?

--

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

Senior members of the community can correct me if I''m wrong here, but
I think it has always been about code reuse. The view always has and
always will be refined and fussed over. However, the the one thing
that remains consistent is code reuse; which means partials, helpers
and modules.

But, as Obie Fernandez puts in his book, The Rails Way, knowing what
to break out into partials and helpers is a craft you learn over time.
My way of doing things fit the application at-hand and may not be
suitable for your problem. It''s just something that requires lots of
experience. Having a solid background in design patterns and
enterprise development techniques really help to model those choices.
But, in the end, you have to understand that each app is different;
best practices only go so far when you jump from building CMS apps and
blogs to designing air traffic control systems.

Honestly though your post is a bit of a gray area. Maybe if you could
be a little more specific we could tell you what we know. :-)

On Dec 12, 9:02 pm, "rails.impaired"
<resident.mo...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> I''ve been developing rails apps for a couple of years now and I
must
> say that I think it is a great way to build web apps.  Rails is
> constantly evolving as are the lines of thinking / features /
> practices / conventions, etc.  As Rails evolves, it is important to
> decide what to adopt.  Some things I adopt right away and others I try
> to monitor and see what happens.  Historically, I have found that
> views / erb have been the one area leaving me scratching my head on
> the approach to development and more importantly the maintenance of an
> app.  Especially large applications.  My current method is using a
> custom scaffold generator to generate views that utilize a custom code
> base that helps deliver the html.  The code in the views adheres to
> The Rails Way and works great, but, I have been building apps this way
> for a while and have kept a close eye on how things have evolved.
>
> I''m at a point where I need to make a decision on how to design
views
> for my apps moving forward.  I''m looking for insight as to the
current
> line of thinking / convention for handling views in rails.
>
> What is the current "Rails Way" to design views?
>
> What direction is Rails moving with regard to views?
--

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.