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 - [EMAIL PROTECTED]
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
