I've never used Wicket, but I've done a fair number of webapps using
similar component frameworks, such as WebObjects and Tapestry. All I
can say - it is hard to argue about component frameworks with people
who never used them. The benefit is essentially a different more
developer-friendly abstraction. Of course it ties to the request/
response protocol.
Wicket site does seem to be heavy on marketing talk. While I find it
very annoying (although this probably serves them in converting the
masses), this doesn't mean it is a bad framework :-)
Andrus
On Aug 24, 2006, at 3:23 PM, Greg Stein wrote:
On 8/24/06, Ersin Er <[EMAIL PROTECTED]> wrote:
...
Wicket vs. Struts: http://www.wicket-wiki.org.uk/wiki/index.php/
Struts
Bleh. That page confuses a lot of things. It conflates disparate
components (e.g. Struts and JSP) in order to form opinions. It appears
that Wicket also does state management "as a benefit" which I've
rarely found to be true (any state in your http server kills
scalability). And it somehow argues that Struts cannot handle multiple
components on a page because they all go to one response handler for
actions? Euh... seems each component would specify its own handler.
On a pro, it seems to talk smack about JSP. Good. On a con, it uses a
lot of buzzwords to try to demonstrate superiority. I don't know how
"Wicket is fully object-oriented. You work with hierarchies of
components and design your application as such. There is no need to
bend your oo design to fit with the request-response nature of the
HTTP protocol." will really help. The web *is* request/response.
Whatever. ETIMEOUT.
-0 (binding)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
