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
>SELECT * FROM PSML WHERE MEDIATYPE = 'WML'
>

True.

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


Mime
View raw message