Good questions... strictly out-of the box role-based-psml also wouldn't work for us for the same reason, some users have more than one role. I have some custom logic that only looks at the particular roles which are associated with a "layout type"... in the database these roles aren't differentiated from other roles in any way.
The question of users getting to chose their own role doesn't apply to us; in fact users can't even directly sign themselves up to jetspeed. Their jetspeed account only gets created in response to an external process which knows which role they are supposed to be. -matt --- Stefan Kuhn <[EMAIL PROTECTED]> wrote: > Hi Metthew, > I was thinking about giving psml to users depending > on the role as well, but > I came to the conclusion that this doesn't make > sense because: When people > subscribe (i. e. create a new account) they get one > specified role anyway. Or > do you leave to visitors to choose which role they > want to have ? But then, > when roles mean security restrictions, your securtiy > is gone, because people > can choose their role freely. So I thought it would > be better to have the > assignment of psmls if the administrator gives roles > to users. > One more problem: What to do if the user has got > multiple roles - which psml > take then ? Do you know what the built-in role-based > psml does in such a case > ? > Thanks for your answers and sorry for asking > questions instead of helping you. > Stefan > > Am Mittwoch, 28. August 2002 23:55 schrieben Sie: > > Here are my experiences with the jetspeed psml > > management system. I've had to change a couple > things > > in ways which somebody else might find useful > (please > > let me know if so!) Also, I am discovering that I > may > > have a (hopefully reconcilable) philosophical > problem > > with PSML. > > > > Before I begin, our portal (still in development > > stage) can be seen at > > > > http://nurse.ri.seawave.com:8180/portal/portal > > > > You can log in using "testcrew/password". > > > > > > We don't plan on letting our users customize their > > portal pages at all in terms of the layout, > presence > > or absence of certain portlets. However, we need > to > > give them ways to customize attributes of their > > existing portlets. > > > > We also need to service more than one TYPE of > user, > > each with a different pre-defined set of panes and > > portlets. > > > > Correct me if I'm wrong, but we can't use > role-based > > PSML because that would prevent the use of > individual > > settings.... any change to a portlet attribute > would > > then be seen by ALL other users in the same role. > > > > Also, there is no single user from whom psml files > for > > new users could be copied, because that wouldn't > allow > > for different layouts for different types of > users. > > > > So I changed JetspeedSecurity to point to my own > > UserManagement class, and overrode the > > addDefaultPSML() method to make a copy of the psml > > associated with the user's role rather than the > psml > > of another user (like turbine). > > > > Not a huge deal, but now I am arriving at what > seems > > to be a bigger problem: > > Although the psml file of a user will differ from > > those of his/her peers only in very narrowly > defined > > ways (only in the manipulation of attributes for > > portlets), each user still has a separate copy of > the > > file. > > > > This means that as we add new functionality to our > > portal, adding new portlets and presumably moving > the > > existing ones around somewhat, ONLY new users will > > benefit from these changes. > > > > Everytime we want to add a new portlet, we'll have > to > > write a script that will iterate through > everyone's > > psml and manipulate the xml in a certain way, > adding > > entries for the new portlet.... the exact type of > > thing that was supposed to be short-circuited by > the > > Customizer. Presumably this will have to be done > > when the server is shut down, because otherwise > the > > psml files of any currently-logged-in users will > be > > overwritten back to their old state when a they > log > > out. > > > > Aren't the notions of CONTENT and SETTINGS > separable? > > Shouldn't this information be stored in 2 > separate > > files? Did I miss some way that the current psml > > system can allow for this? If not, how much work > > would have to be done to allow for this? I would > > certainly be willing to adopt such a project > rather > > than resorting to the "mass update script" > strategy > > mentioned above... > > > > - > > Matthew Forsyth > > Seawave.com > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Finance - Get real-time stock quotes > > http://finance.yahoo.com > > -- > Stefan Kuhn M. A. > MPI of Chemical Ecology, Winzerlaer Str. 10, > Beutenberg Campus, 07745 > Jena, Germany > Tel: +49(0)3641 571261 - Fax: +49(0)3641 571202 > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
