portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <david.tay...@b3interactive.com>
Subject RE: Putting .psml/markup info into database
Date Mon, 09 Jul 2001 23:21:47 GMT
Hi Atul,

Im travelling today, and Im having trouble getting my usual email, so Im on
a different account today...

> Please, educate me here. What are Castor mapping files? Where are they
> located and how they are used?
> >
> >interface Profile
> >{
> >         PSMLDocument getDocument()
> >         ProfileLocator getLocator()
> >}
> >
> >or like this
> >
> >interface Profile extends ProfileLocator
> >{
> >         PSMLDocument getDocument()
> >}
> >
> >I like the second solution best, it's not as clean as the first
> but easier
> >to use...
> I also like the second approach.

Done, its in the cvs.

> >The Profiler would still have to code the fallback algorithm but instead
> >of actually
> >looking for the resource it would just build an ordered list of Locator
> >objects which
> That's what I meant in my previous emails, not exactly though...about
> separating "Fallback Algorithm" in one (may not be super) class and
> everyone will just use the same ProfilerService... We don't want to
> replicate "Fallback Algorithm"
> 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...
> 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
> 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.

Im in the middle of working on it. I tried to commit the interfaces so that
you could see them first.
The code that is specific to the file system still needs to be migrated out
of the JetspeedProfiler and over into the CastorPsmlManagerServer.
Or perhaps it should be called the FilePsmlManagerService, since for the
DatabasePsmlManagerService, you may also choose to impl it with Castor...

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

Yes, like that.
Hope to commit the profiler/psmlmanager mods in the next day or so.
Please take a look at the new interfaces in the PSMLManager, and let me know
if you think they will work for you.
There is no reason why you can't start writing the
DatabasePsmlManagerService, although it will be dependent on my changes to
the JetspeedProfilerService for fully integrated testing.


To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

View raw message