portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Atul Dambalkar <adamb...@cisco.com>
Subject Fwd: RE: Putting .psml/markup info into database
Date Fri, 06 Jul 2001 17:18:29 GMT
Forwarded from jetspeed-user list...

More below...

>Atul Dambalkar wrote:
> > Now, I have CVS HEAD and I am working with it. Reporting bugs
> > as and when I
> > am finding any...
> >
>Yes, Thanks!
> > Got a doubt, related to Profiler and PsmlManager Service. Both these
> > services are basically hooked into Turbine as they extend
> > TurbineBaseService. I looked at the code, both these services never
> > interact with each other directly. Depending upon the logged in user,
> > particular Profile (for the user) is getting created (from
> > JetspeedProfilerService) and appropriate PSMLDocument is loaded (from
> > CastorPsmlManagerService). So my question is how this
> > interaction occurs?
> >
> > Just to explain my question in detail, assume user "turbine"
> > logs in. Now,
> > for "turbine" the default.psml file is located under directory
> > "/WEB-INF/psml/user/turbine". Now, I can figure out that,
> > JetspeedProfilerService is responsible to create this file
> > path. But who
> > invokes the JetspeedProfilerService to get this file path and
> > then later
> > use PsmlManagerService to load the actual document?
>Look at org.apache.jetspeed.util.template.JetspeedTool.java
>This is a good example of invoking the profiler and psml-manager.

Sure. Thanks.

> >
> > Also I would like some detailed information on the "fallback"
> > algorithm
> > that is used while creating user profile/psml-file path. I
> > tried to look at
> > the Javadoc for the "fallback" method in
> > org.apache.jetspeed.services.profiler.JetspeedProfilerService,
> >  which helps
> > a bit but still I would like to have some more informaition on that.
> >
>see /jakarta-jetspeed/proposals/0005.txt

Oh..right..I need to go thro' that.

> > Also there are following methods in interface
> > org.apache.jetspeed.services.profiler.Profiler, which I'm
> > unable to figure
> > out what they do:
> > =====================
> >      public String locateTemplate(RunData data, String
> > resourceType, String
> > path, String template);
> >      public String locateScreenTemplate(RunData data, String
> > template);
> >      public String locateLayoutTemplate(RunData data, String
> > template);
> >      public String locatePortletTemplate(RunData data, String
> > template);
> >      public String locateControlTemplate(RunData data, String
> > template);
> >      public String locateControllerTemplate(RunData data,
> > String template);
> > ======================
> >
>These methods need to be moved out of the Profiler interface.
>I put them there to reuse some code, and wasn't quite sure where to put them
>since I'd prefer they we're implemented in Turbine anyway.
>You should not have to implement them for your service.

Okay, great.

> > Also I would like to have some guidance on how should we put .psml
> > information into database, so that once we agree on that, future
> > integration will be lot easier.
> >
> > So, as far as putting, the .psml information into database is
> > concerned, I
> > think, the DatabaseProfilerService has to handle the exact
> > same issues that
> > are handled by JetspeedProfilerService for creating the
> > resourceURL (that
> > is file path). Now, when we put the psml information in to
> > the database,
> > similar to file system where fully qualified path is the
> > identifying key
> > for the file, we also would need same type of primary key to
> > get the stored
> > psml info. In simplistic terms, I can actually use, the same
> > file name
> > (resourceURL) just replace by some character (may be ".") to create a
> > primary key and dump the psml contents as bytes or string. If
> > we follow
>So you are suggesting storing the entire profile information in one big blob
>(or string)?

That would be most simplistic approach, but I totally agree with what you 
are saying.

>That will probably be best for speed. Im just wondering if we should be
>leveraging the sql engine more.

We should leverage SQL engine more.

>Like if you needed to search psml content.
>Yes, the primary key must be unique, but it would be nice if it were
>possibly segmented i.e.
>type (user/role/group) + entity (username/rolename/groupname) + mediatype +
>language + resourcename
>This will be much more useful for searching on secondary indices, such as


> > this criteria for the primary key,  then we can put all the fallback
> > algorithm and all the profiling related methods in a super class and
> > subclass it to get the file resource URLs (in case of
> > org.apache.jetspeed.services.profiler.JetspeedProfilerService)
> >  or database
> > primary keys (in case of DatabaseProfilerService). That way
> > we would be
> > still using "Factory" pattern and effectively using "Template Method"
> > pattern to reuse the critical algorithm related code (which
> > we definitely
> > don't want to replicate). This way if someone wants to store
> > this psml info
> > into LDAP then they can also do it much easily. As far as
>that would be nice (LDAP)! ....are you volunteering for that one too ;-)

Well, why not...if there is someone to use it :)

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.

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

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

>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

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


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

View raw message