Ben Wong wrote: > I decided against the dispatcher approach for the reasons ville.virtanen > brought up. The dispatcher will have to know what pages are secured and > which aren't. > > Whatever authentication system you use will be burdened with the same issue. After all it is a critical variable in the equation. If you use bland acegi/spring-security, than you manage it's knowledge via web.xml or whatever backend. If you use tapestry-acegi or similar methods, you must annotate the page classes. If you use dispatchers/filters, then they must consult a service that understands the permissions matrix. If you use onActivate in any form for access control, you are accomplishing the task in probably the worst possible manner. If your app is small then the consequences may be negligible and the simplicity of implementation on only a few pages /may/ pay off. Imo it should be avoided because the maintenance costs grow steadily with the number of pages needing security. I'm also a critic of inheritance, and doubly so when it's used expressly for inheriting behavior. There are semantic consequences in doing this when it comes to your app's architecture - your page /is-a/ page and in most cases your Customer page won't /be-a/ SecuredPage. Yes the page is secured, but you're describing restrictions imposed on the page by business rules, and generally nothing about its semantic meaning as a Customer page. It specifies how a different layer - the access control layer - should treat the page, but nothing of the page itself. I realize some may view this as walking a rather fine line between pragmatism and theoretical banter, but surely we can all can attest to the values of a shallow class hierarchy.
* steps down from soap box * -- http://thegodcode.net --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
