Pff... this is the third time I need to send this message, my providers'
smtp server has appeared on the black list of a spam blocker and no mail
gets through to the sf.net mailinglist from my home account. :-S
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 ;-)
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.
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?
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?
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"
... >
This is markup scripting. This is against what Wicket stands for. It is
a small step before you have 'conditional' markup, and 'looping inside
your markup', guess what: you have reinvented JSPs or Velocity with
other syntax!
Wicket is about providing you with the best tools available: your
favorite HTML editor for the markup, use your favorite browser to
preview it, and your favorite IDE to edit your Java. If we introduce
this, then all compile time checking is overboard. You won't have any
refactoring support. The list goes on.
Wicket wants to have as clean markup as possible. Yes we need some extra
stuff to make it work, but it was either introducing some stuff in a
namespace, or re-use some HTML tag. We don't introduce markup scripting.
Reusing markup tags for framework purposes is very designer unfriendly.
Some frameworks need the 'alt' tag, or the 'id' tag in order to do the
matching, thus prohibiting the use by a designer, in CSS or JavaScript.
Wicket uses an alternative namespace, and thus avoids this trap.
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.
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.
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
Martijn
-------------------------------------------------------
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
