5 Replies Latest reply on Jul 26, 2009 4:43 AM by vladimir.kovalyuk

    analyzing the wicket project in the Seam 2.1 distro

    asookazian

      So this is the first time I've looked at the wicket booking app.  Lots of questions...


      It seems every wicket HTML page has a backing class (seems similar to ASP.NET code-behind files).  Is this a hard requirement with wicket views?  That class must extend org.apache.wicket.markup.html.WebPage and must not be a SFSB.  Is this correct?


      how to use a dataTable in Wicket?  the below html snippet in main.html is very ugly/lengthy in comparison to the JSF/RF equivalent.


      The usage of inner classes in classic JSF/RF/Seam/EJB3 development is somewhat foreign and generally unused.


      So somebody plz explain how the dataTable population works. 


      I see

      private WebMarkupContainer hotels;

      in the Main.java.


      <table id="hotels">
                <thead>
                     <tr>
                          <th>
                               Name
                          </th>
                          <th>
                               Address
                          </th>
                          <th>
                               City, State
                          </th>
                          <th>
                               Zip
                          </th>
                          <th>
                               Action
                          </th>
                     </tr>
                </thead>
                <tbody>
                     <tr wicket:id="hotel">
                          <td>
                               <span wicket:id="hotelName">[name]</span>
                          </td>
                          <td>
                               <span wicket:id="hotelAddress">[address]</span>
                          </td>
                          <td>
                               <span wicket:id="hotelCityStateCountry">[city, state, country]</span>
                          </td>
                          <td>
                               <span wicket:id="hotelZip">[zip]</span>
                          </td>
                          <td>
                               <a wicket:id="viewHotel">View Hotel</a>
                          </td>
                     </tr>
                </tbody>
           </table>



      After perusing the entire class, this seems more complicated than JSF/RF but perhaps wicket does not have the life cycle getter/setter multiple-calls problem that JSF has.


      Instead of using just one backing bean (e.g. one SFSB) for your view/facelet, now there is an additional class.


      What exactly is/are the advantage(s) of using wicket with Seam?  How bout the disadvantages?

        • 1. Re: analyzing the wicket project in the Seam 2.1 distro
          vladimir.kovalyuk

          I would encourage you to buy and read Wicket in Action book instead of looking at Seam vision of Wicket. Wicket is far supperior framework comparing to JSF. Seam and JSF screws up your OOD when Wicket encourages you to do your best with OOD.



          It seems every wicket HTML page has a backing class (seems similar to ASP.NET code-behind files). Is this a hard requirement with wicket views? That class must extend org.apache.wicket.markup.html.WebPage and must not be a SFSB. Is this correct?

          That's correct in general. Particularly any panel and page may not introduce its markup file (.html part) if the backing class does not add components (say just override isVisible() method from the superclass). It comes in handy for ananymous classes like instance of Link that should override onClick() method.



          how to use a dataTable in Wicket? the below html snippet in main.html is very ugly/lengthy in comparison to the JSF/RF equivalent.

          I don't know why the sample is so verbose. The regular markup for DataTable is the following:



          <table class="dataview" cellspacing="0" wicket:id="table">[table]</table>


          columns.add(new PropertyColumn(new Model("First Name"), "firstName", "firstName"));
          
                  columns.add(new PropertyColumn(new Model("Last Name"), "lastName", "lastName");
                  columns.add(new PropertyColumn(new Model("Home Phone"), "homePhone"));
                  columns.add(new PropertyColumn(new Model("Cell Phone"), "cellPhone"));
          
                  add(new DefaultDataTable("table", columns, new SortableContactDataProvider(), 8));
          



          Have a look at DataTable sample



          After perusing the entire class, this seems more complicated than JSF/RF but perhaps wicket does not have the life cycle getter/setter multiple-calls problem that JSF has.

          That's not correct due to strange Seam sample. Wicket does not have many problems that JSF has not only getters/setters. It has more thoughtout request lifecycle that allows you naturally mount urls to pages instead of using ugly urlrewrite. The list is pretty long. But for now there aren't so much components. From the other hand you can use YUI and jQuery.



          Instead of using just one backing bean (e.g. one SFSB) for your view/facelet, now there is an additional class.

          Tiering models are the same for Wicket and Seam. Yep you can have one class less with JSF+Seam but you will pay for that when your application grows. The problem is that you don't know the price for now. But the price of having simple java class for backing markup is very cheap (it event isn't worth words I'm typing here). And it is proven since you have separation of concerns. You also have separation of markup and how it is constructed. So it gives you possibility to dinamically decide how to fill it in. The same is pretty cumbersome for JSF and faults with Facelets when you mix parsing and rendering time expressions (that was the reason I moved to opposition to JSF).



          What exactly is/are the advantage(s) of using wicket with Seam? How bout the disadvantages?

          - Wicket is far faster that JSF (while my pages became twice as complex they are rendered one seconds. I don't know how much. It just present me a page when I click so I did't have to think :) Ajax response is even more faster comparing to RF.


          - Wicket generates 3 times shorter html for my pages comparing to JSF/Richfaces implementation. I can use divs instead of wide spread tabs in Richfaces and Icefaces - it allows client browser to render page more quicker. Richfaces produces too verbose output. The css and js files are not cached by browser. It makes response appearing within 3 seconds with RF when I have it immediately with Wicket.


          - Wicket pages really suppor backbuttoning, multiple browser tabs and windows. You don't believe. It just works (and should, it is easy to figure out how).


          - Wicket has simple and robust AJAX engine. It has html fallback version of components. For instance you can have AjaxButton that works  as
          simple submit if the client browser has Javascript switched off.


          - Wicket components can be written 100 times faster. The user can start writing components after two hours of reading mentioned book. I could. I designed property editor panel with the label component and input editor choosen by the property type. It was ten times simpler and readable than Facelets version. Don't tell me JSF 2 has a new model for Components. Facelets is evil in my experience.


          - Wicket takes into account client locale and timezone.


          - Wicket is very good for the model where you separate work of Web Java developers and Web designers. That doesn't mean that they work together all the time. It means Web designer really could help Java developers.


          - Wicket is very good for Java developers because it allows to employ OOD practices as you wish. If it sounds simple think about why engineers invented OOD. To overcome growing complexity. So it is the logically that JSF/Seam applications (that can't use the best of OOD just a few) will eventually fail when Wicket application will continue to grow being controlled.


          - With Wicket you have control over all HTTP protocol. Say you can manage how long page should be cached. You can decide what you render as the response - redirect to the page or the page itself.


          - You don't need Seam conversations or pageflows with Wicket. You can organize pages in whatever manner. You can know what page was redirecting to this page and let the user return back. You don't have to split exception handling to request processing time and rendering time so you can easily employ Open Session in View technique. You don't need to map your data to contexts. You just put your data to Component, Page or Session. If you have conversation create a Java class for it. When you don't need it anymore the data will be garbage collected.


          - You have a great support from IDE when refactoring code since it is more java than XML. Generating constants for component ids is planning for Wicket 1.5. So you will have full refactoring support.


          - Wicket provides you with well-thought exception handling. You never loos the exception. You never loss messages between requests.


          - It is easy to debug Wicket applications. You have ajax control panel on the page and several debugging and tracing options. Your contexts are always at hands so you can use all your java debugger capabilities.


          - You really can write dynamically rendered components and pages. Wicket-RAD is the example. You just put property grid or object-list panels onto your page and that's it.


          - Wicket has such a great mechanism as behaviors. You can design your functionality as a behavior and add it to the component instead of subclassing it. So you can build your components from re-usable parts. Wicket ajax engine is mostly built as behaviours so you can add ajax capabilities for your custom components with ease. But this skill requires deep understanding of Wicket :)


          - Many cases where I used workaround for JSF, Richfaces or Seam degraded to one line of code for Wicket. It seems that Wicket is done by people who know how to design frameworks :)


          The disadvantages are the following:


          - Lack of well-tested reusable components, especially layout components. You can employ jQuery plugins or use one of the wicket stuff projects.
          - Lack of native IDE support. But it is not so demanded as in case of JSF/Seam.
          - Wicket don't have Excel, PDF and Mail integration as Seam provides out of the box. But fairly speaking Seam's implementation is not that I would like to see. I find it good for very simple cases. So eventually I had to switch to different integrations. From the other hand it is easy to handle the request as the resource request (for instance as download link) and when handling render XML and then convert use some OSS library to convert XML to Excel or PDF (XHTML is XML) and return the resulted file as the resource for the resource request.


          My opinion is JSF and Seam are not for sophisticated applications but for application (probably consisting of many pages) that is made in very simple manner using copy-paste technique. So it is very easy to start with Seam and JSF. Wicket is for robust sophisticated applications.
          Think about how your application will grow in the future and decide.


          I see some trend in OSS projects. They consider Wicket or GWT. JSF is too painfull. Concerning JSF in OSS ... I have an example. I has been trying to evaluate Nuxeo EP every quarter. It fails after ten clicks. You have to logout and login again in order to continue (as usual, after exception some Seam session components are broken, Seam and incapsulation are ortogonal things). I have never seen a stable version of Nuxeo to suggest for production. The symphoms are very familiar. I saw them too much in my application. BTW Nuxeo uses sole Seam conversation for all the pages in session. It must mean something. Alfresco is stable. And it allows you to write Wicket UI for it.

          • 2. Re: analyzing the wicket project in the Seam 2.1 distro
            asookazian

            I actually do have the WiA book but I also have dozens of other books.  I will make it a priority, however, to start reading WiA, sounds interesting and I know PMuir is a major Wicket advocate.


            You have made some comments that are borderline offensive and/or I don't completely agree with:


            1) My opinion is JSF and Seam are not for sophisticated applications but for application (probably consisting of many pages) that is made in very simple manner using copy-paste technique.


            From what I can tell, this is a sophisticated app: http://jsfcentral.com/articles/speed_up_your_jsf_app_1.html


            And what about Seam remoting, jBPM integration and conversational web services, that's not sophisticated?  Finally a proper solution for LIEs and the Seam-managed persistence context which is conversation-scoped?  Flexibility in terms of design patterns because layers are not required like in other frameworks.


            And I've been doing Seam dev for 2+ yrs now and I don't think Seam dev, or any serious custom software dev for that matter, can or should be trivialized to being described as using copy-paste technique.  There is custom business logic, persistence logic, standard and custom UI components, UI design/page flow, AJAX functionality, integration with web services and other applications, and design patterns that is unique for every screen and every app.  Sure, you'll see @Begin and @End in backing beans like SFSBs but they're intelligently placed of course.  Unless you're referring to seam-gen artifact generation like -ds.xml and persistence-.xml but I really like to have that feature as well as reverse engineer my db schema as well.  Hit the ground running.


            2) Many cases where I used workaround for JSF, Richfaces or Seam degraded to one line of code for Wicket. It seems that Wicket is done by people who know how to design frameworks :)
            This makes it sound like Seam framework was not designed properly.  I will admit that there are some heavy performance optimizations that are required in JSF/Seam apps (like @BypassInterceptors and being careful with rendered attribute in JSF tags) but if Seam concepts have made it into JCDI, JSF 2.0 and possibly other specs, then of course there's some good things there, no?


            Does Wicket support the concept of Renderers and RenderKits that JSF supports so that we can encode/decode our presentation layers in HTML, SVG, WML, etc.?


            Also, JSF is a standard and Wicket is not.  No matter how much more OOP and better features/performance you may get out of Wicket, it is not supported by JBoss support contracts AFAIK.  But perhaps Wicket too will one day become part of the JBoss stack?

            • 3. Re: analyzing the wicket project in the Seam 2.1 distro
              vladimir.kovalyuk

              Arbi, try Wicket for 3+ months and then compare.


              Personally I would like to follow WORA principle and my experience says that it is pretty difficult to follow WORA everywhere with JSF. At least it is expensive. For simple projects with small budget it is reasonable to employ copy paste from time to time otherwise the project budget would be exhausted. There is no offensive attitude as you imagined.


              I wrote about UI only, Seam leverages JSF in many aspects but users are still lacking of incapsulation. I didn't wrote about business logic or DAO. Whether you like it or not it is just my opinion. Until JSF becomes true OO framework I will say that it is not for business development, despite the fact it is standardized. You may standardize whatever. First off I evaluate how MY project is expensive.


              Wicket has far more thoughout design than JSF has. It is my opinion. JSF developers have many things to learn from Wicket.


              Concerning RenderKits. Wicket supports XML output. So any valid XML can be easily generated by Wicket. I don't know how it would be difficult to make it work with binary renderer immediately. But it is possible to generate XML and then tranform it to binary format. If the task is simple you can switch variants of the component so Wicket will pick-up different java and markup files depending on current variant name. I have already wrote about it.
              From the other hand I can't imagine any case when you have to use different render kits with the same component tree and it's state. The accent made onto Facelets component model in JSF 2.0 is the evidence that RenderKits becomes less important thing. Personally I find renderkits a barrier for newcomers that makes learnign steep. I find Wicket way of incapsulating rendering into the component itself more simpler to design and maitain components.


              BTW, not at all.

              • 4. Re: analyzing the wicket project in the Seam 2.1 distro
                vladimir.kovalyuk

                More advantages.
                - Wicket allows nesting forms and partial ajax processing of nested forms.
                - Wicket allows you to swap one component with another no matter it is regular web request or ajax request. It is a disaster for JSF.
                - Wicket has logic for attaching and detaching components and their data. You should make an effort to get some data evaluated twice. For JSF you have to constantly think about how many times and when every particular expression is evaluated. Once you've missed you have the bug report.
                - Wicket can use xml property files for i18n
                - Wicket remembers raw component input. If you bypass validation or failed validation the values are preserved and rendered back even if you left the page and returned back.
                - Wicket are open to new language features and enhancements. For instance once the closures are available you can benefit from them.
                - Wicket is more friendly for search engines

                • 5. Re: analyzing the wicket project in the Seam 2.1 distro
                  vladimir.kovalyuk

                  And Wicket has MultilineLabel component that does not suffers with this particular posting issues.