Martijn Dashorst wrote:
Anders,
Don't get me wrong, I don't mean to be harsh, but I think you don't
'grok' the Wicket way, given your comments below. I try to give the
'wicket mindset', and it is only my opinion, perhaps other community
members feel differently. And I'm handicapted: I'm dutch ;-)
I really want to like Wicket - honestly - but I'm struggling. Also; I
fully realize that some (most) of my problems are because I'm a beginner
- not necessarily because there is something wrong with Wicket.
Anders Peterson wrote:
I don't know too much about the internals of Wicket, but I have
opinions on how things should work. ;-)
1) Fail gracefully: I had problems with a Panel/Form today. I got a
(Runtime) Exception as soon as it was rendered (which I couldn't
prevent). I actually wanted to show an empty form - it would
illustrate to the user that soon he/she would be able to modify some
data. Sure, I could get this working almost the way I wanted, but not
without some coding. That brings me to my second point.
Failing gracefully is against the principles of framework building: if
something isn't right, then you have to let the framework user know that
it is so. Wicket can't decide (randomly) that something is good or
isn't. How could Wicket handle a textfield attached to a <span> tag? We
should detect that and not let the application go gracefully into oblivion.
Well... sometimes you have to, and definitely should, "fail". Having
components (a form) bound to a model that is not yet initialized is not
one of those cases.
Empty form: supply an emty business object. Not to hard IMO? If it is
null, what should Wicket do? How can we even begin to validate the
request? How should we allocate memory?
If you submit a form with an uninitialized model THEN you should fail.
2) Supply default implementations that work: Wicket developers need to
do far too much subclassing. We shouldn't have to subclass Form,
Button... simply to get something working!
Because when you build an application you need to provide wicket with
what you want it to do? How else should we know what to perform in an
submit?
Have forms/buttons call a method like performActionNamed(...) in the
form's parent.
Actually; why do we have to explicitly instantiate anything? Why not
do this in the html file:
<form wicket:id="form01" wicket:type"Form" wicket:action="doSomething"
... >
I agree (change my mind about). Having as much as possible done in the
Java code is a good thing.
With Wicket I feel I'm building the GUI twice - I have to create a
hierarchy of componenets that exactly matches the (structure of the)
corresponding html file.
Wicket can't know what you want, Wicket is not psychic. Creating the
hierarchy of components and attaching them to the markup is the least of
my worries when building a Wicket application. Creating the business
logic usually is.
As a beginner I find it time consuming to assure that the component
hierarchy matches the html structure. I don't see why the WepPage can't
have a flat view of the html page. Components are bound by name anyway.
The markup can be created by someone else. At least in our company,
someone makes the markup, and we (the developers) attach components to
it in the Java. The designer doesn't need to know Java, JSP or any
scripting language (perhaps JavaScript) to be useful in our
applications. It is a clear separation of concerns which makes Wicket
stand out in the framework arena.
That sounds like an argument for not having to match java-hierarchy with
html-structure!
And even if you feel you have to build the GUI twice, this is still far
less than with JSF or Tapestry ;-) (I hear a boxing bell *DING*).
I just feel that you want a framework where you say:
new MyBusinessApplication().do();
and have a complete application working with 1 line of code. That is not
going to happen with any framework any time soon, even though we have
great plans with Wicket. :-D
I have 5 years experience building complex web based applications using
WebObjects.
http://www.apple.com/webobjects/
Have a look at it - it's free - you may learn something. ;-)
Why am I using Wicket: I'm unhappy with how Apple
manages/markets/licenses WebObjects, and after 5 years I thought I'd try
something new.
/Anders
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
