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...@gmail.com> 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-t...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
