At 06:36 PM 7/7/01 +0200, you wrote:
>Atul Dambalkar wrote:
> >
> > At 02:22 PM 7/6/01 -0700, you wrote:
> > >Ive started working on this today.
> > >Hopefully I can refactor this pretty quickly, by the weekend.
> >
> > That would be fabulous..and then we can start here on the implementation
> > for the DatabasePsmlManagerService. Hopefully, I will have to just follow
> > the "config" object (which you are referring below under PsmlManager) to
> > handle the database interactions.
> >
>
>Yes, the intitial idea is also to rewrite the CastorPsmlManager implementation
>to use the Castor mapping files rather than a generated API (just like the
>registry
>does). The same Castor mapping file can be used to describe both the xml
>persistence
>schema and the DBMS or LDAP persistence schema and if the DBMS, LDAP and
>XML impl are
>all based on Castor, it's very easy to provide upgrade paths from XML ->
>DBMS/LDAP.
Please, educate me here. What are Castor mapping files? Where are they
located and how they are used?
> >
> > Yep, that's what we need. This is now really getting interesting. I am
> > looking forward to the new ProfileLocator interface ..
> >
>
>
>Well, the new ProfileLocator interface would be trivial:
>
>interface ProfileLocator
>{
> get/setMediaType()
> get/setLanguage()
> get/setRole()
> get/setUser()
> get/setName()
>}
>
>basically it's just a transport for all the possible PSML search criteria
>
>A complete Profile object would associate a Locator with a document, either
>like this
>
>interface Profile
>{
> PSMLDocument getDocument()
> ProfileLocator getLocator()
>}
>
>or like this
>
>interface Profile extends ProfileLocator
>{
> PSMLDocument getDocument()
>}
>
>I like the second solution best, it's not as clean as the first but easier
>to use...
I also like the second approach.
>The Profiler would still have to code the fallback algorithm but instead
>of actually
>looking for the resource it would just build an ordered list of Locator
>objects which
That's what I meant in my previous emails, not exactly though...about
separating "Fallback Algorithm" in one (may not be super) class and
everyone will just use the same ProfilerService... We don't want to
replicate "Fallback Algorithm"
Here is what I feel: (Feel free to correct me or fill in any missing bit of
information as you guys definitely know the exact flow and the side effects..)
0. Turbine invokes SessionValidator object in Jetspeed.
1. Profiler(Service) gets invoked from the
org.apache.jetspeed.modules.actions.JetspeedSessionValidator
2. Profiler creates the ordered list of ProfileLocator objets (as you said)
3. Turbine invokes the profile from the RunData object, and renders the page...
4. In this case the implementation of the method "PSMLDocument
getDocument()" in class org.apache.jetspeed.om.profile.BaseProfile needs to
be changed or overridden to the one which uses,
PsmlManager.fallback(Locators)..
5. Modify couple of methods in CastorPsmlManagerService viz.
getDocument(String url) to handle Locator objects.
6. Implement DatabasePsmlManagerService or LDAPPsmlManagerService,
transperant to ProfilerService
I just did a CVS update, looked at the updated code, cool stuff, looks
perfect to me and think we are on right track, except the
JetspeedProfilerService, which I think, needs modification.
>should be used for finding documents, from the most preferred to the least
>preferred
If we implement the ProfilerSerivce this way, then there can be only one
ProfilerService. Of-course JetspeedProfilerService needs to be modified to
handle this functionality (basically, File-System/Resource-URL specific
code from JetspeedProfilerService will just go into
CastorPsmlManagerService) and then we can live with only one
ProfilerService...(no separate DatabaseProfilerService or
LDAPProfilerService)...., we don't have to code "Fallback algorithm" in all
different Profiler Services, only Persistence will change...File
system/Database/LDAP. And then we just use any PsmlManagerService as we
want which can be CastorPsmlManagerService or DatabasePsmlManagerService or
LDAPPsmlManagerService.
What do you guys think on this?
-Atul
>and the PsmlManager implementation will check and return the first
>document available.
>
>--
>Rapha�l Luta - [EMAIL PROTECTED]
>
>---------------------------------------------------------------------
>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]
