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 Wed, 11 Jul 2001 18:28:32 GMT
At 09:54 AM 7/11/01 +0200, you wrote:
>Atul Dambalkar wrote:
>>At 10:00 AM 7/10/01 +0200, you wrote:
>>>+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 )
>>>public Iterator list( User user, ProfileLocator locator )
>>>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?
>Make sure that whenever you have a ProfileLocator object, you can also
>get access to the User specific methods like getTemp(), setTemp(), etc...
>Alos, in Turbine a User is not necessarily tied to a login (if he has not
>loggied in) and may simply be tied to an identification cookie. This
>would enable you to write an "anonymous profiling" rule for selecting the
>PSML resource you want to display...

Got it. Perfect.

>>>or directly in PsmlManager interface, in which case it should be called
>>>  IMO:
>>What is IMO?
>In My Opinion.

I had guessed it  :)

>>>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..
>I understand your concern, it's just that I have no strong opinion one
>way or the other as long as the creation of the list is done within
>the Profiler.

Okay...but now I guess, we decided to change the name to getDocument(List 
locator)...instead of fallback, as the result of the fallback algorithm is 
already reflected in the ordered list of locator.


>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

View raw message