I have a project in which my client is asking me to use portlets 1.0 spec and Websphere Portal Server 6.0. I haven't worked with portlets before but what I've heard of them always have been bad critiques. What are the reasons besides the obvious of using them? If not reasons, what arguments could I use to avoid them?
As someone who has had several jobs (including my current one) developing Java portlets, I'd say don't use them.
Here's the problem:
If you just wanted to use the pre-existing functionality of the portal you are choosing, then use a portal.
If your use of portlets is just to construct a small, light, primarily read-only web-based dashboard where you can quickly look at disparate information, then that's fine.
But if you (or more likely someone higher up on the org chart) thinks of portlets as a way to put a bunch of different web apps on a page and have it all "just work", then you are headed for a world of hurt. Portlets are highly-restricted, self-contained islands of functionality, not web apps in tiny squares on a page.
Every one of my portlet-based jobs has made this mistake, and there's no light at the end of the tunnel. As a portlet developer, here's a small list of things you're used to doing in regular web apps, that you can't reliably do in portlets:
Generate URLs to other pages. You'll need a vendor-specific way to do that, since the Portlet API only allows you to generate URLs that target the portlet that generated them.
Read and set HTTP headers or set the HTTP response code (so no redirects or HTTP caching, since you don't own the page your portlet will be placed on)
Having to namespace all identifiers in the generated page. This means HTML id attributes and JavaScript function names. Since the namespace has to be determined at runtime to ensure uniqueness, you can't have these Javascript functions reside in a separate browser-cachable file they have to be in the response body for your portlet.
Portlets feel as if they were designed for the state of web development as it was in the mid to late 90s (pre-AJAX). But they are ill-suited for today's web development environments (AJAX, single-page rich web apps, etc.) that assume you have complete control of the request/response cycle.
The problems I have with portlets remind me of the same problems as EJBs-
portlets require you to write special code that can only be hosted and run in a special server;
every portlet server vendor has custom extensions/configurations/additional abilities so it's not trivial to change server vendors;
portlets seem to be overly complex to cover functionality that 90% of people wanting to use it don't need
I'd suggest something like Google Gadgets as the Hibernate to portlet's EJB -
Javascript framework - server-side pieces can be written in any language, hosted on any server.
simpler to use
lots of portal servers support it, and it's more portable across vendors because it's not as complex, and it's not a spec for vendors to implement (and extend)
Portlets are attractive to a business because of the promise of flexibility, you an allow customers to tweak and rearrange components on the page, and if you are primarily serving content then they are an effective means of doing that.
In my opinion portals are well suited to aggregating portlets that are either pure content, functionally independent or simply related (e.g when you pick an item from a list in one portlet, you update another to show the details).
Portlets can also enable reuse, because you can configure them into multiple pages/locations fairly simply.
Where the problems can start is when you are trying to decompose complex business functions with multiple steps and interactions. In this scenario determining the granularity of the portlets is more of an art than a science, and careful consideration needs to be given to the interactions between the portlets.
You also need to consider the flexibility of the UI. If you have a set of portlet building blocks your business need to be clear that they can rearrange those blocks, but moving items between portlets involves a rewrite. For example moving the submit button from one portlet to the bottom of the page is not trivial.
So in summary, I guess it depends on what you are trying to do and how much reuse you anticipate of the components. It may be simpler to manage the reuse by creating technical components that IT build into servlets, or it may be that portlets are perfect for your business. There's no right answer, you just need to carefully consider what you are trying to achieve. If you do decide on portlets, you need to embrace the full lifecycle, and avoid any temptation to work around them, you can quickly find yourself in a bad place with all the overheads and restrictions of portlets, without being able to realise the advantages.
Related
I have recently been investigating java server-side web frameworks to serve as a rendering platform for a new B2C web site project. Based on my research I would broadly divide the available solutions into two camps:
those such as JSF and Tapestry, which essentially boil down programming HTML and servlets, and
those such as Wicket, Vaadin and Echo, which dispense with the HTML templating and offer a programming model akin to SWT thick clients, based on a hierarchy of windows, view components, and events, outputting the client-side HTML based on this hierarchy.
The second group - which is one branch of RIA frameworks - offer a lot of desirable features in terms of server-side control, developer productivity (e.g. simplicity, not needing to deal with servlet reentrancy issues etc.), view widgets, out-of-the-box cross-browser compatibility and cool visual effects.
What's not so desirable for a B2C is that the RIA frameworks deliver Single Page Interfaces. At the end of the day, they don't naturally allow browser history and bookmarking (it can be done, but it's messy and limited, e.g. to URL fragments only) and, perhaps most significantly, they are indifferent to SEO, which is a bit of a showstopper for a consumer-focused website.
This would be down to delegating the servlet and HTML control to the framework. The question is, is there a way to have both, or is that just too utopian? A server-side RIA-type framework with all the benefits that that brings IMHO, but with flexible and friendly URLS for bookmarking along with SEO awareness?
Such a solution might not be a single framework, of course, but be layered. As an aside, the framework itsnat seems to offer much of the above, but due to the way that it's implemented I would have a lot of concerns about server overhead (CPU and memory) - although I do think that it is kind of inevitable that RIA frameworks will be more server-heavy than the servlet/templating programming approaches.
Anybody know about alternative ways forward?
JSF and Tapestry can manage restful like URLs out of the box. Wicket can be extendeded to support them.
For wicket check this.
Tapestry supports an URLRewriter. This is useful in case you want to change your URLs and keep backwards compatibility with the old urls.
Take a look to this complex ItsNat based example, Single Page Interface can be SEO friendly and memory consumption can very low, read "disconnect child nodes from client" to know how you can save memory in server.
The Java world has a JSR-286 standard for how portals and portlets should interoperate: software components sharing a unified web page.
There seem to be a number of portal implementations. But is there a live "marketplace" of interchangeable portlets that will run in them? From what I can find searching the web, it looks very lopsided - all portals and no portlets. It's like if there were dozens of Android phones and no apps.
If a product were to base itself on JSR-286 (or some implementation thereof), what's the likelihood of a corporate customer having a bunch of portlets that it might want to add to the portal?
It strikes me that most corporates will already have a portal-like page based on their choice of ERP or CRM product that their business runs on, or maybe even just MS Outlook's "Today" page. So if I ship a new product intended for corporate customers, and I make it a portal (rather than a set of portlets) what is the likelihood of my customers abandoning their existing IBM/SAP/Oracle portal and using my portal as their new homepage? (I'm guessing: not great.) And if I make it a set of JSR-286 compliant portlets, are my customers going to have a way to host host portlets? (I'm guessing: also not great).
Finally, JSR-286 seems quite mute about HTML+JavaScript, i.e. how portals and portlets would interoperate inside the browser. It's all about Java-based server-side stuff, defining a way to cooperate in the use of URLs so that each full-page-refresh can be routed to the correct portlet. It doesn't seem to acknowledge the modern, rich AJAX approach. It mentions AJAX only in passing.
This blog post (and the comments under it) have provided a lot of food for thought and seem to confirm my suspicions:
Professional hands-on experience along
with the above research led me to the
conclusion that the portal
architecture lacks enough technical
advantages and distinguishing features
to warrant an increase in acceptance.
In practice, few applications can
constrain themselves to the isolated
and disparate functionality of
portlets, and relinquishing this
degree of architectural control is
unrealistic in enterprise-level
software... the portal architecture's
window of opportunity to become a
mainstream technology has not only
closed, but closed quite some time
ago.
So to summarise this as a more coherent question: what actual value would I get by building on JSR-286 at this point?
The only advantage I know of offhand is that when vendors of enterprise software have "portal integration" on their feature checklist, it usually means they've written portlets according to the JSR-168 or JSR-286 standards. SAP, Banner, and Magnolia are some of the systems that we use here that work this way, and some organizations find value in the portal approach.
However, as you correctly point out, this imposes some frustrating limitations on the application author. We've also found the value of portals to be somewhat dubious when put up next to a Single Sign On system that saves the user the hassle of signing into multiple applications, but which still allows each application the full benefits of the browser environment.
FWIW, if you do decide to distribute your work as a collection of portlets, there are existing portal systems that are free/open source which you could provide for folks who didn't already have a portlet container:
http://java-source.net/open-source/portals
Hope all of that helps a bit.
I am in the process of writing a Java based web site. I am trying to figure out how to manage some of the content that will appear on different pages. Obviously I don't want to hard code the content; but on the other hand I also don't feel like using a full blown CMS like Alfresco or OpenCMS since I think that it is complete overkill for my needs.
So my question to the experts out there is what is a good way to separate content from the code and maintain it independently without resorting to a large scale CMS? There has to be some sort of middle ground that allows me to change content without having to redeploy the code or go through the other extreme with some large CMS. I don't need all that workflow or versioning stuff etc. Maybe there is an open source library or API that allows you to manage content in a simple way. So what are the opinions out there?
Cheers,
Luis
Beside Tomislav interesting advivce,
You can rely upon template engine (like freemarker or velocity or stringtemplate) to have on one side your page content and on the other your page rendering. This is, in a more evolved fashion, what good old JSPs used to do. But with a twist : using these template engine, your pages can be easily loaded from XML, as an example (I know, for having used recently freemarker on a personnal project that is is quite straightforward).
Alfresco is not designed to build web sites on (although yes, you can). You could try with Daisy ("a comprehensive content management application framework") or one of the other similar solutions from the open source CMS in java directory.
In the end, you might fall back on a relational database and the web interface technology you are most familiar with. Having said that, I would expect Grails or Rails might offer the best value-for-money if you're aiming for a moderately complex web site (authentication, separate back and front end etc.).
I am a newbie in web development using javascript libraries. But I recently saw a J2EE web application that uses ExtJS extensively (say 90%) for rendering the web pages. The web pages in question are either simple forms or grids (tabular reports). The JSPs are fairly threadbare and simply delegate to the ExtJS framework (using onReady function) which then makes AJAX calls to the server and renders the pages. There is a separate .js file for each web page that encapsulates all rendering logic within ExtJS functions.
This is the first time I am seeing an application coded this way. I would like to know if this is a common approach to use these days or is this an extreme use of a javascript library. What are some pros and cons of this design ?
Pro:
The system looks and behaves much better than with regular plain HTML
Con:
The system is hard to debug and modify if is not coded by developers with good experience on the framework.
You can mitigate that cons by using a server side library such as GWT that even can be used with Ext: GWT-Ext
Cons:
Pages won't work at all if the user
has JavaScript disabled.
The user
has to wait for the script to be
downloaded, parsed, and executed
before any content appears. Depending
on the design, the user may also have
to wait on some AJAX requests after
that.
Accessiblity is harder to implement.
My company develops RIAs like you describe as its main focus. These applications (some are in Flex, some in ExtJS) are designed to be highly functional applications for a relatively small set of people.
For ExtJS applications, our main approach is to have static HTML and JavaScript files that then build the UI on the client side (for users, they generally experience sub-second load times as everything is cached and JavaScript runtimes in newer browsers are amazingly fast). Whether it is an all-in-one 'HTML' page, or spread across multiple HTML pages depends on the app (or segment of an app).
All data is then served via AJAX requests through web services (mostly ESTful APIs). The ExtJS grid for example can be served with data with such a trivial server side component it's almost embarrassing.
All complex server side components that we write end up being complex business logic that is not suitable for the client side (or is a duplication of client side functionality for security or checking purposes).
All-in-all I am a big fan of this approach, for the right situation. I would not suggest it for public web sites - but it has a really nice niche in the business application space for example.
One advantage of a Rich Internet Application is that you free up your server(s) from the rendering responsibility, and delegate this to the clients (the browsers).
In a 3-tier architecture, you would literally take the whole presentation layer away from your hardware. You would just need to serve the static files (XHTML, CSS, JavaScript and images).
The idea behind portlets is that a website/page can be comprised of a number of applications that are developed individually. They are then fit together on a page by a portal much like a jig-saw puzzle. This allows functionality to be created independently and slotted together at a later date. This has many obvious benefits.
However. I cannot see how the portlet specification improves upon older ideas like server-side includes, from the point of view of a developer who needs to get something done, as opposed to publish a paper or make a keynote address.
The tone might be a bit negative, but my first foray into the world of portlets has left me thoroughly disenchanted.
From the point of view of the job of just 'including' some dynamic/static content on a web page, you're correct.
However there are a number of conveniences implemented, such as support for personalisation of the portlet (at the portlet/'include' level) and storing this info, a more rigid workflow for configuring what is displayed in the portlet and so on.
Plus obviously there's all the portlet arrangement code that you would have to write otherwise. Some portlet servers do a lot on the client side for arrangement (drag and drop of portlets etc).
You may find some of the discussion at the below URL helpful:
http://www.ibm.com/developerworks/ibm/library/i-portletintro/
For sure, the portals create the view essentially by doing lots of server side includes.
The portlet specs (JSR-168, 286) just define how to code a portlet so it fits into a portal. They only define things necesary for portlets to co-exist on the same portal page, things that are not a part of J2EE servlet or JSP definitions.
Without the specs, it would be hardly possible to use portlets from different development teams, or even different vendors on a single portal page.
Even a single J2EE application with a portal-styled UI can benefit from use of a portlet container - it can help to accomplish many typical UI-related tasks.
Consider e.g. these features defined by portal specs (just a very few):
Portlet lifecycle, isolated from other portlets.
Isolated URL spaces for each portlet
Portlet modes and window states
Portlet session scropes
Personalization, portlet preferences. Users configure apperance of their's portal pages by positioning and setting individual portlets.
Raising / comsuming of events (JSR-286)
...
The specs are not a rocket science, and also they do not pose a paradigm in UI design or so - to me, the most revolutionary about portals was the idea of a user's desktop brought into web applications.