Randy Watler wrote:
David,
Right now the simple algorithm is to use the page name to locate the page.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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
