portals-jetspeed-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: portlet entity Editor
Date Thu, 01 Nov 2007 03:43:12 GMT

On Oct 31, 2007, at 6:13 PM, Mansour wrote:

> David Sean Taylor wrote:
>> On Oct 30, 2007, at 7:39 AM, Mansour wrote:
>>> David Sean Taylor wrote:
>>>> On Oct 27, 2007, at 3:27 PM, Mansour wrote:
>>>>> From my understanding I can ( through the Entity Editor in JS2)  
>>>>> create new entities that are not added to the page. Also, I can  
>>>>> view the parameter for an exiting entity and modify them. When  
>>>>> I remove an entity form all the pages, it's not deleted from  
>>>>> the entity browser. There is no way to delete entities from the  
>>>>> entity browser. And I can not set permissions on an entity. In  
>>>>> fact if I create and entiy through the Entity browser, there's  
>>>>> no way to add it to the pages.
>>>> The entity editor was an early experiment in the Jetspeed XML  
>>>> API, I think we never really completed it
>>>>> Now, how can I get around this:
>>>>> 1- create and add an instance (or entity) to the pages?
>>>> With the portlet customizer. Select the "Add Portlet" button and  
>>>> add a instance to a page
>>>>> 2- set security permissions on this entity ?
>>>> That has to be done by editing XML currently. Woonsan is working  
>>>> on an configure mode 2.1.3 which will handle this requirement
>>>> You may want to double check with him though
>>>>> 3- delete an entity.
>>>> Go into edit mode, press the X for the portlet you want to delete
>>> I do not mean delete an entity from the page only. I mean remove  
>>> it totally. Even if you remove if from the page as an admin. I t  
>>> will be removed fro all users. The entity will be there but not  
>>> showing on any page. Again, this is can be seen through the  
>>> entity editor.
>> I just think that the entity editor can get way out of hand for  
>> large systems, and where it may be a good debug tool, I usually  
>> just go to MySQL to query this kind of info
>> Its still not clear to me why you need to manipulate entities at  
>> this low level. If you could better explain your use case, then I  
>> can better help you
> I will give you an example of the use case for this. I have a  
> reporting portlet. This portlet (entity or portlet instance) is to  
> pull and display data from a customizable connection string. Users  
> for group A connect to DB A. Users in group B can pull data only  
> form DB B. Users in A and B have the choice to display or to hide  
> this reporting portlet but they cannot edit or customize the  
> connection string. There's a system Admin for group A called adminA  
> and for B called adminB. The system administrators can set this  
> connection string and will revoke the permission to edit this  
> portlet from the groups. The system admins do not and should not  
> know anything about how to set permissions through "PSML" (it's JS2  
> specific and not a standard like jsp). IF a portlet is not used by  
> any one then entity (instance) can be deleted from the DB by the  
> admin.

No need to get on your high horse about standards with me. I know  
PSML is not a standard, and I know JSP is a "Java standard".
That line of thinking is in line with my thinking here: why are you  
messing around with portlet entities and the Jetspeed implementation.
You should be implementing this code as a part of your business  
logic, your portlet application, not with Jetspeed-specific impl  
details (Entity Manager) in the portal.
  I still see no reason for you to be meddling with the portal  
implementation layer, when you should be sticking to standards, and  
using the Portlet API to handle this, in your application code
I believe the portlet api gives you the interfaces you need to  
accomplish your use case
Let me give it a try.
Using strictly the portlet api, it doesn't have a concept of groups.
Im not sure how many groups you have, by why not have the  
administrator go into edit-defaults mode, and configure the portlets  
with the following preferences:

groupA-connection = jdbc:mysql://server1/schema1
groupB-connection = jdbc:mysql://server2/schema2
groupC-connection = jdbc:mysql://server2:schema3

and so forth
then in your portlet, lookup the preference based upon what group the  
user is in. Of course there is no standard way to do that in the  
portlet api short of getting the Subject in a Jetspeed specific way

If you changed your requirements to use "roles", we could make this  
work by checking what roles the user is in (request.isUserInRole(role))

I see a possible problem with the case you have an admin having to  
set preferences for each user (not sure if thats what you need, but  
it would be a problem as its not supported by the UI)
I think you could one time populate that with seed data, but it  
sounds like you need a way to edit preferences by an admin for a  
specific user
That is not supported. So I think I understand why you need to add/ 
remove entities and preferences. Here is the API:


and yes, you can delete an entity, call

PortletEntity entity = entityAccess.getEntity("entityid");

Of course you will need to delete the preferences associated with  
that entity, I think I already gave that code in another email

Another possible solution, using the Jetspeed SSO service. You can  
store your connection strings in the Jetspeed SSO storage, on a per  
group basis.
Connection strings can be configured on a per group basis, then you  
can retrieve the connection through a portlet (see the  
DatabaseBrowserPortlet for an example)
Take a look at the SSO Administrative portlet: You can setup the  
credentials there for a group

In your portlet, then you just get the credential (a connection  
strong) via a sso.getCredentials call.
Here we use a combination of SSO storage and preferences storage for  
the connection string, since the credentials need to be encrypted
This is a snippet from the DatabaseBrowserPortlet:

                 BasicDataSource ds = new BasicDataSource();
("SSOJdbcDriver", ""));
                 ds.setUrl(prefs.getValue("SSOJdbcConnection", ""));
                 String ssoURL = prefs.getValue("SSOSite", "");

                 // SSO API lookup
                 SSOContext credentials = null;
                     if (sso == null)
                         throw new SSOException("SSO Not supported.");

                     credentials = sso.getCredentials(getSubject(),  
                 catch(SSOException ssoex)
                     throw new Exception("SSO credential lookup  
failed. Error: " + ssoex.getMessage());

                 String ssoUserName =  
                 String ssoPWD = credentials.getRemoteCredential();
                 ds.setPassword( ssoPWD );
                 con = ds.getConnection();

it will find credentials based on the user's group membership or by  
specific user, depending on how your administrator configured it
Albeit its not fully portable, it does very nicely abstract the SSO  
functionality into a service paradigm with a supported-open-source API

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message