'Ajax in GateIn Framework' and 'Partial refresh'?

[leolo]

Hi!

1.

JBoss Portal has the proprietary feature "partial portlet-window refresh" http://docs.jboss.com/jbportal/v2.7.1/referenceGuide/html_single/#d0e13308.

Will this feature be merged into GateIn?

2.

Chapter 11.2 of GateIn-Doc deals with "AJAX in GateIn Framework".  http://docs.jboss.com/gatein/portal/3.0.0-Beta02/user-guide/en-US/html/ch11.html#d0e6653

Is the described functionality available only with the use of WebUI-Framework? What if I want to use JSF?

Regards,

LeoLo

[theute]

Hardy,

there is no direct equivalent to the partial-refresh switch that was available in JBoss Portal.

The point 2 is really about using Ajax from a portlet, so that's a different use case.

What I would recommend for your JSF application is to use RichFaces components to use Ajax from the portlet itself.

A direct equivalent to partial-refresh in GateIn isn't on the roadmap, it had severe limitations when Portlet 2.0 got introduced (because of events and public render parameters). If you have ideas and time to implement a more solid alternative for GateIn, that would be great

Thomas.

[leolo]

Hi Thomas,

so since there is no equivalent to the partial-refresh in GateIn, do you see a solution for the following use-case in GateIn?

Usecase: "The user clicks a button in a RichFaces-component in Portlet A and Portlet B (or parts of it) will be updated and newly rendered. A third portlet C on that page won't update itself and won't fulfill a render-request."

AFAIK, I can't do this with JSR-286. Do I miss something?

Regards,

LeoLo

[andrea.moron]

I don't know if I'm getting this right. But some time ago read  this eXo article. It says

eXo Portal 2.0 is also a full AJAX portal, which means that when you move from one page to another only a part of the screen is refreshed. To do so, we use the JavaScript XMLHttpRequest object to call the server asynchronously each time a page is changed or the content of one or several portlets in the page have to be modified (as in the case when one portlet sends a message to another one using JSR 286 standard calls). This of course greatly improves the server calls since, unless events are sent, only one render() is necessary. This is contrast to the normal use case in which every portlet has to render its fragment, which takes much more time (even if it is cached).

At each request, the portal returns an XML file that wraps all of the different HTML fragments which are to be updated in the page. The structure of that XML file is:

 * {PortalResponse}
  *      |
  *      |--->{PortletResponse}
  *      |
  *      |--->{PortletResponse}
  *      |          |-->{portletId}
  *      |          |-->{portletTitle}
  *      |          |-->{portletMode}
  *      |          |-->{portletState}
  *      |          |
  *      |          |-->{PortletResponseData}
  *      |                 |
  *      |                 |--->{BlockToUpdate}
  *      |                 |         |-->{BlockToUpdateId}
  *      |                 |         |-->{BlockToUpdateData}
  *      |                 |
  *      |                 |--->{BlockToUpdate}
  *      |
  *      |--->{PortalResponseData}
  *      |      |
  *      |      |--->{BlockToUpdate}
  *      |      |         |-->{BlockToUpdateId}
  *      |      |         |-->{BlockToUpdateData}
  *      |      |
  *      |      |--->{BlockToUpdate}
  *      |
  *      |--->{PortalResponseScript}

The server response contains 3 types of XML:

• one for the portal components fragment, included in the <PortalResponseData> tag -- this also wraps the ID of the component to update
• one for each portlet fragment to update -- this also wraps portlet information such as the window state and portlet modes to update. Portlets that are aware of eXo Portal 2.x AJAX feature can also tell the portal which HTML tags to directly update to avoid a full portlet refresh (which is mandatory for fully compliant JSR 286 portlets)
• The JavaScript code which does dynamic evaluation, so that it is available in the new generated page

Is this still valid in GateIn?

Thanks

Andrea

[leolo]

andrea wrote:

> Is this still valid in GateIn?

good question. Maybe someone can throw light on this.

Sounds to me, like this is only available, if one uses WebUI-framework,

regards,

LeoLo

[plamarque]

You're right LeoLo. This is only true for the WebUI framework.