portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Atul Dambalkar <adamb...@cisco.com>
Subject Re: Putting .psml/markup info into database
Date Mon, 09 Jul 2001 19:09:20 GMT
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 - luta.raphael@networks.vivendi.net
>
>---------------------------------------------------------------------
>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


Mime
View raw message