Hi Paul, There's a not very known API that could help you achieve that : $xcontext. setLinksQueryString ; which propagates some query string params to all subsequent requests. So you could have skin=someskin pushed into it. But that might not be what you want (because of URL aesthetics for example). There might be a better way, I think Ludovic is doing something similar in the mobile skin, that could be a lead. Hope this helps, Jérôme Le 27/09/13 13:17, Paul Libbrecht a écrit :

Dear developers,

let me try to re-explain because obviously I don't find support to implement this.

I want the first hit of an xwiki request to decide which skin to take and keep that skin in all subsequent requests. The decision should mostly depend on the browser.

So the questions: - where is the logic that decides to choose a skin or another?

thanks in advance.

paul

Le 13 sept. 2013 à 18:33, Paul Libbrecht a écrit :

...

Ping?? Le 9 sept. 2013 à 23:01, Paul Libbrecht a écrit :

...

Hello fellow developers,

what is the best practice to decide on a skin in the session and not carry it along with the URLs? We are building a mobile UI and it should have more limited functionalities so that the same pages should eb visited by the same users with different skins depending if the device is a mobile or not.

thanks for hints.

Paul

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Oct 6, 2013, at 4:19 PM, Paul Libbrecht <[email protected]> wrote:

thank you Jérôme,

I have gotten bit further there. Thanks to a filter I was able to add the skin parameter when the session could say which skin to use.

This makes the skin: - decided according to the user agent string at the first hit - stored in session and consistent there, even if links do not mention the skin name - changeable by an intentional action of the user (namely: add parameter skin=xxx to change it)

This implemented in: https://github.com/xwiki-contrib/currikiorg/blob/curriki-1-15/plugins/servle...

I would have preferred to write into the xwiki context if I could. But I have not found a way for a filter to be wired in a way that can get the xwiki context. Would there be one?

The context is created by the Struts Servlet (XWikiAction.java) so it does not exist yet when your filter runs. One solution is to move the xwiki context initialization code from XWikiAction to a filter that runs before your filter. We should do this in the platform ideally since it could be useful. You could create a jira issue about it. Thanks -Vincent

thanks in advance.

Paul

Le 27 sept. 2013 à 13:24, Jerome Velociter a écrit :

...

Hi Paul,

There's a not very known API that could help you achieve that : $xcontext. setLinksQueryString ; which propagates some query string params to all subsequent requests. So you could have skin=someskin pushed into it.

But that might not be what you want (because of URL aesthetics for example). There might be a better way, I think Ludovic is doing something similar in the mobile skin, that could be a lead.

Hope this helps, Jérôme

Le 27/09/13 13:17, Paul Libbrecht a écrit :

...

Dear developers,

let me try to re-explain because obviously I don't find support to implement this.

I want the first hit of an xwiki request to decide which skin to take and keep that skin in all subsequent requests. The decision should mostly depend on the browser.

So the questions: - where is the logic that decides to choose a skin or another?

thanks in advance.

paul

Le 13 sept. 2013 à 18:33, Paul Libbrecht a écrit :

...

Ping?? Le 9 sept. 2013 à 23:01, Paul Libbrecht a écrit :

...

Hello fellow developers,

what is the best practice to decide on a skin in the session and not carry it along with the URLs? We are building a mobile UI and it should have more limited functionalities so that the same pages should eb visited by the same users with different skins depending if the device is a mobile or not.

thanks for hints.

Paul

On Sun, Oct 6, 2013 at 5:51 PM, Paul Libbrecht <[email protected]> wrote:

...

...

I would have preferred to write into the xwiki context if I could. But I have not found a way for a filter to be wired in a way that can get the xwiki context. Would there be one?

The context is created by the Struts Servlet (XWikiAction.java) so it does not exist yet when your filter runs. One solution is to move the xwiki context initialization code from XWikiAction to a filter that runs before your filter. We should do this in the platform ideally since it could be useful. You could create a jira issue about it.

Well, our web.xml actually seems to include such a thing org.xwiki.wysiwyg.server.filter.XWikiContextInitializationFilter but I could not read in the source how its output would be profitable to other filters.

This was made for servlets other than the action servlet which is the main servlet serving wiki pages and which initializes itself the context. It is used currently by REST and GWT-RPC servlets. It creates a fake XWiki context (fake because a REST request or a GWT-RPC request doesn't have all the information a /bin/view/ request has for instance) so it wasn't made to be used with the action servlet (that's why this filter is not mapped to the action servlet in web.xml). Hope this helps, Marius

(I expected something such as a thread-local).

paul _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs