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 Sun, 04 Nov 2007 03:44:32 GMT
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 

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

View raw message