portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: Jetspeed2 Page Profiler/Locator Status
Date Thu, 02 Sep 2004 19:39:20 GMT
Randy Watler wrote:

> 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.
The good ole J1 Role Fallback solution.

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

In J2, the Profiiler and PageManager are designed to work in the same 
way as J1: using a locator object to specify the generalized page location.
The big difference is the profiler is no longer hard-coded solution. Its 
engine is all driven by configurable rules.

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

Yes, the locator does this.
Im looking into JCMS as a PageManager component impl, still working out 
details, like getting JCMS into incubation for starters

> - 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?
Well the profiler will give hints to the page service via the locator
Its up to the page service to figure out what gets ultimately served up

> - 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
I too need to review it, its been a while, my guess is that its not complete
I should be working on this all day tomorrow

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

Yes, that is a valid rule.
If you don't find the given page, fall back to a default page

> - 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?
Nope, not that Im aware
I hope to get a UI in place by next week for defining profile rules
See how that goes...

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

I don't see how splitting the components will conflict with your work 
although it might be best for you to base your patches off the split 
components if you are going to take a few days to write it
It would be great to work with you on completing the profiler functionality
I look forward to it!

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

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

View raw message