Martin Sachs wrote:
Your right !
Already I have developed three Wicket apps (12 month of work for a man), I
know how fast i can do thinks with wicket, but i need knowledge of e.g. JSF
to say wicket is THE FRAMEWORK for the next big site. Maybe with JSF all
things will be developed a lot faster, maybe not. Is other technologies also
Maintainable very well, in comparison to wicket ? That questions cant be
answered with looking at a "HelloWorld" application.
Right. Always choose the right tool for the job ;) in my case, a small
dev team (1 ~ 3 devs), many variants of the same kind of middle-sized
webapps, and exactly the kind of apps that belong to wicket's comfort zone.
Every application has its own unique requirements on style, architecture, so
we cant reuse only very abstract components. That works fine with wicket. So
if we have a new project we develop the basics components for this project
(very fast).
Agreed. However, I found that when dealing with web applications rather
than web site, where a simple and effective HTML / CSS / Ajax based UI
is enough, I could reuse many stuff from previous projects.
Naturally, what I reuse most often "as is" are the custom components
(read wicket components) we have already built. The only project
specific implementation required for those are usualy the IModel implems
to use, and sometimes a few CSS / HTML tweaks.
As we use Wicket only for the UI layer (classical Spring / Wicket
stack), I find that most often, when desiging the requirements for the
UI, I find existing designs and working implementations either in our
previous projects, in wicket user list or by googling... Thankfully,
there are still times where I have to come up with some fresh design.
Maybe you can estimate a factor of time (for development or maintaining) in
comparison with JSP, JSF, ... or whatever you know else
As meaningfull as it can be, three years ago we rewrote our base
applications that were based on a Struts 1.x / JSP / Spring / JDBC stack.
The app was a small / middle sized app at the time (~ 30 struts actions,
~ 100 jsps) representing a ~5 months of workman. It tooks us 2 months of
workman to rewrite from scratch with Wicket. Maintenance time on live
applications has been cut down by a factor 2 on average.
New project developpement time has been cutoff by a factor 3 on average.
Off course, this is not only due to switching to Wicket (event though it
is the major factor), but also to using other techs. where usefull like
Hibernate & co, and rewriting from scratch an application with more than
3 years of feedback on the previous version ;)
I won't talk about JSF as after my first evaluations of the tech. in our
company context, and continuously ranting inside my head for the 3 days
investigating it, I decided that the only way I would use JSF was to
torture me to death :D
Cheers,
Antoine.
regards
Martin
Antoine Angénieux wrote:
I would not count in how much you gain during your fist devs. with
Wicket (even though you STILL gain a lot of time), but how much dev time
you gain when reusing your existing Wicket components and how much time
you save when you need to maintain your apps ;)
Cheers,
Antoine.
Martin Sachs wrote:
I'm looking for a little comparison of the development-time for
Applications
in Wicket against other Technologies.
I think the development with Wicket is two times faster than Struts. But
what are your experiences on JSF, Rails/Grails, SpringMVC/SpringWebFlow.
Anyone you know the development-time from experience ?
(P.S.: The applications must use AJAX and many custom components or tags
in
JSP, not just a hello world sample)
--
Antoine Angénieux
Associé
Clinigrid
5, avenue Mozart
75016 Paris, France
+336 60 21 09 18
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Antoine Angénieux
Associé
Clinigrid
5, avenue Mozart
75016 Paris, France
+336 60 21 09 18
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
