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:50:42 GMT
Atul Dambalkar wrote:

> At 06:36 PM 7/7/01 +0200, you wrote:
> 
>> Atul Dambalkar wrote:
>> >
>> > At 02:22 PM 7/6/01 -0700, you wrote:
>> > >Ive started working on this today.
>> > >Hopefully I can refactor this pretty quickly, by the weekend.
>> >
>> > That would be fabulous..and then we can start here on the 
>> implementation
>> > for the DatabasePsmlManagerService. Hopefully, I will have to just 
>> follow
>> > the "config" object (which you are referring below under 
>> PsmlManager) to
>> > handle the database interactions.
>> >
>>
>> Yes, the intitial idea is also to rewrite the CastorPsmlManager 
>> implementation
>> to use the Castor mapping files rather than a generated API (just like 
>> the registry
>> does). The same Castor mapping file can be used to describe both the 
>> xml persistence
>> schema and the DBMS or LDAP persistence schema and if the DBMS, LDAP 
>> and XML impl are
>> all based on Castor, it's very easy to provide upgrade paths from XML 
>> -> DBMS/LDAP.
> 
> 
> Please, educate me here. What are Castor mapping files? Where are they 
> located and how they are used?
> 


Check these:

http://castor.exolab.org/xml-mapping.html

http://castor.exolab.org/jdo.html


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


Not exactly, Turbine invokes the screenTemplate selected by the request. If no
screen is selected, the default template is used. This template uses the
JetspeedTool to load and render a pane resource defined in a PSMLDOcument which
is referenced by the Profile object.


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


Yes, that's the way it should work.


> 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.
> 
>> 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.
> 
> What do you guys think on this?
> 


I globally agree except than I *do* think that some users may need alternate

Profiler implementation if they want to implement advanced adaptative profiling

systems.

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