-
1. Re: 'Ajax in GateIn Framework' and 'Partial refresh'?
theute Feb 16, 2010 7:40 AM (in response to leolo)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.
-
2. Re: 'Ajax in GateIn Framework' and 'Partial refresh'?
leolo Feb 18, 2010 10:53 AM (in response to theute)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
-
3. Re: 'Ajax in GateIn Framework' and 'Partial refresh'?
andrea.moron Feb 18, 2010 11:42 AM (in response to theute)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
-
4. Re: 'Ajax in GateIn Framework' and 'Partial refresh'?
leolo Feb 24, 2010 10:07 AM (in response to andrea.moron)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
-
5. Re: 'Ajax in GateIn Framework' and 'Partial refresh'?
plamarque Feb 24, 2010 10:18 AM (in response to leolo)You're right LeoLo. This is only true for the WebUI framework.