portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: Putting .psml/markup info into database
Date Tue, 10 Jul 2001 16:43:42 GMT
Hi Atul,

Again my apologies for the delayed responses, on top of travelling my
network card failed yesterday. Today it seems to be working, at least for a
little while. Anyway, I will be back in the office tonight and back online.

See comments below

David

> -----Original Message-----
> From: Atul Dambalkar [mailto:Atul.Dambalkar@xoriant.com]
> Sent: Monday, July 09, 2001 8:15 PM
> To: 'jetspeed-dev@jakarta.apache.org'
> Subject: RE: Putting .psml/markup info into database
>
>
>
> 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

Yes, it is the algorithm of the Profiler. So what about renaming the
PsmlManager.fallback interface to:

    public PSMLDocument getDocument( List locators );

Yet we will still have:

    public PSMLDocument getDocument( ProfileLocator locator );


here are two real basic impl. of the Profiler's fallback algorithm. I could
imagine it eventually being state driven...

    private PSMLDocument fallback( Profile profile, RunData rundata )
    {
        PSMLDocument doc = PSMLManager.getDocument( profile );
        if (null != doc)
            return doc;

        // remove country
        if (null != profile.getCountry())
        {
            profile.setCountry(null);
            doc = PSMLManager.getDocument( profile );
            if (null != doc)
                return doc;
        }

        // remove language
        if (null != profile.getLanguage())
        {
            profile.setLanguage(null);
            doc = PSMLManager.getDocument( profile );
            if (null != doc)
                return doc;
        }

        // fallback mediaType
        if (null != profile.getMediaType())
        {
            profile.setMediaType(null);
            doc = PSMLManager.getDocument( profile );
            if (null != doc)
                return doc;
        }

        if (null != profile.getGroup())
        {
            profile.setGroup(null);
            doc = PSMLManager.getDocument( profile );
            if (null != doc)
                return doc;
        }
        else if (null != profile.getRole())
        {
            profile.setRole(null);
            doc = PSMLManager.getDocument( profile );
            if (null != doc)
                return doc;
        }
        else if (null != profile.getUser())
        {
            profile.setUser(null);
            doc = PSMLManager.getDocument( profile );
            if (null != doc)
                return doc;
        }

        return doc;

    }


    private PSMLDocument fallback( Profile profile, RunData rundata )
    {
        List locators = new List();
        ProfileLocator locator = profile.clone();

        list.add( locator.clone() );

        // remove country
        if (null != profile.getCountry())
        {
            locator.setCountry(null);
            list.add( locator.clone() );
        }

        // remove language
        if (null != profile.getLanguage())
        {
            locator.setLanguage(null);
            list.add( locator.clone() );
        }

        // fallback mediaType
        if (null != profile.getMediaType())
        {
            locator.setMediaType(null);
            list.add( locator.clone() );
        }

        if (null != profile.getGroup())
        {
            locator.setGroup(null);
            list.add( locator.clone() );
        }
        else if (null != profile.getRole())
        {
            locator.setRole(null);
            list.add( locator.clone() );
        }
        else if (null != profile.getUser())
        {
            locator.setUser(null);
            list.add( locator.clone() );
        }

        return PSMLManager.fallback( list );
    }

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

Yes, I will drop the list interface from the PsmlManager service.
And the fallback was renamed to getDocument( List locator )

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



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