developerWorks: The case for portlets

Discussions

News: developerWorks: The case for portlets

  1. developerWorks: The case for portlets (18 messages)

    IBM developerWorks has published an article discussing "How to decide if portlets are your best option". Some software designers always choose the latest technology to implement their solutions. Others tend to stick with more familiar, time-tested platforms. What is the case for portlets vs. the likes of JSP and web frameworks.

    The article covers:

    - What are portlets? Portals? A portal server?
    - Understanding Java servlets, JavaServer Pages, and Microsoft Active Server Pages technologies
    - Understanding portlets
    - Portlets and Web services
    - When do portlets make the most sense?
    - When are other solutions better?

    Obviously, a focus of the article is IBM's portlet solution, but you could substitute others.

    Read IBMs portal article

    How many people are using "out of the box" portal solutions? Do they offer the hooks that you need? Are many people waiting for the portlet spec: JSR-168?

    Threaded Messages (18)

  2. developerWorks: The case for portlets[ Go to top ]

    Let me not miss a thread :-)

    Assuming you like me think Struts is the most popular framework out there, I found that Tiles work great as portlet, relative to other "portlet" aproaches, as per

    Tiles for Struts

    http://blogs.browsermedia.com/patrick/index.do?date=20030211#130200

    Have other people tried something that worked out in production?

    .V
  3. developerWorks: The case for portlets[ Go to top ]

    , I found that Tiles work great as portlet, relative to other "portlet"

    > aproaches, as per

    How do you turn Struts/Tiles into a portlet framework? For one thing there is no separation between request and rendering phase as in what is normally considered portlets. Portlets isnt just putting a lot of stuff on the same page you know?
  4. Abrandft[ Go to top ]

    re: " there is no separation between"

    For seperating I mostly do MVC (Struts), that is the major separation. As you can se in Tiles 201 article, you can put things in scope for that tile.
    This is for the people who like me use Struts.

    Only if I need to; I use Standard Tags X:transform.

    .V
  5. Vick[ Go to top ]

    For seperating I mostly do MVC (Struts), that is the major separation.


    Yes, but that is a separation between logic and presentation, portlets introduce separate request and rendering phases - different thing...

    > This is for the people who like me use Struts.

    I use Struts too...and tiles seems great, but it is not a portlet framework...

    > Only if I need to; I use Standard Tags X:transform.

    Nice to know, but it has no bearing on this subject.

    BR - Johan
  6. developerWorks: The case for portlets[ Go to top ]

    How do you mean "separation between request and rendering phase?" We're using Weblogic Portal right now and it just seems to be .jsp snippets in a table. I'm interested to see what you think.

    Steve
  7. Request and rendering phases[ Go to top ]

    I think what Johan is referring to is the method used, at least in IBM's portal server, where all portlets first go through a request phase in parallel, and then they all begin a rendering phase in parallel. The request phase allows portlets to generate events, which can be received by portlets that are registered to listen for specifc events, and then these portlets can take some other action. Once all events are fired/handled, and other request processing is complete, I think the rendering phase kicks in. That's why a combo of Struts/Tiles can't be considered a true portlet framework - that sort of request/render cycle support doesn't exist in Struts. Tiles may buy you a portlet-like UI, but that's all.

    Rob
  8. Request and rendering phases[ Go to top ]

    Hmmm. That's interesting. WL Portal has an event framework, so I guess one can do something similar to IBM's design.

    It seems to be that portal vendors have done a really shabby job of educating the public of what a Portal product can do. I mean, even going through the meat and potatoes, what are the best practices? They have all these tag libraries that let you do events, campaigns, ads, etc. but I'd have to do some research to even get a grasp of how to properly use a request/rendering pipeline. And we've been using a portal product for a year and a half.

    Unfortunately, I think people just think of "portlet-like UI" when people hear portlets. If there really is more to a framework like this, then great, but so far the case really hasn't been made obvious.

    Steve
  9. Request and rendering phases[ Go to top ]

    I agree with your comments about portal vendors not really educating the public about what a portal does. But then, I think the concept of a portlet is misapplied a lot. To me, portlets address the need of having quick access to data from a lot of different sources, but that's all they address. You can view stock quotes, or emails, or weather info in a portlet, but you certainly wouldn't try to reserve a plane ticket in one. You'd need a full screen and a lot of page flow to build an effective webapp for that kind of function.

    I think the only case where portlets makes sense is as a home page for a user. There, you can throw all kinds of data in small helpings at the user. Most portlets like this tend to have 2 screens max - you enter data in the first screen, then the 2nd screen shows the results. And typically, if there are links anywhere, when you click on one, you get a new window with the page in it, so you never leave the confines of the portal page.

    IBM might be on the right track if they provide Struts support (though I'd rather use something else besides that). Ideally, that would allow you to have a page full of portlets that is highly personalizable and also have regular webapp's built.

    Rob
  10. A portlet, at least in WL has the capability of min/normal/maximizing itself in the portlet container. I don't think Tiles covers this. This allows one portlet to support a component (normal size) view on the home page and a maximzied (application) view and still be the same portlet. Your unit of work is still the portlet not the page or pages. This way you still benefit from all underlying portal services especially security, content management, and decoupled presentation.

    One thing most dicsussions don't cover is the levels of portal adminstration that allows multiple users, roles, presentations, and applications.
  11. we have a choice of using weblogic portal or struts/tiles in a project. since you seems to have worked with both technologies, can you identify the pros and cons between using weblogic portal and struts/tiles?
  12. Templates[ Go to top ]

    you can use templates in JSP without Struts too. Check out this for example:
    www.servletsuite.com/servlets/template.htm
  13. <quote>
    Although JSR 168 provides a portlet specification, portlets are not fully standardized yet?


    It’s almost a year since JSR 168 has been drafted and why aren’t portal servers following the standard. Does this standard lack any major functionality?

    We are using Weblogic portal server and looking forward to make a generic design so that our application is portable to any portal server with minor modifications. Any suggestions or pointers would be highly helpful.

    -Thanks
  14. as I know Websphere has the most compatible API to the JSR 168 coming up
  15. <quote>
    why JSR not followed by portal servers


    Good question. We are using ATG's portal framework (also runs on other app servers, not just Dynamo). We tried to use as much as possible out of the box, but heavy customisation was also needed. We have 3 channels: web, pda and wap. it was quite some effort to make it work.

    While every vendor has the same visual mapping of a portlet to a "content island", how this is modeled in each framework is very, very different. I don't think this will be portable in the near future.

    Tibi
  16. JSR 168 is not released yet[ Go to top ]

    JSR 168 may have been started a year ago but it has not been released as a community draft yet. That is why the portal vendors haven't released implementations of the spec yet.

    -Mike
  17. Good reasons not to use portlets[ Go to top ]

    I think this article is actually quite good. Note that it is written from an IBM perspective, so the benefits that are listed are all benefits of IBM's portal server, not necessarily all portal servers. In addition to IBM's, I've used two other vendor's portal servers, and all 3 differed a great deal in how they approach portlets.

    If you want to use a portal server, it is very important that you don't let the concept of portlets drive the UI design, and I think the authors touch on this. We had to use a portal this past year on the project I was on, and this was decided before any UI design was done. It turned out that 90% of the interfaces we needed were fairly complex, many of them requiring all of the real estate that the screen could offer. If this is your case, don't even think about portlets, as using a portal server for us was a big mistake.

    I like to view portlets as providing read-only or simple views of data. Portlets just can't provide a lot of page flow support for complex UI's. They've got plenty of benefits, as described by IBM, but there are plenty of drawbacks as well.

    What does sound interesting is that IBM provides Struts support in their portal server now. To me, the ideal would be a server that provide portlet support, since often home pages work well as portlet-driven pages, and a server that also provides solid webapp support for real web applications (I wouldn't call a portlet a real web application, it's like a lite webapp). I'm hoping that if they provide Struts support, then it would be feasible to integrate something like WebWork or another webapp framework as well.

    Rob
  18. paradigm shift[ Go to top ]

    It would be nice to have some sort of orgainized criteria that would help determine if a portal and portlets are required. Choosing a portal container and portlet componentization strategy seems to be heading the top of Maslow's Hierarchy of Web App Needs. The simplest need to get on the web requires only HTML and then progresses with ASP, then JSP, then Struts, and finally portals. The complexity goes up at each level. With Portals you get to delegate your security admin back to marketing/hr, presentation back to creative, and decouple your tightly coupled and coordinated releases with other groups so that you can focus on getting your app out the door.

    It comes at a cost. The hurdle to get over is the paradigm shift from page to portal component and inherent limitations. Working with something that lives between <td> instead of <html>. When you control the page you can control refreshes and frame use. Now you have neighbors (other portlets) and neighorhood convenants.

    JSR 168 should be out in March and I hope portals or at least portlet containers are designed as presentation tier web application frameworks with standardized APIs to authentication/authorizaton, presentaton resources (client type, content, layout), and application components. Also, as a development manager I want my unit of work to be my application where I don't have to coordinate releases with other groups. All portlet containers should be able to run on top of a Servlet Container with standarized APIs to required Portal services. Problem is, once you use a vendor's taglib you've drunk the koolaid.

    I's like to see Jakarta taglibs work on standard API's to personalization, content management, and other services.
  19. You're looking in the wrong place[ Go to top ]

    The site you're looking for is:

    portolets.html