portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Sean Taylor" <da...@bluesunrise.com>
Subject RE: RE: Putting .psml/markup info into database
Date Fri, 06 Jul 2001 21:22:35 GMT
Atul Dambalkar wrote:
> BTW, what is your opinion on, moving the "fallback" algorithm
> specific code
> to some super class and reusing it in the respective sub classes
> (FileSystemProfilerService/DatabaseProfilerService...)? Or
> another approach
> would as I am outlining below that, to create method
> signatures in such a
> way that the current ResourceURL/file paths get entirely
> eliminated and
> then the PSML location (file system/database/ldap)  will be totally
> transparent to PsmlManagerService.

Yes, that is the plan.
I am now looking at either enhancing the Profile object or creating a new
ProfileLocator object for setting criteria for searching
I originally thought the fallback algorithm would be generic, but in
practice Im finding out that it can differ for different impls.
The ResourceURL/file paths should not surface in the interfaces.
We are moving towards that with the Profile and the new ProfileLocator
interfaces

>
>
> > > PsmlManagerService for managing database PSML info
> > > (create/update/remove),
> > > is concerned it has to be implemented from ground zero.
> > >
> > > While using
> > > DatabaseProfilerService/DatabasePsmlManagerService, I think,
> > > there may be few issues related to the Customizer, which
> > > currently assumes
> > > only File based PSMLs. I need to investigate that further.
> >
> >I hope not....I thought I removed that stuff
>
> Nope, its still there in CVS HEAD which I extracted on Jul-3,
> 14.53 PST.
>

The customizer is a candidate for complete rewrite ...
I'd like to see a new customizer written with velocity and pull tools.
This should be possible soon but we still have some work to complete first,
such as interfaces (OM API) for PSML.

>
> > >
> > > Please, let me know, what do you think on above points and
> > > also of any
> > > other clues that may help me in implementing above task.
> >
> >I will add some new methods to the Profiler interface for
> listing profiles
> >(there can be more than one profile per user...)
> >This shouldn't be too much work, but they will necessary in order to
> >customize all profiles.
> >Will also move out the template location methods -- perhaps into a
> >TemplateLocator service.
>
> What is the time line that you are looking for this, to commit?
>

Ive started working on this today.
Hopefully I can refactor this pretty quickly, by the weekend.

>
> >Im wondering if there is a need for two Profiler services.
> Perhaps much of
> >the Profiler functionality, such as searching thru
> directories, should be
> >moved down into the CastorPsmlManagerService (and
> >DatabasePsmlManagerService). The Profiler should not be
> aware of the file
> >system.
>
> That's perfect. In that case, we need to modify
> PsmlManagerService for
> method signatures to handle extracting the PSML information
> independent of
> any location...file system/database/ldap.. something like..
> PSMLDocument getDocument(type (user/role/group), entity
> (username/rolename/groupname), mediatype, language,
> resourcename) which can

Yes, this is from a discussion with Raphael a while back:

                                 Profiler
   request parameters ---------------+---------------> Profile (config
locator)

                       PsmlManager

  Profile ----------------+-------------------------> PSMLDocument (config)

> also adequately handle Database queries..
> and so CastorPsmlManagerService also has to be modified to
> handle these new
> methods. Similarly DatabasePsmlManagerService will implement
> those methods
> to query the database.
>
>
> >Perhaps we should move this discussion to
> jetspeed-dev@jakarta-apache.org
>
> Sure, now it is.
>
> -Atul
>
>
>
>
> ---------------------------------------------------------------------
> 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