portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaƫl Luta <raphael.l...@networks.groupvu.com>
Subject Re: Putting .psml/markup info into database
Date Tue, 10 Jul 2001 08:00:49 GMT
Atul Dambalkar wrote:

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


+1 for list(locator) being in Profiler. It's definitely Profiler's job to do
that, although I would amend the interface to

public Iterator list( RunData data, ProfileLocator locator )
or
public Iterator list( User user, ProfileLocator locator )
or
add a get/setUser() in ProfileLocator to put in the RunData User object.

Why ? Imagine I want to write an alternate adaptive Profiler that stores
persistent information in the User profile... I need to be able to access
a pointer to the User.
... All in all, I think the third option is the best, it replaces the string
user parameter that was there before and gives a lot more power to the
profiling interface and enables a trivial implementation of a DB-backed PSML
implementation (just store PSML as BLOB using setPerm())

What do you think ?

As for the second method, I'm +0 where it's located, it can be either in
Profiler, in which case it would implemented something like:

public PSMLDocument fallback (List loactors)
{
   Iterator i = locators.iterator();
   PSMLDocument doc = null;

   while ((doc == null) && i.hasNext())
   {
     try
     {
       doc = PsmlManager.getDocument((ProfileLocator)i.next());
     }
     catch (Exception e)
     {
       //ignore any exceptions just use next locator
     }
   }

   if (doc==null)
   {
     // algorithm failed
   }

   return doc;
}

or directly in PsmlManager interface, in which case it should be called
  IMO:

public PSMLDocument getDocument(List locators)

and implemented exactly the same way as above... !

--
Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris


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