UI component centralized rendering control - best practices ?

[Rod Berkley]

We're using JSF 2.0 in our web layer, and we'd like to have a fine control over the UI components that need to be rendered and required.
Rather than applying "rendered" and "required" attributes on every component, we'd like to delegate such configurations to a centralized component.

There are several dimension to be considered on this configuration, such as the user logged in, the page being displayed, and some business contexts, i.e:
(page x, txtfield y, user A, business context w) -> ( rendererd = true, required = false)
(page x, txtfield y, user B, business context w) -> ( rendererd = true, required = true, error msg = ...)
(page x, txtfield y, user B, business context t) -> ( rendererd = false, required = false)

Is there some proven solution (a framework, maybe) to handle this requirement ?

Are there best practices to consider using JSF 2.0 API to handle this requirement ?

Regards,
Rod

[Tim Holloway]

Welcome to the JavaRanch, Ron!

Actually, centralized control doesn't work too well for me. I do better with components. For example, I'll often have a security component with a security context backing bean that I reference to obtain the logged-in user's name (if any) and to supply the render values for security-related constructs. This architecture is something I can recycle from app to app instead of having to create some sort of monolithic overstructure on a one-off basis per app.

I'm also using facelets augmented by custom facelet components for things like this. However, the main body of the page is typically a backing bean(s) specific to the functionality of that particular page. Which is why it's even more useful to have the invariant parts in their own function-specific components.