portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Atul Dambalkar <Atul.Dambal...@xoriant.com>
Subject RE: Putting .psml/markup info into database
Date Tue, 10 Jul 2001 03:14:34 GMT

Hi David,

While driving back home, I was thinking about the newly added interfaces in
Profile(Service) and PsmlManager(Service). I came up to this. I thought I
should write an email, right away, so as to avoid any cofusion with my last
email (about GenericPsmlManagerService).
Here is what I think:
"FallBack Algo" is actually a functionality of Profiler(Service) and it is
not the job of the PsmlManager to handle that. PsmlManager(Service) should
just manage the PSMLs. So I think PsmlManager(Service) should not have
following two methods:
1. public Iterator list( ProfileLocator locator ) 
2. public PSMLDocument fallback( List locators );
Those methods need to be moved to Profiler(Service.
The "fallback" method in Profiler(Service) then should invoke 
PSMLDocument getDocument(ProfileLocator) method to get the appropriate PSML
document. I couldn't figure out what structural pattern this would fall
under. So basically, the GenericPsmlManagerService which I outlined in my
last email is definitely not needed, and above two methods should go in
Profiler(Service) and its implementation in JetspeedProfilerService.

What are your views on this?

-Atul

-----Original Message-----
From: Atul Dambalkar
To: jetspeed-dev@jakarta.apache.org
Sent: 7/9/01 5:00 PM
Subject: RE: Putting .psml/markup info into database


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

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