On 7/2/01 9:16 AM, "Scott Eade" <[EMAIL PROTECTED]> wrote:
>> 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.
Yup, I definitely think Default screens are a better option
for 2.1.
>
>> 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.
It very well may be like EJB security. I still don't know very much
about EJB but I'm getting there :-) I'm sure the usage pattern I would
like to implement has already been done many times.
>> 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]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
