Igor has already mentioned one advantage of declaring and configuring components in code -- it is easy to make the presentation very dynamic. For example, when displaying products from a catalog, the page constructor can vary the display-components used depending upon the type of product chosen by the user. (You could have different types of panels for different types of products, any one of which is embedded into the same basic page object.) But I have another consideration in mind.
The advocates of Extreme Programming argue that it is naïve to think one can always design first and then implement. They argue that it is more realistic to start coding a few use cases and refine the design along the way, as experience adds insight and as the user's requirements become clearer. To refine the design of existing code they recommend _refactoring_ (see Martin Fowler's book on that topic). Suppose I've built a page and later decide, in view of the DRY (Don't Repeat Yourself) principle that a portion of my page should be refactored into a custom component. With Wicket I can move some of the page's Java code into my new panel class, and move HTML snippets from the page's associated HTML to the panel's HTML file. This process seems not too far removed from Fowler's "Extract Class" refactoring. To me, the ability to easily refactor is one advantage of having the components added and configured in code. To do such a refactoring in Web Objects, I am guessing that one would have to work with the generated tag files (a mixture of HTML and component configuration tags), which I doubt is practical to do by hand. So unless the tool implements this kind of refactoring directly (which I doubt), you would create the re-usable component _from_scratch_ using the display-painting tool again, throwing away components that were painted earlier. I fear that this wasted effort may be a disincentive against presentation-layer refactoring -- with the result that final designs won't be as tight as they could have been. (On the other hand, if the Web Objects tool makes re-doing the work sufficiently easy, the waste of redoing work may be insignificant.) I can see that some applications might be easier to build with Web Objects, just as for building certain types of fat clients Visual Basic 6 is easier to use than Swing. But for more sophisticated presentation logic, the Wicket approach will facilitate the use of design patterns, refactoring, and other modern OO techniques. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Sent: Wednesday, August 30, 2006 3:15 PM To: firstname.lastname@example.org - Java code is MUCH cleaner with WO, you keep in code only data pushed in the presentation layer and actions. No need to add components and configure them in java code. - Components are declared in HTML, configured in another file, binding (configuring) the component with the java class. This approach need tools, WO has some nice tools for this. - Both frameworks make creation of custom components easy (unlike JSF!!!) ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Wicket-user mailing list Wicketemail@example.com https://lists.sourceforge.net/lists/listinfo/wicket-user