Monday, May 10, 2010

Change desktop look and feel dynamically?

Hi


I will see if I can find the API that you are asking for and will keep you posted. Just wanted to share this another approach and see if this works for you.

I would try a different way to achieve what you want. From .portal file, create 2 Desktops from Portal Admin Console. Then for each Desktop, modify the look and fee that you want. The desktops can be named in such a way that the language initials will be in the end something like this:

http://yourHost:yourPort/yourWeb/appmanager/anyPortalName/en (English with corresponding look and feel)

http://yourHost:yourPort/yourWeb/appmanager/anyPortalName/fr (French with corresponding look and feel).

Now from Header or Footer, choose language drop down box, when they change the language, you can call java script function or in pageflow, your action method. Based on language they selected, construct the above url using request.getContextPath() etc etc. and Append the language in the end. This will be more dynamic. So in future if you add more languages, just create corresponding desktops and you should be good to go.

One of the main uses of Desktop approach is this one only. Like to have different customized Desktops with different look and feel and say even different books and pages (customized etc).

Also, when user changes the language, you can store this language value in his preferences (custom user preferences file). So once he logs in, in login pageflow (or backing file code), you can get this preference value and redirect to that Desktop. In this way, everytime user do not need to login and then change the language.

Some code snippet in Pageflow login() action method:
String baseUrl = this.getRequest().getContextPath(); //http://host:port/yourWeb

String selectedLanguage = "en"; // Get this from selected drop down box or in login portlet once user logs in from his preferences

String queryString = "/appmanager/somePortalName/" + selectedLanguage;

baseUrl = baseUrl + queryString; //http://host:port/yourWeb/appmanager/somePortalName/en

this.getResponse().sendRedirect(baseUrl.toString());

Try something along these lines.


And also Take a look at http://download.oracle.com/docs/cd/E13155_01/wlp/docs103//javadoc/com/bea/netuix/laf/PortalLookAndFeel.html
 
Thanks,
Venkata Sarvabatla

Saturday, May 8, 2010

Installation of Weblogic11g's Portal and Webcenter

What are the minimum of weblogic components required for the installation of Portal and Webcenter?


Weblogic Portal and WebCenter are totally 2 different Products.


Latest version of Weblogic Portal is 10.3.2 which can be installed from this bottom link. This installation do not need any prerequisite software. This installer will install JDK, Weblogic Server, Eclipse IDE and all Portal Framework Components. There is NO weblogic portal 11g

http://www.oracle.com/technology/software/products/wlp/index.html

If you mean Weblogic Server, then yes, we do have Weblogic Server 11g latest version that you can download

Coming to WebCenter Suite, it includes multiple components. Its a Suite. See bottom link to see what it includes (Expand small + icon next to the product name).

http://www.oracle.com/technology/software/products/middleware/htdocs/fmw_11_download.html

To run WebCenter applications, you do need Weblogic Server installed. This is the only dependency I am aware of. Ofcourse you need full version of latest JDeveloper that includes all WebCenter ADF modules.

As of now only in portal 10.3.2, if I am not wrong, you can consume WebCenter Portlets in Weblogic Portal using WSRP.

Thanks,
Venkata Sarvabatla

Thursday, May 6, 2010

Portals vs Desktop

Hi

Guessing you are familiar with Java Class and Objects (instances), I will give that analogy. Its not exactly same but concept wise it is same. Portal (.portal file) is like a Class file. Desktop(s) that you create from Portal Admin Tool are like Instances of this single .portal file. Note that each java object instance can have its own values for the instance variables. Same thing for each desktop can have its own set of Books/Pages/Portlets, look and feels etc.

.portal file is a single file that has all the Books, Pages, and Portlets on Pages along with some look and feel stuff. Now desktop is derived from this .portal file. Imagine we have a portal for a company that has HR Dept, Marketing Dept, Sales Dept. For this we can have single .portal file, with 3 Pages HR, Marketing, Sales. Now we can create 3 Desktops like HR Desktop, Marketing Desktop, and Sales Desktop. By default all these desktops will have 3 pages. But for HR Desktop you can remove 2 pages (Marketing and sales). For Marketing Desktop you can remove HR and Sales Page etc. So you will have different desktops for different deparments. But .portal file is the central main file having all the pages and portlets. You can achieve this using Entitlements also by setting proper entitlements for each Page and adding users to those Entitlement Roles. Just for explaination I gave above example.

When we access portal application from .portal file, it is rendered from .portal xml file. But when we create Desktop, .portal file is Parsed and all the stuff is stored in the Database like Books, Pages, Portlets information, Look and feel stuff etc etc.

Also we cannot set Entitlements to .portal file. We can set them only to Desktops. Ofcourse once we set to Desktops, it works for .portal file also. I have seen this. But in reality Entitlements gets applied only to Desktops.

Also, if you want End User to customize the Portal application, like they can add or remove Portlets, pages etc, they Cannot do this in .portal mode. They can do this only in Desktop mode. This is called Visitor Tools Customization. Just like in yahoo or google, we can edit and add/remove portlets, change look and feel etc.

Performance wise, Desktop will be little bit slow, speically if you allow end users to customize their Desktops. For each Customized Desktop, there will be chain of records in Portal tables starting from Desktop, Book, Pages, Portlet Tables. You can see multiple records in PF_Desktop_Instance table. There will be slight performance issue.

But it is always good to have Desktop and expose Desktop as the final url for any portal application. In this way, we can edit .portal file anytime like add new books/pages/portlets etc but Desktop will not be affected. When we are ready to move all these changes, then you can update Desktop with all new changes you made in .portal file.

Having multiple .portal files is not a good idea, unless they are totall different from business point of view like totally different areas/applications. Have one .portal file. Make use of Desktops. Also make use of Visitor Entitlements which are very powerful things from BEA. Using Entitements and without any coding involved, you can control what parts of Portal (Desktop) like Books/Pages/Portlets are visible to which set of Users (Roles, Groups etc).

So given a choice, go for Desktop mode only. Atleast one Desktoo should be fine.

You can fine more details in oracle docs on portal.

Using Multiple Desktops - http://download.oracle.com/docs/cd/E13155_01/wlp/docs103/portals/optimize.html#wp1001690

Managing Portal Desktops - http://download.oracle.com/docs/cd/E13155_01/wlp/docs103/portals/creating_staging.html
 
Venkata Sarvabatla