06 September 2005

... just some notes and thoughts on learning Wicket... I will continue updating this page....

  • (-1) The Display Tag from Wicket-examples does not provide exporting table to Excel. The implementation in the example is just fake, you still need to write your own.

  • (-5) Wicket's Component (Page) serves both View and Controller roles in MVC. It is hard to test Controller Logic in isolation. Personally I think this is the major disadvantage of Wicket.

  • (0) All Pages will save into session, so make sure all instance variables of Page are serializable. This also means one should avoid to inject stateless service into the Page. Use lookup instead.

  • (0) Due to above reason, we need to use lookup instead of inject for Spring managed bean. The simplest lookup is write a base WebPage -- WebPageSupport with a method:
    protected static Object getBean(String beanName) {
        WicketServlet ws = ((WebApplication) Application.get())
                .getWicketServlet();
        return WebApplicationContextUtils.getRequiredWebApplicationContext(
            ws.getServletContext()).getBean(beanName);
    }
    
    quite simple ! But with some lookup overhead.... It is easy to refactor to a ServiceLocator that doing some cache.

  • (+3) Wicket provides Markup inheritance out of box. With this, we don't require SiteMesh/Tiles anymore! more powerful and easier! Wow!!

  • (+1) By default, page to page flow are all redirected. No more double-submit-by-REFRESH-button issue !

  • (+1) One can define either global resource.properties for the whole application or local one for custom component. Just name your global resource.properties as your Application class name:
       com.mywicket/MyWebApplication.java
                   /MyWebApplication.properties    //global resource file
    
    It's possible to make every page have it's own resource file, but I think it is too overkill. Only reusable custom component worths it.

  • (+2) Crypted URL -- turn your URL /context/foo/bar/baz... into /context/foo?x=s%kaBAfi1r8pfuasir12113. Just override two methods in your WebApplication:
       protected WebRequest newWebRequest(HttpServletRequest servletRequest) {
    	return new WebRequestWithCryptedUrl(servletRequest);
       }
    
        protected WebResponse newWebResponse(HttpServletResponse servletResponse)
    	throws IOException {
    	return new WebResponseWithCryptedUrl(servletResponse);
       }
    
    And done ! I like this feature very much. It saves lots of time on design/develop for preventing the user to hack/guess the URL. The implementation also shorten the crypted URL smartly. Well, crypted URL is ugly but... hey ! Who care URL for a web application ! It shouldn't be memorable or bookmarkable.

  • (+1) Make component invisible by override isVisible()
        protected boolean isVisible() {
            return mySecurityCheck(....) ;
        }
    
    There is another method checkAccess() can do security check, but I prefer to hide the component if the user does not allow to access it.

to be continue....


回響

可以用 Tag <I>、<B>,程式碼請用 <PRE>