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 Tue, 10 Jul 2001 00:00:39 GMT

At 04:21 PM 7/9/01 -0700, you wrote:
>Hi Atul,
>
>Im travelling today, and Im having trouble getting my usual email, so Im on
>a different account today...

No problem..David.

Great that, you could reply back. Thanks.


> >
> > Please, educate me here. What are Castor mapping files? Where are they
> > located and how they are used?
> >
> > >
> > >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.
> >
>
>Done, its in the cvs.

Yeah, I saw that. Cool stuff.

> >
> > >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.
>
>Im in the middle of working on it. I tried to commit the interfaces so that
>you could see them first.
>The code that is specific to the file system still needs to be migrated out
>of the JetspeedProfiler and over into the CastorPsmlManagerServer.
>Or perhaps it should be called the FilePsmlManagerService, since for the
>DatabasePsmlManagerService, you may also choose to impl it with Castor...

Perfect!!

> >
> > >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.
>
>
>Yes, like that.
>Hope to commit the profiler/psmlmanager mods in the next day or so.
>Please take a look at the new interfaces in the PSMLManager, and let me know
>if you think they will work for you.

The interfaces look perfect. But got a doubt about the "FallBack Algo." How 
are you handling it for FilePsmlManagerService? Can we have a generic fall 
back algorithm? New ProfileLocator object has made it a lot simpler..

Here is what I feel:

public class GenericPsmlManagerService implements PsmlManagerService {

         //  Uses Template Method pattern.
         public PSMLDocument fallback(List locators) {
                 // implementation
                 Algo {
                         // Will invoke public PSMLDocument getDocument( 
ProfileLocator locator ) method from sub-class.
                 }
         }
}

public class DatabasePsmlManagerService extends GenericPsmlManagerService {
         // impl.
}

public class FilePsmlManagerService extends GenericPsmlManagerService {
         // impl.
}

It will be great, if you can please, comment on above..

>There is no reason why you can't start writing the

Yes, and we are now working on that right away. We are trying to leverage 
Turbine DB Schema for the Database service. I will keep you posted on our 
development here...

>DatabasePsmlManagerService, although it will be dependent on my changes to
>the JetspeedProfilerService for fully integrated testing.

Sounds great and looking forward to it..

-Atul


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