One strong consideration four our research into using Wicket as the standard
UI framework for our open source projects is the very workflow of our
company. We have a well defined and capable UX team, who design the
interfaces for our applications. Their deliverables include wireframes and
html mockups. Wicket would allow us to utilize those mockups, thereby
eliminating a fairly sizable amount of the work required to produce pages.
With GWT, we'd only be able to use designs from UX as a reference, and woudl
need to recreate the work from scratch with Java. This would be wasted
effort.
Finally, our initial review of GWT revealed one undesirable factor: the
amount of scripting and markup emitted by GWT to do even trivial things.
Although we didn't pursue this further to see if the growth of scripting and
other artifacts grew linearly with page size, but the initial trial was
enough to shift our focus to more lightweight, efficient frameworks. GWT
may have progressed since then, so YMMV.
-jjk
On 4/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
On 4/4/07, Richard Hogue <[EMAIL PROTECTED]> wrote:
> Thanks for all the info. I've been in the Swing world for 10 years and
> need to come up to speed on the alphabet soup of the Web World in a few
> scant weeks ;-) My knowledge of Ajax is, shall we say, a bit sparse...
>
> Wicket and GWT seem to be the most swing-like, and they are both easy to
> become productive on in an hour (or less).
Another framework to consider might be Echo 2. I think it's kind of
in-between Wicket and GWT. Like GWT, you'll have to work with layout
managers though, so if you plan to get separate UI designer guys, that
won't work as well.
> It does boil down to "the right tool for the right job", and management
> is looking for the framework of "the future", even though we have no
> idea what we are supposed to be building...
Yep. A very important consideration is whether the projects you'll be
building can be all-ajax, or need to support a more traditional model
as well.
> I still have some code our architect has put together to accomplish a
> "non-trivial" task and he is not happy with the amount of code he had to
> write to accomplish the task. I need to find a way, if possible, to
> simplify it.
Wicket usually doesn't win when it comes to writing less code.
However, less code doesn't always mean that it is better maintainable
and flexible. In Wicket's case, you often have to write a bit more
code than it's counter parts because it is unmanaged and doesn't
impose yet another DSL. In return, you'll get lots of type safety,
good refactoring support and developer freedom. My biased opinion of
course. The choice is your's (and team).
What you could do is make a list with 'should haves', 'nice to haves'
and 'might haves' and rate the different options you are investigating
accordingly. You could send such a list (with your opinions if you
whish) here and see if people are interested in giving their -
probably Wicket biased - opinions. For example, i18n support, the
ability to work with separate designers, reusability, etc.
Eelco
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
