> I think it's awful. The security of your system should
> have absolutely nothing to do with your templates, even
> in macros. I know that in 2.1 it is cumbersome to have a site
> with complex security requirements so maybe you have to
> resort to what you are doing.
Nah, I was just playing around. I have decided that the use
of Default screen classes provides for cleaner templates.
> In 2.2 there will be a policy service where the security attributes
> for a particular part of your site can be configured (with an xml file,
> or properties, or a database). This way there would simply have to be
> one type of screen for security and you would have to subclass
> security screens and override isAuthorized for each different part
> of your site. I'm also hoping that this role/perm attribute tree
> that is analagous to your site will behave like an inheritance
> hierarchy so that if a particular screen has no permission settings,
> a mechanism can wander up the security attribute tree until it finds
> the first parent node with security settings and use those. So you
> will be able to set base permissions and override where you want
> to change things. I have a simple policy service working now but I
> trying to make a better tree structure (borrowing from xerces) that
> makes it fast at looking up attributes in parent nodes.
That sounds great. I hesitate to draw an analogy to EJB security
as I have no EJB experience.
> Do what you have to do but I think having security code of any kind
> in the templates totally breaks MVC.
I agree (with hindsight ;-] )
>
> jvz.
>
Thanks,
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
