Shah,

Comments below....

Shah Amit wrote:


I have been able to implement all that you have pointed me. Thanks a lot for helping me out with this. I think I do get the idea of having document sets. Its a good concept.

Good. There is much to grasp here. There is a design document I failed to mention that might be helpful to some degree on the Profiler. It is located in CVS at: /design-docs/src/profiler/J2-page-manager-profiling.sxw. This is an OpenOffice document... let me know if you need another format.




I have a couple of confusions though.

- In the document sets, there is a <profile-locator>page</profile-locator>. I dont know what that is for.

This is used to specify an alternate profiling locator name/rule to use when determining the document set elements. "page" is the default profiling locator name used to identify the profiling rule for the user that selects pages and navigational elements for a request url.



- Also you wanted to explain me on how to get this more dynamic with the help of profiler. I guess you can shoot that and I will try to grasp the concept.

The profiler is used to define a logical view of the pages, folders, and other documents that exist in the physical file system. Essentially, it filters and/or aggregates various folders and their contents into a contiguous content space accessible via the portal request urls. It does this by applying profiling rules that can map portal content by user, roles, groups, subsites, and other criteria to construct the end user's view of the portal content.


In your case, you can use the profiler to generate a different view for the "guest" user by placing a modified version of customer_area.ds in /_user/guest/customer-area.ds. It could define no document paths at all and make the customer-area.ds content essentially invisible. This works because the profiler aggregates /* and /_user/guest/* portal content, with the more specific content taking precedence.

The profiler can also be used to control what content is visible for logged in users. For example, if your users are assigned the "group-fallback" page profiling rule, different versions of the customer-area content could be placed in separate group-specific folders. Say you had two versions of customer-area content for your two user groups "p1" and "p2". If you left the document sets as defined earlier, you could put various psml pages in: /_group/p1/customer-area/comparison-tools/*.psml and /_group/p2/customer-area/comparison-tools/*.psml. Then, when users that belonged to the "p1" group were authenticated, they would see the aggregation of the global and group-specific comparison-tools content.

Security specifications in the files can be used to further filter pages, folders, and other documents selected by the profiler. Again, take a look at the J2 demo content and you will find many test cases for the profiler and security functionality. Log in and out using the following user/passwords to see various profiling and security effects: user/user, manager/manager, jetspeed/jetspeed, and admin/admin.

Of course, please ask questions!


- (This is not so relevant to this discussion, but) the pages directory that we are talking about --- I still have to put it under <tomcatInstall>/webapps/jetspeed/WEB-INF/pages/... I asked a question before and David said I can have the pages under my own portlet webapp and access it on the internet with -- http://localhost:8080/jetspeed/portlet/myApp/myPage.psml I tried that and it did not work. This however is not that big of an issue, but just a nice thing to have...

I am not sure about this... David will have to clarify. AFAIK, the location of the pages directory is specified in the bean specification of the document handlers in /portal/src/webapp/WEB-INF/assembly/page-manager.xml.


Randy


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to