A big hello and thanks to Rob!
Reading this post it came to my mind through Rob's playing the devils
advocate here he is really improving this user-list's community.
And there are one personal experience and one common though to share
with you.
1. Personal experience with Wicket
Long before I knew of Tapestry I was evaluating webframeworks. I came
from cocoon, which in fact was and is a web-publishing-framework but
back in 2000 nobody cared about that. Huge efforts where made to make it
a webframework and doing simple webapps was a real PITA.
Through a collegue of mine I found Wicket and from reading the marketing
stuff on their page - they where the first framework that had this
comparison matrix online - I found it interesting and started to
evaluate. Hello world was easy and also the demo application was quite
interesting. When you have some experience with browser applications you
usually have ideas on what you need and so I tried to make my first own
Wicket app. Things got nasty, documentation was not present and my claim
was to not follow another mailing list. Though Eclipse would help me
with the Java part the concepts of Wicket haven't been connected with
what I see as the basis - HTML. Finally I dropped it. The quickstart was
to hard to take for me.
Compare this to Tapestry 5! You get 5 screencasts that speed you up in
an instant. The maven quickstart where you immediately can start your
own work. I was really impressed. Project Layout is well documented, the
concept is HTML visible/ invisible instrumented, so 50% of the lease
already payed!
Every Java programmer knows Beans and the IOC concept in 2007 is not
new. Of course the deeper you step into the framework the more fancy
things you have to learn. One ambivalent thing is this magical javassist
stuff. On the one side - not sure if this is the technical reason - it
helps you keep your code clean. I like @Property annotation because I
see no intellectual challenge in generating getters and setters. The
price is payed in debugging where paramters get set somehow invisible.
Anyway, compared to Wicket or Struts and Cocoon I need the debugger in
5% of the time I used to use it back then! Besides T5 notedly supports
you in getting a clear cut between business and web logic so the tiers
can be developed completely separate.
2. A common thought
One marketing problem of T5 as I see it is it's superb readyness. It
really is easy to develop applications with it after you learned the
basics - and that's easy too, thanks to the user-list (!) and the
nightly-docs(!). Let me give you an example. I have a contact form for
my webpage developed with Spring MVC. When I decided to switch to T5 I
let it live side by side. Yesterday I decided to write the T5 version of
it. I think it was done in 10 minutes. Ok, I of course reused the spring
stuff through IoC. But isn't that cool to?
Back to the readiness. Because T5 is so ready, users usually do their
thing with it. And it was said on the list some weeks before when an
insult from Rob was shaking this list for the very first time. But think
of it. We also have to market T5. Not only to our bosses or clients and
programmer collegues but also in the huge webframework market. And to do
that we need some flesh - this is the user stories.
So honestly Rob, thank you for your razor-sharp comments. Somehow you
are able to awake us to make the next step for T5 in a bright future.
My 2 cents,
Michael
Onno Scheffers schrieb:
Take for example Kent Tong, the former Tapestry commiter. He has now even
written a book on
Wicket.
..and he has written yet another one on JSF after that. So clearly he must
not like Wicket very much :o)
regards,
Onno
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
