Discussions

News: JSR 168 Portlet Specification Formally Approved

  1. The JCP Standard Edition and Enterprise Edition Executive Committee has approved the Final Approval Ballot of the JSR 168 Portlet API.

    The ballot was mostly a formality, with all companies voting "Yes" with no comment, except Apache who didn't vote, and IBM who voted "Yes" with the following comment:

    "
    IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
    "

    Also see a press release from Vignette which talks a bit about the approval and JSR 168, as well as Vignettes portal products.
  2. This is a meaningless JSR. Why on earth isn't there a general UI Component infrastructure instead? That would serve the need for portlets and a host of other scenarios as well.
  3. I'm sure it was easier to get everyone to agree on the Portlet spec than a general UI component infrastructure spec. Baby steps, I guess, which is fine by me, as I am looking forward to creating compliant portlets for some applications.
  4. Useless... or not[ Go to top ]

    This is a meaningless JSR. Why on earth isn't there a general UI Component infrastructure instead? That would serve the need for portlets and a host of other scenarios as well.


    Anyone who's tried to write a "portable" portlet using IBM's and BEA's products would disagree with you on that. The 2 systems arent' even remotely close to each other. Now that 168 is live, maybe BEA can release their super secret 168 compliant framework.
  5. This is JSF goals to provide a UI framework.

    You can build a portal using JSF as well as using UIComponents inside portlets.
  6. This is a meaningless JSR. Why on earth isn't there a general UI Component infrastructure instead? That would serve the need for portlets and a host of other scenarios as well.



    Because more often than not, you'd get an EJB-like spec which does everything but pleases no one.
  7. BTW, for those interested, I have a list of open source portal server implementations. Many of them have or are planning to support the new JSR specification.

    You can find the list here:

    http://www.manageability.org/blog/stuff/open_source_portal_servers_in_java
  8. This is great news!

    I was quite surprised to hear that some consultancies have already created portlets (I know of two cases, one for Citrix integration and one for sending SMS messages), and I talked to a customer last week who have begun adding a requirement to consultancies doing work for them that the result should be Portlet compliant. All of the customers and partners I've talked to really like the idea. It'll be interesting to follow and see how it works out in real-life.
  9. IBM says:

    This comment is not necessarily directed at the current business or license terms for this JSR.

    Then why in hell are you spamming the JSR Group? What's next, is IBM going to start selling ad space in their JCP Comment areas?
  10. Is it me or is this a step back?[ Go to top ]

    Maybe I misunderstood something about the spec...

    but in normal J2EE development we are taught that it is good to keep view and controller separate so we divide them up into JSPs and Servlets/EJBs/Other Stuff.

    And now we have this portal server that we can plug in portlets to. And these portlets bring with them view AND controller, their functionality WITH THEIR OWN DESIGN. How will we get these portlets to fit into our corporate design portal? Is there some functionality in the spec that will provide this option?

    I don't think so. As this Portlet API is so closely related to the Servlet API, it will just spit out its HTML-Code that the portal server is to include in a certain position. Our only options to modify the output will be those options, that portlet providers include in their portlet configuration, maybe some CSS classes that we can define. But there is no standard mechanism to provide the portlet with our own design, the portal design.

    In my opinion this portlet thing leads to the wrong direction. A portal server should only plug in the functionality of a component and should be responsible for the design itself. At least portlets should be forced to define their design in a way, that can be easily modified, like JSPs.
  11. Is it me or is this a step back?[ Go to top ]

    And now we have this portal server that we can plug in portlets to. And these portlets bring with them view AND controller, their functionality WITH THEIR OWN DESIGN. How will we get these portlets to fit into our corporate design portal? Is there some functionality in the spec that will provide this option?

    >

    > I don't think so. As this Portlet API is so closely related to the Servlet API, it will just spit out its HTML-Code that the portal server is to include in a certain position. Our only options to modify the output will be those options, that portlet providers include in their portlet configuration, maybe some CSS classes that we can define. But there is no standard mechanism to provide the portlet with our own design, the portal design.

    I must confess I have similar misgivings. I am working on an application that will also feature a portal, and am undecided about using the new spec. It seems awkward, sort of like an additional layer that is not quite aligned right in terms of easy "leverability".

    So currently, I am much more comfortable implementing portal components using the spec that can be dropped into any compliant container (basically ensuring that components comply or can easily be made compliant to the spec), THAN actually including a portlet-enabled portal with the application.

    > In my opinion this portlet thing leads to the wrong direction. A portal server should only plug in the functionality of a component and should be responsible for the design itself. At least portlets should be forced to define their design in a way, that can be easily modified, like JSPs.

    Not completely sure I get your drift here, but I guess generally agree with you. ;-)

    This spec was a good step forward in making sure that you could design components that you could drop into any compliant portal, and have them work out of the box. That's a good thing.

    But, IMHO, I believe the current spec is better for portlet designers than portal designers. But that's just my opinion. I am sure that these things will resolve themselves in the months to come. Or perhaps with spec version 1.1. 8-)

    Sandeep
  12. Is it me or is this a step back?[ Go to top ]

    You are correct by saying this:
    <quote>
    but in normal J2EE development we are taught that it is good to keep view and controller separate so we divide them up into JSPs and Servlets/EJBs/Other Stuff.
    </quote>

    IMO, the Portlet API has nothing to do with the functionality. It's pure the view.

    Nowadays we have Business Component Models like EJB, etc., so we can develop e.g. stand-alone "Bookmark Business Component", which can be integrated into your own application. We also have Presentation Component Models for Java Applications (Swing, SWT) like JavaBeans: Formular, Frame, Button, TextEdit, etc. To stay within the example of the Bookmark Business Component: we can create a "Bookmark Swing Presentation Component" with a Formular, some TextEdits and maybe some Buttons, which can access our Bookmark Business Component. This Bookmark Swing Presentation Component can be reused everywhere, where you use Swing in your Java Application.

    What we don't have is a real independent Presentation Component Models for xxxML (HTML, WML, cHTML, etc.). OK, we can create an HTML file with some Buttons and TextEdits, develop a Servlet with Struts for the formular and JSP for the view technique. So we get our "Bookmark HTML Presentation Component". The question now is how can we reuse this in our own or other applications?

    -> First difficulties: my application uses another Servlet framework (not Struts). My application uses another view technique (not JSP). How can I reuse that Bookmark HTML Presentation Component in my application then? This question also arises if you have to reuse the Bookmark Swing Presentation Component within other SWT applications ;-) The problem with xxxML Presentation is that you have a lot of choices.

    -> You are correct with the design. Portlet API (or the deployment descriptor) should give you a chance to customize those look&feels.

    -> Portlet is also about the running behaviour of your Presentation Component. How can you define "close", "open", "minimize", "maximize" of your Portlet if you don't have any standard mechanism? You can compare this with a Swing formular. Nowadays it's very easy to write such a Swing formular and integrate them into Plug-Ins in NetBeans for example. Portlets should be similar with that:
    - Swing NetBeans Platform or SWT Eclipse Platform -> extended with Plug-Ins.
    - Portal Platforms -> extended with Portlets.
    Becareful, the seperation of Presentation and Business Component is always there.

    I really hope that Portlet API will tackle all these problems. The idea is just:
    - Write your Bookmark Business Component with any implementations (based on Java interfaces).
    - Write your Bookmark HTML Presentation Component with any implementations (based on Portlet API + Servlet Framework + View Technique).
    - Put them together into ear.
    - Deploy the ear file into a Portal, which is conformed with Portlet API. Edit one or two XML property files before (for Business and Presentation) to customize it into your portal (DataSource, CSS, look&feel, etc.).
    - Voila! You have the Bookmark Portlet (= Bookmark Business Component + Bookmark HTML Presentation Component) running within your portal (just like Plug-Ins for NetBeans and Eclipse)!

    This idea is great, IMO ;-)

    Cheers,
    Lofi.
    http://www.openuss.org
  13. Nice explanation Lofi
  14. Is it me or is this a step back?[ Go to top ]

    <quote>IMO, the Portlet API has nothing to do with the functionality. It's pure the view.</quote>

    You're right, since the Portlet API only defines the Interface to the presentation layer. Everything below that is beyond the scope of the portal server. But I'm not sure, if it must or should be like this. Your example of the ideal portlet development process assumes, that the company that uses a portlet builds it itself. But the promise of the Portlet API, I think, is somewhat different.

    In my opinion, it is: Buy yourself any Portal Server to create your own portal. You want to integrate your Lotus Notes Mail and Calendar into this? Go look, if IBM has Portlets for it. Just plug it in then. Want to have a google integrated? Go look if they have a portlet or anybody has written one to access it. Don't you think, this leads to the picture, that there is no need for developing any more?

    Ok, you may argue, that indeed there is no further need for developing if you go buy that notes mail portlet and plug that into your server. But I am sure, that in almost all cases, that won't do the job, because the design just will not fit into the portal. (Although I really feel silly stating, that the designability of a portlet is a killer feature, I think that is the case. A portal is the "figurehead" of the company and suits wouldn't accept "lotus yellow" in their all blue'n'white portal. There are many subtle ways, in which a portlet visually wouldn't fit into a portal).

    So, in my opinion, the part of the portlet, that the vendor will want to edit, should be in an editable format. I currently think of two possibilities:

    1. "The Component is the Portlet". There is no portlet defining the complete mvc-View but only an "[m]c"-Component that can be easily integrated into any presentation system. It would be a job of the portal server, to allow me easy integration of this component and definition of the layout. I'm sure, that a portal server could make this job so easy, that any HTML designer could do it, without knowing that there is java beyond the surface.

    2. Portlet is forced to present view-Layer in an user-editable format, maybe JSP. Instead of defining, which class in your portlet package is the portlet class, you would define one JSP in there as your "start-JSP". As JSPs are only text, the customer will be able to edit them. And if you embed your functionality in there as tag libraries, he will just see HTML with some additional spooky tags (not as spooky, as embedded java code tho ;). Again a job for any HTML designer.

    I understand that the key argument behind the form of the Portlet API is it's similarity to the servlet API. Since almost every java programmer has worked on servlets sometime in his/her career, we now would have millions of potential portlet developers, right? But again I think, the problems described will come up very quickly when/if really a big market for portal servers and portlets will come up.
  15. Overspecification....[ Go to top ]

    So now we have a cool "portlet specification".

    Will this lead to portable portlets? I don't think so. Portlets are integrated in Portal frameworks that have their own notion of what a controller is, how it
    works and how it is to be designed. You don't even get any good model
    for inter-portlet communication from the specification. A lot of products heavily - and rightly so - on a vast component framework. And so on and so
    on.

    But will it maybe make development easier? How so? Nowadays most portlets are
    JSP snippets using JSP built in vars etc. In the future they are going to
    be JSP snippets usign Portlet built in vars....no big change here.
  16. They have adopted it anyway by way of the "Jakarta Pluto" project on the Apache website.

    I'm just curious.

    Probably no-one cares anyway. :-)