# What is the best practice for drying up role-based views?

**URL:** <https://www.ruby-forum.com/t/what-is-the-best-practice-for-drying-up-role-based-views/112432>\
**Category:** Rails\
**Created:** [August 18, 2007, 9:19pm UTC](https://www.ruby-forum.com/t/what-is-the-best-practice-for-drying-up-role-based-views/112432 "2007-08-18T21:19:54Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jose](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/e274bd/32.png) [@jose](https://www.ruby-forum.com/u/jose)\
**Post date:** [August 18, 2007, 9:19pm UTC](https://www.ruby-forum.com/t/what-is-the-best-practice-for-drying-up-role-based-views/112432/1 "2007-08-18T21:19:54Z")

</div>

I’m finding a pattern in many of my Rails application’s which is:  
views that change depending on the role of the person using the  
application. For example, an admin sees one view and an assistant  
sees another view. Many elements may be the same but critical  
elements change.

I’m finding drying up the code to display different view elements  
(links, blocks, etc.) is not easy. I can keep actions from being  
executed at the controller level, but morphing the views to remove  
elements not intended for the user is not simple. I’m finding that  
having separate templates for each role is the safest thing to do,  
but that isn’t dry at all. I can imagine a series of templates which  
refine the accessibility of the elements, but that seems like a lot  
of files and a system is that is not easily maintained.

What is the best practice for drying up role-based views?

I was reading about aspect oriented programming and how it can be  
used to layer functionality upon classes. Does this seem like a  
possible way of layering additional functionality to views? I wonder  
to what degree Rails and Ruby already are already capable of doing  
aspect oriented programming of which I’m not aware.

Jose

…  
Jose Hales-Garcia  
UCLA Department of Statistics  
removed\_email\_address@domain.invalid