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.
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
Being able to selectively show content on the page is very convenient,
how would this be done within MVC?
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]
