Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [skalli-dev] Web-ContextPath other than "/"

Hi Jochen,

not to forget places like FavoritesServlet or StaticContentServlet that call request.getRequestURI() (which contains the web-contextpath, see (http://stackoverflow.com/questions/4278083/how-to-get-request-uri-without-context-path) and then check whether the returned URI starts with some prefix, e.g.

 

public class FavoritesServlet extends HttpServlet {

    …

    public void service(HttpServletRequest request, HttpServletResponse response)

            throws ServletException, IOException {

        String requestURI = request.getRequestURI();

        if (requestURI.startsWith("/favorites")) {

 

 

 

VAADIN/themes/simple:

For the JSPs I could also imagine a solution with a filter that calculates the path once and then sets a request attribute. UserFilter for example is quite similar in the sense that it filters more or less all JSPs to provide the logged in user and user id.

 

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException,  ServletException {

 

        HttpServletRequest httpRequest = (HttpServletRequest) request;

        String contextPath = (httpRequest!= null) ? httpRequest.getSession().getServletContext().getContextPath() : "";

        String themePath = contextPath + Consts.VAADIN_THEMES_SIMPLE;      

        request.setAttribute(“themePath”, themePath);

 

        // proceed along the chain

        chain.doFilter(request, response);

    }

 

and then

 

     <img src="${themePath}/images/logo350x89.png" alt...

 

 

For o.e.s.view/js/toggle.js   we need a separate solution.

 

For the info boxes I’d like to pass the theme path (or a facility that provides it) through getContent(…, ExtensionUtil). ExtensionUtil already delivers  things like the logged in user to the info boxes, and ProjectViewPanel, which creates the ExtensionUtils, has access to the Vaadin application.

 

For Vaadin components like PeopleComponent there are Vaadin mechanisms to access theme resources without knowing the path prefix, but I have to study the documentation again.

 

Your questions:

1.       Vaadin explicitly encourages different themes, so in order to not have another round of refactoring later, it would make sense to have the “simple” part customizable.

2.       I have no experience with context listeners, but I have some feelings about static class holding request params. About how many problematic classes do we actually talk? TagCloud is one of them, but it is used from a JSP, where we have the theme path. Solvable case, methinks.

 

Cheers,

Michael

 

From: skalli-dev-bounces@xxxxxxxxxxx [mailto:skalli-dev-bounces@xxxxxxxxxxx] On Behalf Of Jochen Hiller
Sent: Freitag, 13. Mai 2011 12:03
To: Skalli project developer mailing list
Subject: [skalli-dev] Web-ContextPath other than "/"

 

Hi all,

 

I want to share my ideas and thoughts for supporting web-contextpath other than "/". See also bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=343937

 

I have added a method to o.e.s.view.internal.ViewBundleUtil, which returns either "/VAADIN/themes/simple" (for web-contextpath: "/") or "/mycontextpath/VAADIN/themes/simple" (for web-contextpath: "/mycontextpath"). The HttpServletRequest will be used, to get access to the context of web application.

 

    /**

     * Get the path to Vaadin theming based on current web context.

     * The web context will be taken from a given servlet request.

     * @param req a servlet request. If null, "/" will be assumed for context path

     * @return a path to VAADIN theme path, e.g. "/<contextPath>/VAADIN/themes/simple".

     *   If context path is "/", returns "/VAADIN/themes/simple"

     */

    public static String getVaadinThemesPath(HttpServletRequest req) {

        String contextPath = (req != null) ? req.getSession().getServletContext().getContextPath() : "";

        return contextPath + Consts.VAADIN_THEMES_SIMPLE;

    }

 

I have changed a sample JSP (login.jsp) according:

 

<%@page import="org.eclipse.skalli.view.internal.ViewBundleUtil"%>

...

<img src="<%=ViewBundleUtil.getVaadinThemesPath(request) %>/images/logo350x89.png" alt...

 

 

There are about 20 occurences in JSP files to be changed. No problem.

 

 

I also checked the usage of the /VAADIN/themes/simple path. In Java code I found references in PeopleComponent, ProjectDevInfoBox, SubprojectsInfoBox. All these classes do NOT have a reference to a running web application. 

Another example is TagCloud.java, which uses Const.URL_PROJECTS_TAG ("/projects?tag"). In general, all URLs in Const.java reflects references to URLs generated by Skalli.

 

 

My questions are now:

 

1. Does it make sense, to include the whole path "/VAADIN/themes/simple" (incl. simple) as part of the getVaadinThemesPath()?

Or do you have in mind, that the "simple" part should be customizable?

 

2. How can we handle generation of URLs from classes, which do NOT have a reference to a web application?

To handle a request through all architecture layers does not really make sense.#

We should also aware that we have 2 web-contextpaths: "/" for UI, "/api" for REST based API.

 

I can imagine, that we register a ContextListener (using <listener>...</listener> tag in web.xml, or registering a servlet), which registers the actual web-contextpath in a helper/static class. This can be used then to generate URLs based on the current context path, e.g. an

  URLBuilder.createAPIUrl(String path);

  URLBuilder.createUIUrl(String path);

 

If we agree on such a solution, this can also be used for adapting the JSPs.

 

 

What do you think? This would be a major change, so I would like start a discussion about the best solution.

 

 

Bye, Jochen 


Back to the top