On 8/24/06, Greg Stein <[EMAIL PROTECTED]> 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.
As the note on top of the article states, it was not written by any
team member of Wicket.
If you are interested in my take amongst some other frameworks on
this, you can find it here:
http://www.virtuas.com/articles/webframework-sweetspots.html
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).
Most competing frameworks are 'optimized' for that scalability as
their number 1 concern. That works *if* scalability is your number 1
concern, like the Googles, Amazons and other large public facing web
sites. However, if you are developing systems for just a couple of
(tens of) thousand users, where the load is predictable etc, you might
as well focus on other issues than merely scalability. Wicket focusses
first on the development model and only in the second case, as an
optimization, gives you the tools to tune your application for
scalability.
Two years ago I was looking for a framework that would scale better
for development. A framework that would let us utilize reuse like we
were used to with e.g. Swing. A framework that would save our projects
from all the hacks, ad-hock session usage etc that inevitably popped
up when the UI get more complex. A framework that would help our
junior programmers learn object orientation instead of learning just
about every bad programming habit one can image. A framework that
would allow us to hire HTML/CSS guys with their own tools for the
layout etc and leave the programming to programmers. A framework that
would have more means of breaking functionality up in smaller pieces
so that for a change we would end up with something maintainable after
spending a couple of man years building. Those were real, urgent
problems that needed to be addressed and that the (model 2) frameworks
we were using at that time didn't address (in fact they made things
worse). With Wicket I found a framework with a solution to these
problems.
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.
This is akin to the objections people up to today make to ORM
frameworks like Hibernate. They say you shouldn't try to bend OO
design to fit the relational nature of databases. In this case too,
it's a matter of optimization; staying close to the metal gives you
the best options to optimize, but using an ORM framework or component
framework provides you with a superior programming model.
I'm sad people feel we are trying to sell Wicket with a bunch of buzz
words. We hoped we were doing better than that, and in fact feel that
by swimming against the current in many areas, going for the cheap
sell is the last thing we did. Anyway, the 'OO programming model' part
is really important to us. The framework was started by Jonathan
(previously worked for Microsoft as a Java evangelist, worked amongst
other things Visual J++, switched to SUN to work on AWT and Swing)
who, when starting out for his first web application with Java, was
appalled by the fact that there was no framework, out of all the 50 or
so he found, that allowed him to just simply program like he could do
with Swing. JSF, Echo and Tapestry came close to his goals as at least
they know component reuse and state management, but he still missed
the 'simply Java' part. So he decided to scratch his own itch and
created Wicket.
With object oriented programming we mean something simple really, like:
public class MyComponent extends SomeOtherComponent { ...
or
public class ClickPanel extends Panel {
private int count = 0;
public ClickPanel(MarkupContainer parent, String id) {
Link l = new Link(this, "link") {
public void onClick() {
count++;
}
};
new Label(l, "label", new PropertyModel(this, "count"));
}
That's all you have to do to create a new component, and if it is
available in your class path, it's available for use with no other
requirements. Personally, I favor this way of programming over having
to be aware of the underlying protocol all the time, just as I would
favor not to bother with the event loop of the operating system when
I'm developing a desktop application. You can object to the importance
we give to providing a clean OO model, and argue that our tradeoffs
are ill chosen, but I believe Wicket fills a gap in the web framework
sphere.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
