Full page refresh being caused when portlet links are clicked

[Ankur Jaswal, modifié il y a 10 années.]

We are noticing full page refresh when portlet links on the left navigation menu are being clicked. We are using Liferay 6.0 EE SP1, jsf-api-2.1.21 and jsf-impl-2.1.21, Liferay faces 3.0.2-ga3, Icefaces 3.3.0 jars.

liferay-portlet.xml the config for each portlet looks like this

<portlet>
<portlet-name>QBEReport</portlet-name>
<instanceable>true</instanceable>
<header-portlet-css>/resources/css/main.css</header-portlet-css>
<header-portlet-css>/resources/css/custom.css</header-portlet-css>
<footer-portlet-javascript>/resources/js/main.js</footer-portlet-javascript>
</portlet>

portlet.xml looks as below

<portlet>
<portlet-name>QBEReport</portlet-name>
<display-name></display-name>
<portlet-class>org.portletfaces.bridge.GenericFacesPortlet</portlet-class>
<init-param>
<name>javax.portlet.faces.defaultViewId.view</name>
<value>/pages/reports/qbeReport.xhtml</value>
</init-param>
<expiration-cache>0</expiration-cache>
<supports>
<mime-type>text/html</mime-type>
<portlet-mode>view</portlet-mode>
</supports>
<portlet-info>
<title>QBER(BQER)</title>
<short-title>QBE Report</short-title>
<keywords>QBE Report (QBER)</keywords>
</portlet-info>
<security-role-ref>
<role-name>administrator</role-name>
</security-role-ref>
<security-role-ref>
<role-name>guest</role-name>
</security-role-ref>
<security-role-ref>
<role-name>power-user</role-name>
</security-role-ref>
<security-role-ref>
<role-name>user</role-name>
</security-role-ref>
</portlet>

[Neil Griffin, modifié il y a 10 années.]

Hi Ankur,

When you wrote:

left navigation menu

Can you be more specific as to what menu you are referring to?

Also, this is unrelated, but your portlet-class should be:

javax.portlet.faces.GenericFacesPortlet

Instead of:

org.portletfaces.bridge.GenericFacesPortlet

Kind Regards,

Neil

[Ankur Jaswal, modifié il y a 10 années.]

Left navigation menu is the menu on the left side that is created using Liferay templates and structures (pls see the attached image, the Account Manager link on the left is part of the Left Navigation menu, its a link to a page where the portlet is dropped)

I think the problem is being caused by the configuration below in the portal-ext.properties

request.shared.attributes=REQUEST_SHARED_

when we comment out this property the the full page refresh does not happen but the ace components of iceface like ace:dataTable etc do not work. When we uncomment the ace components work but the full page refresh happens

Thanks for pointing the javax.portlet.faces.GenericFacesPortlet that was a typo I changed in some of the portlets and missed a few.

[Neil Griffin, modifié il y a 10 années.]

Do portlet links on the left navigation menu point to anchor positions on the same portal page, or to different portal pages?

[Ankur Jaswal, modifié il y a 10 années.]

They point to the same portals page.

[Neil Griffin, modifié il y a 10 années.]

When you get a chance, please paste:

1. The current URL you see in the browser

2. An example href value of one of the links in the menu

I would need to see this for scenario A (request.shared.attributes is set) and scenario B (request.shared.attributes is not set).

[Ankur Jaswal, modifié il y a 10 années.]

This is from the log

com.liferay.faces.bridge.container.liferay.PortletContainerLiferayImpl (PortletContainerLiferayImpl.java:118) - Detected Liferay build number 6011
[25.06.2013] [09:43:57] DEBUG [http-8080-10] com.liferay.faces.bridge.container.liferay.PortletContainerLiferayImpl (PortletContainerLiferayImpl.java:166) - User-Agent requested URL=[http://yourtickettowork-dev.maximus.com:8080/group/enportal/earnings-report?p_p_id=QBEReport_WAR_EnPortalportlet_INSTANCE_aAx7&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-2&p_p_col_count=1&_QBEReport_WAR_EnPortalportlet_INSTANCE_aAx7_javax.faces.resource=themes%2Fsam%2Fimages%2Fui-icons_222222_256x240.png&_QBEReport_WAR_EnPortalportlet_INSTANCE_aAx7_ln=icefaces.ace]
[25.06.2013] [09:43:57] DEBUG [http-8080-9] com.liferay.faces.bridge.container.liferay.PortletContainerLiferayImpl (PortletContainerLiferayImpl.java:166) - User-Agent requested URL=[http://yourtickettowork-dev.maximus.com:8080/group/enportal/earnings-report?p_p_id=QBEReport_WAR_EnPortalportlet_INSTANCE_aAx7&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-2&p_p_col_count=1&_QBEReport_WAR_EnPortalportlet_INSTANCE_aAx7_javax.faces.resource=themes%2Fsam%2Fimages%2Fui-default.png&_QBEReport_WAR_EnPortalportlet_INSTANCE_aAx7_ln=icefaces.ace]
[25.06.2013] [09:43:57] DEBUG [http-8080-11] com.liferay.faces.bridge.BridgePhaseResourceImpl (BridgePhaseResourceImpl.java:145) -

Below is an example of a page that this linked from the Left navigation menu

[Ankur Jaswal, modifié il y a 10 années.]

do you have any idea about behavior related to this property request.shared.attributes=REQUEST_SHARED_ that I mentioned earlier ?

[Neil Griffin, modifié il y a 10 années.]

Thanks for taking time to post your recent comments. I think I need to be more clear about what I am asking for though.

In order to help me determine what impact request.shared.attributes is having, please follow these steps:

Scenario A:

1. Shutdown the server
2. Set the following in portal-ext.properties
request.shared.attributes=REQUEST_SHARED_
3. Start the server
4. Using Chrome, navigate to http://yourtickettowork-dev.maximus.com:8080/group/enportal/account-manager
5. When you see the menu on the left, right-click on the hyperlinks that is supposed to display a portlet, and click on "Inspect Element"
6. Copy the value of the href attribute of the link and paste it here in this forum thread

Scenario B:

1. Shutdown the server
2. Comment-out the following in portal-ext.properties
request.shared.attributes=REQUEST_SHARED_
3. Repeat steps 3-6

I basically want to compare the URLs from step 6 in Scenario A and Scenario B.

[Ankur Jaswal, modifié il y a 10 années.]

Thanks for replying - sorry that I did not quite catch what you requested. Here is what you asked for

With request.shared.attributes=REQUEST_SHARED_
<a href="/group/enportal/account-manager" id="aui_3_2_0_1418">- Account Manager</a>

without request.shared.attributes=REQUEST_SHARED_
<a href="/group/enportal/account-manager" id="aui_3_2_0_1460">- Account Manager</a>

[Neil Griffin, modifié il y a 10 années.]

Hi Ankur,

OK, it looks like the links are the same.

Going back to your original statement of the problem:

We are noticing full page refresh when portlet links on the left navigation menu are being clicked.

When I consider a link like this:

<a href="/group/enportal/account-manager" id="aui_3_2_0_1418">- Account Manager</a>

I would expect a full page refresh, because clicking on the link is asking for the user-agent (browser) to invoke an HTTP GET on the URL.

If it should not invoke an HTTP GET, then what is the behavior that you are expecting?

Thanks,

Neil

[Ankur Jaswal, modifié il y a 10 années.]

The question is then why does not the full page refresh happen when request.shared.attributes=REQUEST_SHARED_
is commented in portal-ext.properties ?

[Neil Griffin, modifié il y a 10 années.]

I don't know the answer to that -- but I do have some things I can ask you to try that might help lead us to an answer.

Please try the following steps for both Scenario A and Scenario B:

1. Using Chrome, navigate to http://yourtickettowork-dev.maximus.com:8080/group/enportal/account-manager
2. Click on on View->Developer->Developer Tools
3. Click on the "Network" tab
4. Click on the "Clear" button in order to clear the history of past requests (looks like a circle with a slash through it)
5. Click on the "Account Manager" link in your left side menu
6. If Chrome reports a request, then click on the row representing the request in the "Network" tab
7. Copy all the text from under the "Headers" tab and paste it here

[Ankur Jaswal, modifié il y a 10 années.]

With request.shared.attributes=REQUEST_SHARED_

Request URL:http://yourtickettowork-dev.maximus.com:8080/group/enportal/account-manager
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:LFR_SESSION_STATE_42707=1372193636204; COOKIE_SUPPORT=true; ice.connection.contextpath=.; ice.connection.lease=1372193345255; JSESSIONID=F41ECBD6E640605BF753AD705B528CBF; COMPANY_ID=11601; ID=4e39466b66513356346b633d; PASSWORD=586e6a33556e75476e6e3637373645475a45355343773d3d; LOGIN=756a6a77616c63686f776468757279406d6178696d75732e636f6d; SCREEN_NAME=507544466f69754b5a4e513d; GUEST_LANGUAGE_ID=en_US
Host:yourtickettowork-dev.maximus.com:8080
If-None-Match:"5ae23d2e"
Referer:http://yourtickettowork-dev.maximus.com:8080/group/enportal/payment-request
User-Agent:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
Response Headersview source
Content-Encoding:gzip
Content-Length:9819
Content-Type:text/html;charset=UTF-8
Date:Tue, 25 Jun 2013 20:55:15 GMT
ETag:"35accda2"
Liferay-Portal:Liferay Portal Enterprise Edition 6.0 EE SP1 (Bunyan / Build 6011 / January 13, 2011)
Server:Apache-Coyote/1.1

Will post the header without request.shared.attributes=REQUEST_SHARED_ soon

[Ankur Jaswal, modifié il y a 10 années.]

Without request.shared.attributes=REQUEST_SHARED_

Request URL:http://yourtickettowork-dev.maximus.com:8080/group/enportal/account-manager
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Cookie:LFR_SESSION_STATE_42707=1372194344128; COOKIE_SUPPORT=true; ice.connection.contextpath=.; ice.connection.lease=1372193345255; JSESSIONID=F41ECBD6E640605BF753AD705B528CBF; COMPANY_ID=11601; ID=4e39466b66513356346b633d; PASSWORD=586e6a33556e75476e6e3637373645475a45355343773d3d; LOGIN=756a6a77616c63686f776468757279406d6178696d75732e636f6d; SCREEN_NAME=507544466f69754b5a4e513d; GUEST_LANGUAGE_ID=en_US
Host:yourtickettowork-dev.maximus.com:8080
If-None-Match:"f4fbaa10"
User-Agent:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
Response Headersview source
Content-Encoding:gzip
Content-Length:10438
Content-Type:text/html;charset=UTF-8
Date:Tue, 25 Jun 2013 21:13:53 GMT
ETag:"17cbf191"
Liferay-Portal:Liferay Portal Enterprise Edition 6.0 EE SP1 (Bunyan / Build 6011 / January 13, 2011)
Server:Apache-Coyote/1.1

[Neil Griffin, modifié il y a 10 années.]

With request.shared.attributes=REQUEST_SHARED_ I see this:

Referer:http://yourtickettowork-dev.maximus.com:8080/group/enportal/payment-request

But when request.shared.attributes is commented-out, I don't see a "Referer" entry.

Question: When you conducted the tests, did you start out on the following URL for both scenarios?
URL:http://yourtickettowork-dev.maximus.com:8080/group/enportal/account-manager

The presence of the "Referer" indicates that the first test was conducted on the payment-request page.

[Ankur Jaswal, modifié il y a 10 années.]

For the second test I just hit the URL http://yourtickettowork-dev.maximus.com:8080/group/enportal/account-manager
directly as it was already there in the browser. I will do the test again and paste both

[Ankur Jaswal, modifié il y a 10 années.]

With request.shared.attributes=REQUEST_SHARED_

Request URL:http://yourtickettowork-dev.maximus.com:8080/group/enportal/account-manager
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:LFR_SESSION_STATE_42707=1372196983360; COOKIE_SUPPORT=true; JSESSIONID=968BA2DF01E4AE1DBE9B2C0B9FFE24D9; COMPANY_ID=11601; ID=4e39466b66513356346b633d; PASSWORD=586e6a33556e75476e6e3637373645475a45355343773d3d; LOGIN=756a6a77616c63686f776468757279406d6178696d75732e636f6d; SCREEN_NAME=507544466f69754b5a4e513d; GUEST_LANGUAGE_ID=en_US
Host:yourtickettowork-dev.maximus.com:8080
If-None-Match:"d0d34c8"
Referer:http://yourtickettowork-dev.maximus.com:8080/group/enportal/home
User-Agent:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
Response Headersview source
Content-Encoding:gzip
Content-Length:9821
Content-Type:text/html;charset=UTF-8
Date:Tue, 25 Jun 2013 21:52:30 GMT
ETag:"169e8c12"
Liferay-Portal:Liferay Portal Enterprise Edition 6.0 EE SP1 (Bunyan / Build 6011 / January 13, 2011)
Server:Apache-Coyote/1.1


Without request.shared.attributes=REQUEST_SHARED_

Request URL:http://yourtickettowork-dev.maximus.com:8080/group/enportal/account-manager
Request Method:GET
Status Code:200 OK
Request Headersview source
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie:LFR_SESSION_STATE_42707=1372197872267; COOKIE_SUPPORT=true; JSESSIONID=380FA3272D8D38BA807536E9C3EAF8B8; COMPANY_ID=11601; ID=4e39466b66513356346b633d; PASSWORD=586e6a33556e75476e6e3637373645475a45355343773d3d; LOGIN=756a6a77616c63686f776468757279406d6178696d75732e636f6d; SCREEN_NAME=507544466f69754b5a4e513d; GUEST_LANGUAGE_ID=en_US
Host:yourtickettowork-dev.maximus.com:8080
If-None-Match:"169e8c12"
Referer:http://yourtickettowork-dev.maximus.com:8080/group/enportal/home
User-Agent:Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
Response Headersview source
Content-Encoding:gzip
Content-Length:10416
Content-Type:text/html;charset=UTF-8
Date:Tue, 25 Jun 2013 22:06:25 GMT
ETag:"d14af907"
Liferay-Portal:Liferay Portal Enterprise Edition 6.0 EE SP1 (Bunyan / Build 6011 / January 13, 2011)
Server:Apache-Coyote/1.1

[Neil Griffin, modifié il y a 10 années.]

Hi Ankur,

Thanks for doing the tests again. The results indicate that an HTTP GET is being issued by the browser in both scenarios. The only difference that seems significant to me is that the Content-Length is different. So I would recommend that you repeat the tests exactly the same way again, but this time capture the text from the "Response" tab in the Chrome Developer Tools window. If you pretty-print the HTML in each response and then do a "diff" to compare them, then it might reveal what is different in the response for the two seemingly identical requests.

Neil

[Ankur Jaswal, modifié il y a 10 années.]

One thing is sure though that HTTP GET request to the portal does not necessarily cause a full page refresh

[Neil Griffin, modifié il y a 10 années.]

Hi Ankur,

In a normal situation, whenever an HTTP GET is issued for a portal page, an entire HTML document is returned to the browser, and it is the job of the browser to render the markup accordingly. Perhaps this is not a normal situation. I'm interested to know "diff" results of the two responses.

Neil

[Ankur Jaswal, modifié il y a 10 années.]

We are using these portlets in UAT and production with iceface 1.8.2 using jsf 1.2. The portlets are always being invoked the same way (clicking the link on the Left Navigation Menu) we have never had these problem. I just now saw the request header and its a GET and no page refresh as expected in a portal environment. Only after upgrading we are noticing this issue

I am gathering the reponses

[Ankur Jaswal, modifié il y a 10 années.]

seeing lots difference using the unix diff tool. The text staring with the < is from the response for "with shared.request.attributes" and text starting > is for "without .."

[samuel tian, modifié il y a 10 années.]

RE: Full page refresh being caused when portlet links are clicked

[Neil Griffin, modifié il y a 10 années.]

Do you have any custom request attributes that you set in your portlets that begin with the "REQUEST_SHARED_" prefix?

[Ankur Jaswal, modifié il y a 10 années.]

No. I just enabled the request.shared.attributes=REQUEST_SHARED_
property to find that the full page refresh does not happen when it is there. However, the iceface components, as I mention earlier in the thread, do not display correctly when the property request.shared.attributes=REQUEST_SHARED_ is there and does display properly (with full page refresh) when the property request.shared.attributes=REQUEST_SHARED_
is commented out in the portal-ext.properties

[Ankur Jaswal, modifié il y a 10 années.]

Icefaces sample portlet for liferay the showcase-portlet also behave the same way when I try with liferay faces 3.0.2-ga3 jars

[Neil Griffin, modifié il y a 10 années.]

The default value in portal.properties is the following:

request.shared.attributes=LIFERAY_SHARED_

Do you have a requirement to set it to a different value?

[Ankur Jaswal, modifié il y a 10 années.]

we do share attributes but they do not have to be prefixed with REQUEST_SHARED_, basically we can remove the config request.shared.attributes=REQUEST_SHARED_. But the biggest thing is the portlets have to work without full page refresh using iceface 3.3 and liferay faces 3.0.2-ga3 or we cannot upgrade

[Neil Griffin, modifié il y a 10 années.]

Hi Ankur,

OK I think I understand now. I was under the assumption that you had a requirement set the value of the request.shared.attributes property. If it is OK with you, then from this point on I would like to discuss this issue without mentioning request.shared.attributes=REQUEST_SHARED_

It seems to me that the browser is behaving correctly, meaning, when clicking on a link in the menu, the browser issues an HTTP GET and fully re-renders the portal page.

Just to make sure I understand your issue correctly, you are saying that when the ICEfaces 1.8 version of the portlet is on the page (instead of the ICEfaces 3.3 version), then the page does not fully re-render when the menu link is clicked?

Neil

[Ankur Jaswal, modifié il y a 10 années.]

I dont think browser is behaving correctly - a full page refresh is not the behavior expected in portal environment.

If you are saying the GET will always do full page refresh why is it not refreshing currently and why does not it refresh if we add the property shared.request.attributes - it should refresh all the time when you use GET right ?

Again if GET always refreshes what other HTTP protocol you expect to be used by liferay to get the page so that the full page refresh do not happen.

[Neil Griffin, modifié il y a 10 années.]

Hi Ankur,

Regarding your question about HTTP GET:

It depends on the type of URL that the browser is requesting. When a browser issues an HTTP GET request for a portal page like the following:

http://yourtickettowork-dev.maximus.com:8080/group/enportal/account-manager

Then the response will be an entire HTML document, and will render the HTML in the browser if the return status code is HTTP 200 (OK)

When a browser issues an HTTP GET request for a portlet ResourceURL, then the response will be whatever the GenericPortlet.serveResource(ResourceRequest, ResourceResponse) method returns. In the case of a JSF 2 Ajax request, it is typically a small XML document that contains a partial-response that updates small regions of the DOM.

Regarding your question about request.shared.attributes, here is the documentation and the default value from portal.properties:

    #
    # Portlets that have been configured to use private request attributes in
    # liferay-portlet.xml may still want to share some request attributes. This
    # property allows you to configure which request attributes will be shared.
    # Set a comma delimited list of attribute names that will be shared when the
    # attribute name starts with one of the specified attribute names. For
    # example, if you set the value to "hello_,world_", then all attribute names
    # that start with "hello_" or "world_" will be shared.
    #
    request.shared.attributes=LIFERAY_SHARED_

If you want to set a custom value for the request.shared.attributes property, the documentation states that it must be a comma delimited list, like this:

request.shared.attributes=LIFERAY_SHARED_,REQUEST_SHARED

I tried to reproduce your problem with the icefaces3-portlet with the following value:

request.shared.attributes=REQUEST_SHARED

When I tried it, the icefaces3-portlet didn't render correctly because internal Liferay Portal request attributes prefixed with LIFERAY_SHARED_ were no longer shared. Additionally, it was missing resources and Chrome reported 16 JavaScript failures on the initial load of the page. If Chrome reports JavaScript errors for you too, then that might explain why ace:dataTable wasn't working.

Kind Regards,

Neil

[Ankur Jaswal, modifié il y a 10 années.]

It might be the way I added the portlet to an existing page, let me create a new page and add the portlet and see gets called differently

[Ankur Jaswal, modifié il y a 10 années.]

I created a new page added the portlet - its still happens.

Regarding your question earlier question - I tried the showcase-portlet - that also shows the same behavior. I will attach the one that I am using - it is using liferay faces 3.0.2-ga3 and iceface 3.3.

[Neil Griffin, modifié il y a 10 années.]

Hi Ankur,

When you wrote:

I tried the showcase-portlet - that also shows the same behavior

What behavior do you refer to? Do you mean that an HTTP GET is issued by the browser and the page is fully re-rendered?

Are you setting the value of when you try it with the request.shared.attributes=REQUEST_SHARED showcase-portlet.war?

Neil

[Ankur Jaswal, modifié il y a 10 années.]

when you said "When a browser issues an HTTP GET request for a portlet ResourceURL, then the response will be whatever the GenericPortlet.serveResource(ResourceRequest, ResourceResponse) method returns. In the case of a JSF 2 Ajax request, it is typically a small XML document that contains a partial-response that updates small regions of the DOM." this is how the page should be invoked when page if configured (pls see image) and is not happening I think. Is the bridge (faces bridge) causing this ? If you notice the page type is portlet and the url that browser calls is a Friendly url so it I assume will be converted to the real one (Resource URL) by liferay

[Neil Griffin, modifié il y a 10 années.]

Hi Ankur,

When you wrote:

this is how the page should be invoked when page if configured (pls see image) and is not happening I think. Is the bridge (faces bridge) causing this ? If you notice the page type is portlet and the url that browser calls is a Friendly url so it I assume will be converted to the real one (Resource URL) by liferay

The screenshot you provided shows a very normal/typical setup for a portal page that contains portlets. There is nothing on that screen that would indicate any special functionality like invoking the page with a ResourceURL. The friendlyURL does not get mapped to a ResourceURL, rather it is simply an alias for a portal page URL.

I would recommend that you study what happens with ICEfaces 1.8 in your legacy system, and see how the request info differs, and/or how the response differs.

Kind Regards,

Neil

[Ankur Jaswal, modifié il y a 10 années.]

can you please tell me how to configure a liferay page to access portlet so that the portlet gets invoked as a Resource URL request ?

[Neil Griffin, modifié il y a 10 années.]

Do you mean something like the way Liferay does it when a portlet is added to the page dynamically with the "Add Application" menu?

[Ankur Jaswal, modifié il y a 10 années.]

Does not matter.

I am trying to understand the behavior of my older portlets (jsf 1.2, iceface 1.8.2 and the old portlet bridge that comes with liferay) that do not do full page refresh. Or may be there is something wrong in the way we are coding our jsf 2 portlets.

[Ankur Jaswal, modifié il y a 10 années.]

Hi Neil,

Found the problem - its our code. We were calling <icecore:config mandatoryResource="all"/> at the top of the page - this was causing the full page refresh. As soon as I removed it the full page refresh does not happen.

Thanks for all your help and support man !!

[Neil Griffin, modifié il y a 10 années.]

My pleasure Ankur. Glad you got it working.