General discussion

Locked

Tech Spot

By write2munish ·
Tags: Off Topic
blog root

This conversation is currently closed to new comments.

41 total posts (Page 1 of 5)   01 | 02 | 03 | 04 | 05   Next
| Thread display: Collapse - | Expand +

All Comments

Collapse -

Navigation in a Portal

by write2munish In reply to Tech Spot

<div xmlns="http://www.w3.org/1999/xhtml">
<blockquote>
<br />If you offer more than a few portlets within your portal, then you need to think about how people will navigate between and among them. While it is tempting to just let users click the back button until they make it back to the portlet page, this is a highly inefficient method. When you have complete control over the development of the application that the portlet accesses, you should include breadcrumb navigation trails, links to the main sections of the portal site, and links to related portlets. <br />
<br />Information architecture has to be designed for a portal and its application just as in the development of any other Web application. A good navigation scheme within a portal should allow the user to answer each of the following seven questions from anywhere within the portal or its applications.<br />
<br />Seven questions to determine a good navigation scheme:<br />
<br />1. Am I still in the portal?<br />2. How do I get to the main page of the portal?<br />3. What are the major areas of this portal?<br />4. Where am I in relation to the main page of the portal and the other applications I have visited?<br />5. Where can I go from here?<br />6. How can I go back to where I came from?<br />7. When I leave this screen, will I be able to get back to it?<br />
<br />
</blockquote>
<br />
<div class="tag_list">Filed in: <span>
<a href="http://del.icio.us/write2munish/WPS" rel="tag">WPS</a> </span>
</div>
<!-- Search Google -->


<script type="text/javascript">
<!--
google_ad_client = "pub-7748261127957446";
google_ad_width = 160;
google_ad_height = 600;
google_ad_format = "160x600_as";
google_ad_type = "text";
google_ad_channel ="";
google_color_border = "6699CC";
google_color_bg = "003366";
google_color_link = "FFFFFF";
google_color_url = "AECCEB";
google_color_text = "AECCEB";
//-->
</script>
<script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript">
</script> </div><p><div class="blogdisclaim"><a href="http://tech-munish.blogspot.com/2006/03/navigation-in-portal.html">This post originally appeared on an external website</a></div>

Collapse -

When not to use Portals ?

by write2munish In reply to Tech Spot

<div xmlns="http://www.w3.org/1999/xhtml">
<blockquote>
<br />Portlets are not the solution to every design challenge. Here are a few things that portlets do not do well:<br />
<br />* Complex user interfaces do not translate well to portlets. The markup languages like HTML and WML simply cannot describe some interfaces. Try to imagine implementing an integrated development environment (IDE) like Eclipse or Visual Basic in HTML and you'll have the idea. Native applications and Java applications work better for this. (If you have a complex user interface and still want to take advantage of the benefits of portlets, WebSphere Portal does support Struts, which can be very helpful.)<br />
<br />* User interfaces with data that must be constantly updated are also not portlet material. When you update one portlet, all portlets on the entire page must be re-drawn, so it is generally not a good practice to have your portlets automatically reload themselves with new data. On the other hand, you can have "refresh" option in the portlet so your users can choose when to reload the page. You cannot be sure how often users will choose to refresh the page, so if your data must not be out-of-date, use a native application or a Java application instead of a Web application. <br />
<br />* Highly interactive user interfaces do not translate well to Web applications in general, or portlets in particular. If you want your interface to change automatically when a user takes some action, like selecting an entry in a drop-down list, you can either submit the form and reload the entire page (annoying), or use a scripting language to re-draw the portlet (very difficult). If you use a scripting language, you will need to make sure it works for all of the devices you want to support, and you will also need to make sure your portlet still works if scripts are disabled by some of your users. For mobile devices, you will probably need to have alternate JSP pages that do not use scripts. Native applications or Java applications are easier to make highly interactive than are Web applications.<br />
<br />* Portlets need to live "within their box." Be careful if you have a link in a portlet that takes you to a Web page outside of the portal server environment, because it is difficult to get back to the portal after that. Frames are not allowed (Internal frames are allowed, but only Microsoft Internet Explorer users can see them). Pop-up windows and scripts usually cannot be used for mobile devices. If you can't make your application fit into the portal framework, don't make it into a poorly-behaved portlet.<br />
<br />* If you will want to provide services to other applications, consider writing a Web service first. Once you implement a Web service, you can write a portlet to use it, and you can publish the Web service to share it with other applications. The stock portlet is a good example: the stock quote service should be a Web service that the stock quote portlet and other applications can use. In this case, you might also write a program that automatically sends users a text pager message when a stock reaches a certain price.<br />
<br />* If the company does not have a portal server yet, and does not plan to invest in one immediately, one can go ahead and implement the application as a servlet using JSP pages for the output. One can always convert it to a portlet later.<br />
</blockquote>
<br />
<div class="tag_list">Filed in: <span>
<a href="http://del.icio.us/write2munish/WPS" rel="tag">WPS</a> </span>
</div>
<!-- Search Google -->


<script type="text/javascript">
<!--
google_ad_client = "pub-7748261127957446";
google_ad_width = 160;
google_ad_height = 600;
google_ad_format = "160x600_as";
google_ad_type = "text";
google_ad_channel ="";
google_color_border = "6699CC";
google_color_bg = "003366";
google_color_link = "FFFFFF";
google_color_url = "AECCEB";
google_color_text = "AECCEB";
//-->
</script>
<script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript">
</script> </div><p><div class="blogdisclaim"><a href="http://tech-munish.blogspot.com/2006/03/when-not-to-use-portals.html">This post originally appeared on an external website</a></div>

Collapse -

When do portlets make the most sense?

by write2munish In reply to Tech Spot

<div xmlns="http://www.w3.org/1999/xhtml">
<blockquote>
<br />
<a href="http://tech-munish.blogspot.com/2006/03/when-not-to-user-portals.html">Last time</a>, I blogged about when not to use portals. This time, I am blogging about when portlets make sense. So,now if your goal is to bring together your Web applications and information into one convenient place, portlets are the obvious choice. If your development goals are somewhat different, consider these other portlet and portal server features that you might want to take advantage of:<br />
<br />* Portlets can be extended to work on many client devices. The users can move from computer to computer, and mobile device to mobile device, and still use the infomation and applications they need.<br />
<br />* Portlets allow you to easily customize their content for different user groups, and individual users can rearrange and tailor them to their needs.<br />
<br />* One can make the portlets have a unified look, and change their appearance quickly, using Cascading Style Sheets along with themes and skins that the portal server provides. You can create your own themes and skins as well, to better reflect your company's image and style.<br />
<br />* Portlets can be published as Web services, so that companies outside of your portal server's environment can easily write programs to use them.<br />
<br />* The IBM WPS provides excellent support for internationalization, beyond what the Web Application server provides. It is straightforward to develop portlets that will display correctly for international users, even in double-byte or bidirectional languages like Chinese and Arabic.<br />
<br />* Portlets help divide complex applications into tasks: in general, one group of closely related tasks equals one portlet. WPS's administration portlets are a good example: like the administration tasks can be broken down into categories (Portlets, Portal Settings, etc.), groups of related tasks (Manage Users, Manage User Groups), and single tasks (Search for users, Create new user).<br />
<br />* Portlets make it easy to add features to your applications later. If the new feature is large, one can create a new portlet. For small updates, you can update the existing portlets without losing users' individual preferences.<br />
<br />* Portlets, like other Web applications, play well with firewalls. They use standard Web protocols to receive and display information.<br />
<br />* You only need to install and configure portlets once for all of your users, which is much easier than working with stand-alone applications on each computer. This logic applies to the other Web applications as well.<br />
<br />* The portal server works with the Web application server to provide security, installation support, reliability, and availability for many users, so you don't need to spend a large part of your development effort working on these features.<br />
<br />* Once you do invest in a portal server, you may find its advanced features useful: content management, transcoding, voice support, and offline browsing, among others, useful for integrating into your application<br />
</blockquote>
<br />
<div class="tag_list">Filed in: <span>
<a href="http://del.icio.us/write2munish/WPS" rel="tag">WPS</a> </span>
</div>
<!-- Search Google -->


<script type="text/javascript">
<!--
google_ad_client = "pub-7748261127957446";
google_ad_width = 160;
google_ad_height = 600;
google_ad_format = "160x600_as";
google_ad_type = "text";
google_ad_channel ="";
google_color_border = "6699CC";
google_color_bg = "003366";
google_color_link = "FFFFFF";
google_color_url = "AECCEB";
google_color_text = "AECCEB";
//-->
</script>
<script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript">
</script> </div><p><div class="blogdisclaim"><a href="http://tech-munish.blogspot.com/2006/03/when-do-portlets-make-most-sense.html">This post originally appeared on an external website</a></div>

Collapse -

Using XMLAccess as Release tool on a WPS project

by write2munish In reply to Tech Spot

<div xmlns="http://www.w3.org/1999/xhtml">
<blockquote>
<br />Although there is no automated method to move Portal applications from one environment to another, there are two options:<br />
<br />* Completely replace the old release with a new release. The drawbacks of this option is that any data that was customized by the user is lost. While this option works, it is not the recommended way.<br />
<br />* Use the XMLAccess tool to load incremental or differential release<br />
<br />
<b>The XML configuration interface</b>
<br />
<br />The XML configuration interface is more commonly referred to as the XMLAccess tool, because xmlaccess is the command that is executed. The tool provides a batch processing interface for Portal configuration updates and allows you to export an entire Portal configuration or parts of a configuration. For example, you can process and export specific pages to an XML file. You can then re-create the exported configuration from a file on another Portal. <br />
<br />While XMLAccess is as simplified bulk transfer utility, there is no magic button that automatically moves all the components of your Portal to the next environment. The XMLAccess tool is best for the initial loading of Portal application and for doing incremental releases. However, it is increasingly being used as a command line Portal administration tool.<br />
<br />I will talk more about XMLAccess next time.<br />
</blockquote>
<br />
<div class="tag_list">Filed in: <span>
<a href="http://del.icio.us/write2munish/WPS" rel="tag">WPS</a> </span>
</div>
<!-- Search Google -->


<script type="text/javascript">
<!--
google_ad_client = "pub-7748261127957446";
google_ad_width = 160;
google_ad_height = 600;
google_ad_format = "160x600_as";
google_ad_type = "text";
google_ad_channel ="";
google_color_border = "6699CC";
google_color_bg = "003366";
google_color_link = "FFFFFF";
google_color_url = "AECCEB";
google_color_text = "AECCEB";
//-->
</script>
<script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript">
</script> </div><p><div class="blogdisclaim"><a href="http://tech-munish.blogspot.com/2006/03/using-xmlaccess-as-release-tool-on-wps.html">This post originally appeared on an external website</a></div>

Collapse -

XMLAccess and WPS

by write2munish In reply to Tech Spot

<div xmlns="http://www.w3.org/1999/xhtml">
<blockquote>
<br />Last time, I talked about the Release process for WPS using XMLAccess as the tool, <a href="http://tech-munish.blogspot.com/2006/03/using-xmlaccess-as-release-tool-on-wps.html">here</a>. Now, I going for more details on the XMLAccess to help gain an indepth understanding of the tool.<br />
<br />
<b>Why use XMLAccess</b>
<br />The major benefit of XMLAccess is its ability to update pages and
portlets without losing user customization. If you perform your updates
via XMLAccess, any user customization to a page or a portlet is
retained because the object IDs are retained.<br />
<br />For example, the organization may have deployed a stock portlet
that the user can customize to monitor certain stocks by adding just
those stocks to the portlet. If you update this portlet, you do not
want the user customization to be lost. The XMLAccess tool allows you
to maintain the user?s customization. When exporting and importing via
the XMLAccess tool, the object IDs of the portlet application are
maintained. When a user customizes a portlet or a page, these
customizations are stored in your back-end database. All these
customizations are stored relative to the actual portlet application.
The key that ties all of these customized versions of a portlet or page
back to its parent is the object ID. <br />
<br />
<b>How XMLAccess works</b>
<br />The XMLAccess command line client is a small separate program that
connects to the server using an HTTP connection, which allows you to
configure the Portal remotely. The XMLAccess command is located in the
wp root/bin directory of the Portal server and is xmlaccess.bat (on
Windows) or xmlaccess.sh.<br />
<br />The syntax for the command is as follows:<br />
<br />xmlaccess -user wpsadmin -pwd itso -in file.xml -out result.xml -url myhost:9082/wps/config<br />
<br />In the command line, use the following file names:<br />
<br />* file.xml: The name of a file containing the XML request (configuration export or update) that should be processed.<br />
<br />* result.xml: The name of the result file containing the XML output
(configuration export). You can later use that file to re-import the
exported configuration.<br />
<br />* url: The URL to access the Portal configuration servlet. This URL
consists of the Portal host name, the base Uniform Resource Identifier
for the Portal, as specified during installation (for example /wps),
and the servlet extension /config.<br />
<br />You can use the XMLAccess tool to transfer a complete configuration, including:<br />* Portlets<br />* Access Control List<br />* Portal Web application configurations (portlet applications)<br />* Portal skin definitions<br />* Portal theme definitions<br />* Portal portlet configurations<br />* Portal site map (pages, labels, and links)<br />* Portal URL mappings<br />
<br />With the XMLAccess tool, you can also:<br />* Load the WebSphere
Portal default portlets configuration during the initial install and
transfer parts of Portal configuration.<br />* Create and modify existing Portal artifacts incremental releases.<br />*
Delete Portal artifacts. However, you must manually add delete commands
to the input file. Keep in mind, although the XMLAccess tool is a bulk
transfer utility, the command does not know history. It only knows the
Portal configuration at specific point in time.<br />
</blockquote>
<br />
<div class="tag_list">Filed in:
<a href="http://del.icio.us/write2munish/WPS" rel="tag">WPS</a>
</div>
<!-- Search Google -->


<script type="text/javascript">

</div><div class="blogdisclaim"><a href="http://tech-munish.blogspot.com/2006/03/xmlaccess-and-wps.html">This post originally appeared on an external website</a></div>

Collapse -

Portal Frameworks

by write2munish In reply to Tech Spot

To create more complex portlet applications, using frameworks can save
a lot of development effort and assure that these portlet applications
are well-designed and maintainable. WebSphere Portal supports three
different frameworks: Struts, Java Server Faces, and the JSF Widget
Library.

<strong><br />
<br />
Struts</strong>

<br />
Struts is one of the oldest Web
development frameworks, and it has a very large developer community and
very good tools support. Struts is an open source project at Apache
[Struts] and was created to provide servlet and JSP programmers with a
multi-page, Model-View-Controller (MVC) framework. Because Struts was
developed for servlets, it does not work out-of-the-box with portlets;
portlets have the MVC patterns strictly built into the interface, with
an action and a render phase. In addition, the portlet and servlet
request/response are different and must be adapted. WebSphere Portal
provides a special version of the Struts V1.1 library that was modified
to support JSR 168 portlets on WebSphere Portal.<br />
<br />
<strong>Java Server Faces (JSF)</strong><br />
Java Server Faces is a UI
framework for Java Web applications which was standardized through the
Java Community Process. Because it is quite new, it took portlets into
account and can work with portlets and servlets out-of-the-box. In
addition to the UI components, JSF also provides infrastructure support
for state handling, validation, and event processing for these
components. It is a very powerful and flexible framework that works
well with portlets.

WebSphere Portal supports JSF by including
the JSF library so that themes and skins can utilize this UI framework.
Rational Application Developer provides tooling support. You can create
JSF-based portlets using a wizard, and you can use additional JSF UI
widgets that portlets might use.

<br />
<br />
<strong>JSF Widget Library (JWL)</strong>

<br />
JWL
is provided by Rational Application Developer and enables portal and
portlet programmers to use an additional widgets based on JSF. A
noteworthy feature of this library is that these widgets have client
capabilities. The widgets can perform processing on the client in order
to update their views, which saves round trips to the server,
dramatically improving the user experience because the response time is
shortened by orders of magnitude. You can deploy WebSphere Portal
portlets which use these widgets just like any other portlets.<br />

Collapse -

Portal Frameworks

by ananomouse1 In reply to Portal Frameworks

Wow. Really in-depth and insightful. Thanks for taking the time to share this. <br /><br />I appreciate the links to the mentioned frameworks also.

Collapse -

Portal Frameworks

by alind In reply to Portal Frameworks

I would say that the title is misleading. A more appropriate title would be WebSphere Portal & Web frameworks. This would saved me some time.

Collapse -

Obtaining the object ID for a page or portlet

by write2munish In reply to Tech Spot

There are several use cases when a portlet needs to obtain the object
ID used to uniquely identify a portlet or a page. For example, the
object ID of a page definition is required for a portlet to launch a
dynamic instance of that page. You can use the lookup() method of the
JNDI Context class to obtain the object ID for a portlet or a page,
passing the unique name of the page or portlet. As an alternative for
portlets, you can obtain the object ID by using JNDI lookup() and
passing a combination of the portlet application ID and the portlet
name.
<br />
<br />
? For JSR 168 compliant portlets, the portlet application ID is the value of the ID attribute of the
element in the portlet.xml. However, this attribute is not required by
the Java Portlet Specification. If the ID attribute is not set, the
portlet WAR file name is used as the portlet application ID.
<br />
<br />
? For IBM portlets, the portlet application ID is the UID attribute of the element. This attribute is required.
The following example shows both ways to find an object ID.
<br />
<br />
************************************************************<br />
 // initialization
Context ctx = new InitialContext();

<br />
<br />
// portal:uniquename prefix is required for unique name lookup
<br />
Name uniqueName = new CompositeName("portal:uniquename");

<br />
<br />
// portal:config/ prefix required for portlet definition lookup
<br />
Name portletName = new CompositeName("portal:config/portletdefinition");

<br />
<br />
// the unique name assigned to the page is example.org.page
<br />
uniqueName.add(org.example.page);

<br />
<br />
ObjectID oidForName = (ObjectID) ctx.lookup(uniqueName);

<br />
<br />
// appID and portletName have already been set programmatically
<br />
portletName.add(appID);
<br />
portletName.add(portletName);

<br />
<br />
ObjectID portletDefOID = (ObjectID) ctx.lookup(portletName);<br />
<br />
 ************************************************************
<br />
<br />
The
Name used for the lookup() method is created from a CompositeName,
which is prepopulated with the required portal prefixes enclosed in
quotes. This technique is used to avoid having to escape special
characters in the prefix.

Collapse -

Portal Search - WPS V5.1

by write2munish In reply to Tech Spot

Portal Search has undergone significant changes in the WPS V5.1

<b>Search Portlets</b>
There is a new Portal Search Box and Search Center portlets that presents a search box on every portal page. When the users enter a search string and click Search, the portal takes them to the new Search Center portlet and applies the search criteria and shows them the search results.

<B>Catalog</b>
Another, new development is the Portal Search can be assigned to external/internal web sites. Portal Search allows crawling and indexing portal pages. The crawler can fetch and index all pages with portlets to which it has access rights. This way you can enable users to search those pages. You can define which portlets on which pages you want to make searchable. You can do this by granting the required access permissions to the crawler user.

<b>Security</b>
Another feature is limiting the search results based on the user privileges. Each individual search collection is now a separate portal resource. You can give users access permissions on them and thereby make different search sources available to different users or user groups. This applies to all search collections. For example, in the Search Center users see only the tabs for those search collections to which they have access.


Some of the drawbacks, I encoutered is the lack of availability of search features for anonymous users. Also, settings up the search with results in mulitple languages is very tedious. The whole crawlong and cataloging of the pages and documents takes too long.

Back to After Hours Forum
41 total posts (Page 1 of 5)   01 | 02 | 03 | 04 | 05   Next

Related Discussions

Related Forums