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: wicket-user@lists.sourceforge.net

- 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
Wicket-user mailing list

Reply via email to