WILY PORTAL MANAGER 5.3.2 RELEASED

Wily Technology today announced general availability of Wily Portal Manager 5.3.2 for IBM WebSphere Portal, supporting IBM WebSphere Portal versions 5.1 or 5.0.2x.

Check the press release here.

Comments

  1. Anonymous2:13 PM

    Hi Punit,

    I posted this back in Weblogic Portal Forums, and I am moving it here because I believe you can get interested in the subject as it concerns enterprise portals in general.

    I am currently implementing a portal on WLP.
    On the other hand, I'm also building a proprietary framework to host several applications for a large institution.
    For the latter, we are using Ajax and solid Javascript development to create a desktop-like visual environment (with reusable components, drag and drop between applications, context menus, dynamic windows, reusable views: list, detail, etc).

    Given the functional contrast (between the portal and the rich application), I am becoming terribly frustrated by the inflexibility of the portal/portlet paradigm, and the innability to incorporate most of these concepts without hacking the specification... it's evident to me that the jsr168, as implemented now, has sacrificed too much in favor of too little (WSRP and portability) and carries with limitations imposed by arguably "obsolete" problems such as client statelessness or the innability to refresh the browser on a per portlet basis.

    One might argue that the latter comes from a commitment to the "no javascript" development philosophy. But, doesn't Weblogic console, Portal admin and even the sample portal use javascript for non-trivial tasks??
    Doesn't everyone??


    With javascript legally forming part of our toolbox, here are some obvious enhancements that come to my mind (which still could be applied without violating the spec):

    - Drag and drop of portlets within a page
    - Lifecycle and State management occuring asynchronously over the wire, for each portlet independently
    - Dynamic invocation of a given portlet with a javascript Api (on demand)
    - Context menu (or similar) used to invoke a relevant portlet (by allowing registration, just like in a shell)

    I am being very conservative here... and yet these features alone would create a dramatically more dynamic user experience without pushing the spec. Plus, we would be able to create lighter portal applications (bye bye unnecessary page reload overhead!).


    Of course portlet state and inter-portlet communication should (or could) then be passed to the visual interface. But, hey, isn't that where it should be? If you think about it, no portlet should allow potentially insecure operations to occurr unchecked, and for this matter, the consumer server environment is as dangerous as the user client environment (if you hold true to the producer-consumer-user paradigm).
    Now, talking about interoperable portlets... how standarized is inter portlet communication anyway?

    And what about mobile and js-disabled souls!!? well, I believe fallback is the word for them.

    Anyway, all this issues should be resolved by the portal container, that's what we are paying for ;)!
    how?... easy: clever, solid javascript and a smart fallback strategy.

    If you feel I'm talking on air here, here's some pretty solid air:

    http://projects.backbase.com/RUI/portal.html
    http://www.google.com/ig

    I am currently experimenting on this issues, but I'm already having conceptual problems with the personalization service and others... (of course, it's all thought for something else).

    Any ideas more than welcome.
    BEA, what do you have in mind?

    Regards,
    Aldo[/nobr]

    ReplyDelete
  2. Anonymous6:11 AM

    IBM provides some dhtml tools in their portal. The problem is, that once you buy into them, you are stuck with a vendor specific implementation. As an individual developer I think the key decision is either a vendor neutral solution or not. Portal standards are not a replacement for a windowing operating system. Ajax is an approach. Maybe it can be incorporated with Portal technology. But to expect it out of the box in a vendor neutral way is naive.

    ReplyDelete
  3. Anonymous10:31 PM

    Hi Punit
    this is Amit, my native place is aligarh.
    i working on a project which involves the use of various technologies like JSF,Portlet JSR 168 on weblogic portal server..etc.

    in a portal page on the left side i have 2 portlet like browse and search and on the right side i want only one portlet should be displayed based on the left side portlet, if have done search then search result portlet should be displayed and if the browse has been used on the left side then the browse result portlet should be displayed .
    for jsf and portlet communication purpose we are using org.apache.portals.bridges.jsf.FacesPortlet .

    how can i do this.

    regards
    Amit Sharma

    ReplyDelete

Post a Comment

Popular posts from this blog

Web Clipping for Portals goes Mainstream

Firebase upgraded properties are not yet supported in Google Analytics App

eXo Portal Merges into JBoss Community