Darren Gilroy wrote:
>
> 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?
>
Do you have a specific reason for avoiding the Profiler ?
> 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.
>
Close, the Profile element would be a kind of PSMLLocator object
Alternatively, we could create such an interface
interface PSMLLocator
{
public String getPage();
public void setPage(String page);
public String getUserName();
public void setUserName(String user);
public String getRole();
public void setRole(String role);
...
}
and then we would have
interface Profile
{
public PSMLDocument getDocument()
public PSMLLocator getLocator()
}
which is somewhat more complex to use but has the advantage to clearly show the
concept behind each interface (PSMLMLocator = search criteria, PSMLDocument = document,
Profile = join )
> 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();
Rather Profiler.createProfile() because the profiler would want to hide
which Profile implementation it uses since its persistence mechanism
dependant.
> 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?
>
PSMLDocument represents the configuration element tree and methods to
manipulate the document content whereas Profile provides meta-information
on the document and methods to manipulate the document itself.
> 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.
>
You know that you can contribute code if you want to see it happen faster... ;)
--
Rapha�l Luta - [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
