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 Mon, 05 Nov 2007 07:40:43 GMT
Oops, the mail went to the public list. Not any private info yet. We can 
discuss this publicly and get more inputs from other users.



Mansour wrote:
> David, thank you for your help in this. I decided to exclude the 
> public mailing list form my reply in order to feel free in giving info 
> about what I am trying to do. Your last reply resolved big part of the 
> problem, and I just need to make sure that I understand everything. 
> Taking a real life example will help a lot.
>
> Let's say I need to write a portlet "application" that contains few 
> reports for a hotel system:
> 1- moth to date (MTD) revenue.
> 2-YTD revenue.
> 3- sales.
> 4- expenses.
> 5- report of empty rooms.
> 6-report of rooms to be cleaned.
> 7-rooms need maintenance.
> ...
>
> This portlet application is to be hosted for few hotels on one 
> "single" portal server.
> For each hotel, I need to create an instance. And I need to set the DB 
> connection and credentials and it should not be changed by any one else.
> When the user logs in , she has the choice to add this instance to 
> here page. She can add more than one instance and customize them. For 
> example, a revenue manager may add an instance and using the edit mode 
> she can configure this instance to show the YTD revenue report. She 
> may add another instance and configure it to show the sales as well. 
> The revenue manager has access to any type of report she wants. The 
> cleaning person in the hotel should not view the expenses. She should 
> only see the rooms to be cleaned and may be maintenances. The 
> maintenance guy should not have access to the reports of empty rooms.
>
> In this case I will create the number of reports I need (using BIRT 
> and eclipse) and wrap them in a portlet application. and deploy it. 
> Then I will customize the DB connection for each hotel in the global 
> preference ??  so no one can change it. Am I right ?
>
> then I may give the users edit permissions so that they can choose 
> what report to show. Correct ?
>
> Now, how can I tell jetspeed, don't let the cleaner see the expenses.
> One way I though about is through the roles but don't I need the name 
> of the reference of the entity "instance" ? if yes how can I get it? 
> Further more, this has to be done by the administrator on the site (in 
> the hotel). I can not give access to the j2-admin, and the admin can 
> not use PSML. And this is where the confusion starts.
>
>
> On the other had, the entity is not deleted when yo remove it from the 
> page, it's just hidden. If you go to the entity editor, you can see it 
> there?
>
> I hope things make sense now and you can understand what I am trying 
> to do. You can adopt this example for any other application (ie. car 
> rental, car dealership,...etc). I am still in the very early stages of 
> this project and I am not in a rush to get know how to get this done 
> know (it would be nice thou). The most important part to me is to know 
> if it's possible and easy with JS2, and if not, do you see this will 
> change in about 3 months from now?
>
>
>
> Thank you for your help.
>
>
>
> David Sean Taylor wrote:
>>
>> On Nov 3, 2007, at 2:50 AM, Mansour wrote:
>>
>>>>>
>>>>
>>>> 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.
>>
>> I agree with what you are saying there, your business logic shouldn't 
>> be configuring security, thats the role of the portal as that follows 
>> the separation of concerns pattern
>>
>>>> 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.
>>
>> I think this is a good case for "default" preferences. Remember you 
>> can have 3 kinds of preferences:
>>
>> 1. "global" default preferences per portlet configured in the 
>> portlet.xml
>> 2. Default preferences per page configured on the portlet page in 
>> "edit_defaults" mode
>> 3.  the user can have user-specific preferences per portlet on a page.
>>      this implies that you can have two of the same portlets  on the 
>> same page with different default preferences, as well as different 
>> prefs per user
>>
>> So say we have a portlet named ReportPortlet with prefs named 
>> "connectionString", "userName", "password"
>> In the portlet.xml, we configure the global settings to:
>>
>> connectionString="jdbc:mysql:defaultServer"
>> username="default"
>> password="secret"
>>
>> and then the admin  goes into edit defaults mode, and overrides the 
>> connection to for a ReportPortlet placed on a page named 
>> "ClientOne.psml":
>>
>> connectionString="jdbc:mysql:clientOneServer"
>> username="client1"
>> password="secret"
>>
>> and then the admin  goes into edit defaults mode, and overrides the 
>> connection to for a ReportPortlet placed on a page named 
>> "ClientTwo.psml":
>>
>> connectionString="jdbc:mysql:clientTwoServer"
>> username="client2"
>> password="secret"
>>
>> and so on...
>> The one draw back here is that you will need to set the security 
>> constraints on the "fragments", or portlet instances, by hand in PSML 
>> file
>> We are working on a administrative "configure" mode though for 2.1.3 
>> to edit fragment constraints....
>> I guess one way to get around that limit in 2.1.2 is to have one 
>> ReportPortlet per client configured in the jetspeed-portlet.xml with:
>>
>>     <portlet>
>>          <portlet-name>ClientOneReportPortlet</portlet-name>
>>          
>> <js:security-constraint-ref>clientOne</js:security-constraint-ref>
>> ....
>>     <portlet>
>>          <portlet-name>ClientTwoReportPortlet</portlet-name>
>>          
>> <js:security-constraint-ref>clientTwo</js:security-constraint-ref>
>>
>> After all that, I may still prefer the SSO solution
>>
>>>>
>>>> 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 
>>> permissions?
>>
>> I think so, see above
>>
>>>> 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?
>>
>> By deleting a portlet from a page using the customizer, it has the 
>> same effect
>>
>>>
>>>> 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 ?
>>
>> Yes, there isn't much code there really.
>> You must be writing some code already for the ReportPortlet, so you 
>> can just use the code provided as a basis, and leave the majority of 
>> the coding to the SSO component
>>
>> ....
>>
>> As an aside, this makes me think of another approach using Java 
>> Permissions, which can be configured in Jetspeed.
>> I was thinking about setting up your own permission, say a
>>
>> public class ConnectionPermission extends PortalResourcePermission
>> {
>>
>> that would protect your connection strings, something like
>>
>>         <Permission type="connection" 
>> resource="jdbc:mysql:connection1" actions="connect">
>>             <roles></roles>
>>             <groups>one,two</groups>
>>         </Permission>
>>
>> of course that would take a enhancements to the XML support in 
>> Jetspeed and the administrative UI, but you could create these 
>> programmatically and add them to the system
>> I am not recommending this approach right now, just taking notes
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>


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


Mime
View raw message