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.
>
> 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
> 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.
> 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 will probably be best for speed. Im just wondering if we should be
leveraging the 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'
> 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 ;-)
> 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
>
> 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.
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.
Perhaps we should move this discussion to [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
