portals-jetspeed-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mansour <mansou...@yahoo.com>
Subject Re: portlet entity Editor
Date Sat, 03 Nov 2007 09:50:49 GMT
David Sean Taylor wrote:
> 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".
I did not mean to do this. I am sorry that you took it this way.
> 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
 From my understanding, jetspeed can be used to manage the security and 
permissions. I did not know that I should handle this in my business 
logic. I though the businees logic is only for business logic, and the 
portal should help me separate the concerns by handling the permissions 
and access to the resources.
> 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:
that's exactly what I need. The top level (portal) administrator 
configures this connection strings. in other words, the top level 
administrator, creates as many instances as she needs. An instance for 
each client. Each client has an admin on site. The site admin can give 
permissions for the users (depending on their job) to view or modify the 
config. No user or admin can change the connection string. The users can 
choose to add the entity to the portlet entity to their page.
> groupA-connection = jdbc:mysql://server1/schema1
> groupB-connection = jdbc:mysql://server2/schema2
> groupC-connection = jdbc:mysql://server2:schema3
does this mean this can be done without programming the security and 
> 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:
> http://portals.apache.org/jetspeed-2/multiproject/jetspeed-api/apidocs/org/apache/jetspeed/components/portletentity/PortletEntityAccessComponent.html

> and yes, you can delete an entity, call
> PortletEntity entity = entityAccess.getEntity("entityid");
> entityAccess.removePortletEntity(entity);
I can delete entities but from code and not from j2-admin, right? no 
other way?

> 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
This sounds interesting, I will look into this and will let you know. It 
needs to do this from code ?

> 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();
>                 ds.setDriverClassName(prefs.getValue("SSOJdbcDriver", 
> ""));
>                 ds.setUrl(prefs.getValue("SSOJdbcConnection", ""));
>                 String ssoURL = prefs.getValue("SSOSite", "");
>                 // SSO API lookup
>                 SSOContext credentials = null;
>                 try
>                 {
>                     if (sso == null)
>                         throw new SSOException("SSO Not supported.");
>                     credentials = sso.getCredentials(getSubject(), 
> ssoURL);
>                 }
>                 catch(SSOException ssoex)
>                 {
>                     throw new Exception("SSO credential lookup failed. 
> Error: " + ssoex.getMessage());
>                 }
>                 String ssoUserName = 
> credentials.getRemotePrincipalName();
>                 String ssoPWD = credentials.getRemoteCredential();
>                 ds.setUsername(ssoUserName);
>                 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

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

View raw message