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 18:11:37 GMT
At 10:00 AM 7/10/01 +0200, you wrote:
>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 ?

I am okay with the first two options..but I am not able to follow the 
third..what it is trying to do?


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

What is IMO?


>public PSMLDocument getDocument(List locators)
>
>and implemented exactly the same way as above... !

I am still concerned about this method being in PsmlManager...even though 
the Profiler is handling creation of ordered list of Locators, the 
"fallback" is job of the profiler..

More later...

-Atul

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


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