Good morning... :-)
Raphael Luta wrote:
>
> - 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()
The primary function of the profiler is to take a request, and given the
request params (device capabilities, mediatype, user, role, language,
location, page, etc.), return a resource or document. This would work like:
Profile profile = Profiler.getProfile(...);
PSMLDocument doc = profile.getDocument();
PortletSet set = PortalToolkit.getSet( doc.getPortlets() );
Im not sure about the third step: psml.getPortlets(). This returns the
castor-generated class representation of the psml from
(org.apache.jetspeed.xml.api.portletmarkup)
why not simply
PortletSet set = doc.getPortletSet();
>
> // sets and retrieve the PSML document
> public PSMLDocument getDocument()
>
> public void setDocument(PSMLDocument doc)
>
> // save the document
> public boolean store()
>
do you think the Profiler should save the PSML document?
(this is probably left over from my original stuff...)
Wouldn't it be better for the PSMLManager service, or the document object to
store itself
> // 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 );
do you mean
public PSMLDocument 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 ?
>
yes, it looks good.
im just wondering about what the PSMLDocument interface
it currently relies on:
import org.apache.jetspeed.xml.api.portletmarkup.Portlets;
import org.apache.jetspeed.xml.api.portletmarkup.Entry;
and then you have to call the PortalToolkit to get your portlets:
PortletSet set = PortalToolkit.getSet( doc.getPortlets() );
wouldn't it be better if the PSMLDocument interface had methods that
directly returned PortletSet?
Of course our implementation could make direct use of the
xml.api.portletmarkup classes
btw --- I just noticed that the portlet api doesn't have any PortletSet
interface.
It really is a Portlet-api, not a Portal-api...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
