portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <rwat...@finali.com>
Subject Re: Jetspeed2 Page Profiler/Locator Status
Date Thu, 02 Sep 2004 17:54:41 GMT
David,


>> David/Scott/All,
>>
>> Looking at the Jetspeed2 CVS HEAD, it appears that the 
>> profiler/locator system is not active and instead PSML pages are 
>> pulled directly from the page-manager. There were also one or two 
>> "under construction" comments that have also supported this conclusion.
>>
>> Assuming I have not missed anything obvious, I am wondering where this 
>> support stands? Since we will need group/role profiling at a minimum 
>> before we can roll out a production Jetspeed2 implementation, I would 
>> certainly be willing to help out in the coding, debugging, or any 
>> other capacity if my efforts would be welcome.
>>
>Right now the simple algorithm is to use the page name to locate the page.
>Nothing more.
>I hope to start writing an admin portlet this week to setup profile rules
>

Understood. Our immediate need is to have the system execute on the 
existing "j1", "role-fallback", and "path" role sets.

To that end, I have tinkered with some of the "under construction" code 
in o/a/j/profiler/impl/ProfilerValveImpl and 
o/a/j/profiler/impl/JetspeedProfiler. I am considering hacking 
o/a/j/page/impl/CastorXmlPageManager to support page ids formatted by 
the existing profiler, (i.e. 
'page:/default-page.psml:user:anon:mediatype:html:language:en:country:US'). 
I envision using a J1 like PSML directory structure under the existing 
pages directory for this. However, I am not sure this is what is intended!

Here are some J2 design questions I have related to these thoughts:

- Apparently, the file system arrangement of the PSML resources under 
the pages directory is currently used to determine navigation and 
default pages. Ultimately, this information would need to be 
customized/generated by the profiler in its rule context instead of 
being read from the file system/database, no?

- Given the default values in the "path.session" and "request.session" 
rules, I assume the profiler rules should be determining the default 
page instead of the default name available in 
o/a/j/om/folder/FolderImpl. Is this correct?

- After adding debug code to loop over the profiler fallback iterator, I 
am wondering how the "group.role.user" rule is intended to be iterated 
over. It seems to be only binding to the "user" at the moment:

page:/test-page.psml:user:manager:mediatype:html:language:en:country:US
page:/test-page.psml:user:manger:mediatype:html:language:en
page:/test-page.psml:user:manger:mediatype:html
page:/test-page.psml:user:manager

Would I expect to see something like 
"page:/test-page.psml:role:user:..." and 
"page:/test-page.psml:role:manager:..." out of this locator or are 
multiple locators required? Given that the "path.session" rule is part 
of the "j1" definition,  I would also expect the following to be 
available on the fallback iterator:

page:/test-page.psml
page:/default-page.psml

Would that be a reasonable expectation?

- It seems that by enabling the JetspeedProfiler page access, extending 
the CastorXMLPageManager to map the profiler/locator page urls to the 
directory structure, and improving the generation of the Folder exported 
via a request attribute I can bootstrap a rudimentary profiling system 
for pages. Am I missing something?

Finally, I am wondering if this work would conflict with current 
jetspeed 2 development by commiters... judging by the fact that you are 
splitting the profiler and page-manager components out now, perhaps you 
are already at work here. If not, could this kind of effort help at all 
if contributed?

Randy Watler




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message