Raphael -
I see your point, and I agree. However, there are some things I am not 100%
clear on.
You say:
> However, this service currently doesn't support this
> kind of signature since it's the role of the Profiler to
> match RequestParameters -> PSML resource object.
> If I understand correctly your need, you want to be able
> to explicitely specify user/mimetype/etc... parameters
> which are used for locating PSML files, is that right ?
You are absolutely correct to say that I am looking for a way to explicitly
specify the user/mimetype/etc parameters when changing PSML content. I would
prefer access to a PSML object to occur independently of the Profiler. Is
this you have proposed?
The Profile is just a wrapper so we know how to load a PSML Document, or in
the current implementation, which psml document. (Is this correct?) So
creating a new profile is not quite the same as, but may have a similar
effect as, creating a new PSML document.
I agree that it is nice to have the persistence method hidden behind the
Profile interface implementation. However, when we do this, we want to make
it clear that when we wish to access a PSMLDocument that has nothing to do
with the current RunData it is obvious that we are doing so. For example:
// Create Object - NO RunData parameter
Profile baseProfile = Profiler.getProfile(username, mimetype, etc);
--or--
Profile baseProfile = new Profile(); or Profiler.createProfile();
baseProfile.setUserName(username);
baseProfile.setMimeType(mimetype);
baseProfile.setEtc(etc);
PSMLDocument doc = baseProfile.getDocument();
// this would call baseProfile.load()
// and PsmlManager.getDocument(baseProfile) if necessary
-- manipulate the document --
baseProfile.setUsername(newuser);
baseProfile.store();
// this would call PsmlManager.saveDocument(baseProfile);
Also, I am a bit uneasy with the relationship between a Profile and a
PSMLDocument. They seem to be much the same, the Profile just being the data
needed to choose a certain PSMLDocument. Perhaps you could help me
understand this?
I hope I am making the least bit of sense. I am very excited about the work
that you are doing on Jetspeed, and am very enthusiastic about the direction
you are taking the PSML infrastructure.
With thanks...
Darren
-----Original Message-----
From: Rapha�l Luta [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 07, 2001 4:20 AM
To: [EMAIL PROTECTED]
Subject: Re: PSMLManager
Darren Gilroy wrote:
>
> Hi -
>
> A bit ago, the signature for the following methods:
> org.apache.jetspeed.util.PSMLManager.getPSMLContent() and
.setPSMLContent()
>
> changed from
> (String username, MimeType mimetype)
> to
> (RunData rundata, MimeType mimetype)
>
> I have a portal application where there is one administrative user that
> selects the portlets for other users, rather than each user selecting
their
> own portlets. So, when this API changed, I had to write my own version of
> PSMLManager because the RunData object I had wasn't for the user whose
psml
> file I needed to get/set.
>
> Any chance you would be willing to bring back the old signature? Maybe
> something like this in PSMLManager:
>
> setPSMLContent( String username, MimeType mimetype ) {
> --- implementation
> }
> setPSMLContent( RunData data, MimeType mimetype ) {
> setPSMLContent( data.getUser().getUserName(), mimetype );
> }
>
In the latest CVS, I introduced a PsmlManager service which is going to
completely
obsolete and replace the static PSML manager class so you can plug whatever
implementation you want.
However, this service currently doesn't support this kind of signature since
it's the role of the Profiler to match RequestParameters -> PSML resource
object.
If I understand correctly your need, you want to be able to explicitely
specify user/mimetype/etc... parameters which are used for locating PSML
files,
is that right ?
So here is what I have in mind and tell me if it works for you (or if you
have a
better idea):
- I propose to change the Profile interface to (basically swapping the
current Profile
with the BaseProfile and hiding getURL() which is implementation specific
in the
base BaseProfile implementation)
public interface Profile
{
// do we really need this ? isn't it better to let the
// client object initialize the PortletSet tree if required
// with the PortalToolkit service ?
public PortletSet getPortletSet()
// sets and retrieve the PSML document
public PSMLDocument getDocument()
public void setDocument(PSMLDocument doc)
// save the document
public boolean store()
// these setters/getters allow you to specify or retrieve
// all the criteria used for selecting a PSML file
// Some of these may be mutually exclusive like username/role/group
public String getUserName()
public void setUserName( String group )
public String getMediaType()
public void setMediaType( String group )
public String getGroup()
public void setGroup( String group )
public String getRole()
public void setRole( String role )
public String getPage()
public void setPage( String page )
}
An instance implementing such an interface could be used by the PsmlManager
service to look for a specific PSML resource thus the PsmlManager service
interface would be :
public interface PsmlManagerService extends Service
{
public Profile getDocument( Profile profile );
public boolean saveDocument( Profile profile );
public boolean saveDocument( Profile profile, PSMLDocument doc );
}
and the Profiler interface could stay about the same with methods
like
public Profile getProfile(RunData data)
public Profile getProfile(RunData data, String role)
etc...
and
// return an empty profile
public Profile createProfile(RunData rundata, String userName)
throws ProfileException;
// return a profile, read the request params from request and
// override username...
public Profile createProfile(RunData rundata, String userName)
throws ProfileException;
The flow for manipulating the configuration files would then be:
// create the object
Profile baseProfile = Profiler.getProfile(rundata);
PSMLDocument doc = baseProfile.getDocument(baseProfile);
// this would call PsmlManager.getDocument(baseProfile) if necessary
-- manipulate the document --
baseProfile.setUsername(<myuser>);
baseProfile.store();
// this would call PsmlManager.saveDocument(baseProfile);
(the previous snippet has actually loaded a Profile, edit its document
and saved it as another user configuration)
The only reason why I've not yet implemented this is that it takes time
and break a few things around but I guess it's a much cleaner process and
it's not tied to a URL/file based implementation...
Comments ?
--
Raphael Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
