PSMLManager

[Darren Gilroy <DG...@CONSONUS.com>]

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 );
}

Comments?
Thanks!
-best-darr-


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

Re: PSMLManager

[ra...@networks.groupvu.com]

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 - luta.raphael@networks.vivendi.net

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

Re: PSMLManager

[David Sean Taylor <da...@bluesunrise.com>]

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: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org

Re: PSMLManager

[Raphaël Luta <ra...@networks.groupvu.com>]

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 - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org