On 7/2/01 1:00 PM, "John McNally" <[EMAIL PROTECTED]> wrote:
> I do not see why the decision on which content to display based on the
> user, if left in the template, breaks the MVC pattern. I can see how it
> might be preferred to break out page level security into centralized
> control. But page level security is just a special case of the more
> general access control provided by Turbine.
#if (!$mypull.isAuthorizedGlobal("some_perm"))
$data.setRedirectURI($link.setAction("LogoutUser").getURI())
$data.setStatusCode(302)
#end
I think something like above to control page level security is
distinctly different than what you have below. I don't think that
access/restriction of pages is part of the view at all while
what you have listed below is lending to the view for a particular
user even though I'm not fond of that either.
The criterion I would use is that what's above would mean zero
to a designer. But I concede there is a difference between a
designer and a template engineer. The other criterion I would use
is that what's above references parts of the internal system
that may change and are therefore unmaintainable by a designer
because how are they suppose to know what permissions apply
to what pages.
>
> Say the following exists within a set of links providing app navigation
>
> #if ($acl.hasPermission("administrate"))
> <a href="$link.setPage("AdminMenu")">Admin Menu</a>
> #end
I still don't think this is good either because it again references
parts of the internal system. Even if it is only the permission name,
that can still change and the designer/template engineer must consult
someone as to what that permission should be changed to.
Maybe something like:
#foreach ($link in $user.links)
<a href="$link.href">$link.name</a>
#end
So maybe this isn't perfect either but protects against changes
in permission names and the addition of permissions. So you don't
have to have 10 #if statements to create links for each menu item
that pertains to a permission the user has.
> Being able to selectively show content on the page is very convenient,
> how would this be done within MVC?
I totally agree. What I disagree with is references to the internal system
in templates because you limit the freedom of the designer and I don't
think it's maintainable.
The people who work on Scarab's templates are more technically savvy than
the designers I work with. Even the #foreach would throw them for a loop
(ha!) but the page access thing wouldn't mean a thing to them, and they
don't want to learn about it which I think is fair.
Maybe bending MVC is more appropriate, I guess it depends a lot on who
is working on your view and how technically competent they are, or how
technically compentent they want to be. I'm sure we could go on all day :-)
> john mcnally
>
>
>
> Jason van Zyl wrote:
>>
>> 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]
>
> ---------------------------------------------------------------------
> 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]
