David Sean Taylor wrote:
>
> Good morning... :-)
>
g'd evening :)
> 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() );
>
yes, or possibly
PortletSet set = PortalToolkit.getSet( doc );
> 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();
>
Because PSMLDocument is a representation of the "static" configuration
elements whereas PortletSet is "dynamic" document representation used for
the layout.
PSMLDocument (or Portlets) and PortletSet have roughly a Peer pattern
relation (even though this is not strictly true right now) so it's seems
like a good design decision not to mix teh 2 APIs in the same object
but use a Toolkit to associate both.
The net effect would be that everything in
org.apache.jetspeed.portal is a "dynamic" OM used for rendering (and should
be moved to org.apache.jetspeed.om.portal to be consistent with the OM
convention) whereas the current xml.api.portletmarkup is the statis API used
for manipulating the page content (and this should be moved to
org.apache.jetspeed.om.psml.castor implementing an interface based OM
org.apache.jetspeed.om.psml exactly like I've done for om.registry).
> >
> > // 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...)
Profiler no, but the Profile object yes, it's much more elegant than calling
yet another static class and nicely hides your persistence method in the
Profile interface implementation.
> 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 );
>
yes.
> >
> > 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
>
good points but I think I've addressed thos at the beginning of this mail.
> btw --- I just noticed that the portlet api doesn't have any PortletSet
> interface.
> It really is a Portlet-api, not a Portal-api...
>
Natural, PortletSet is part of the layout infrastructure not the component model,
and thus Jetspeed specific.
--
Rapha�l Luta - [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
