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]>

Reply via email to