Hi,
Took some time to pick up this thread again as we were preparing for the
UAT of the application rewrite using Wicket =) for the last 2 weeks.
The UAT was quite successful, with minor modifications required (expected).
The real good news is that Wicket performed admirably in terms of
productivity and the bugs tracing and fixes in the lead up to the UAT.
We rewrote the modules in under a month (the original took about 4). The
productivity boost actually came from the tweaks we needed for UI
interaction as well as code tracing when unexpected behaviour occured.
The experience using Wicket has been real refreshing, I truly enjoyed
the departure from the model2 as well as the json-rest/rich-client
frameworks we were used to.
Ok enough ambling. I have some responses below.
Igor Vaynberg wrote:
On Wed, Nov 18, 2009 at 9:27 PM, Lester Chua <cicowic...@gmail.com> wrote:
Thanks for the reply.
1) Product Roadmap (Release plans, upcoming features etc)
This is important to us because it will at least indicate the intentions
of
Wicket Team. As any technology that is adopted enterprise-wide needs to
be
long-lived and well supported in addition to it's features and
technology,
some visibility about the product lifecycle is required.
http://cwiki.apache.org/WICKET/wicket-15-wish-list.html
http://cwiki.apache.org/WICKET/wicket-14-wish-list.html
I did see the wishlist but was wishing for something more like a roadmap
with projected release timelines, I can see why that it will probably not be
accurate for an open sourced project but an indication of a rough ETA and
included features will be good.
By the way, is the wishlist official? As in are the features present in the
wishlist official? Or is the wishlist used as an idea incubator/exchange?
its an idea incubator
Although it's nice to have the wishlist, it's a shame that the Wicket
does not publish a roadmap (even a limited one with just key specific
features to be improved on).
Is is a resource/maintenance issue you have that prevents you from doing
so? Or is it more of a management decision to not publish the roadmap so
that you can avoid "commiting" to a timeline?
The reason why I'm asking this is partly selfish. The organization that
I'm pushing Wicket in has a technical committee that review
frameworks/platforms for use. Anything that does not fall into their
recommended list will need a waiver to be used and deployed. Yea I
know, very cumbersome but it's a fact of life here, and I suspect in
many other organizations that have security as one of their top concerns.
After using Wicket in a real life app conversion, I think I'm able to
address most points that has been raised including security (very
pleased on that front) and productivity etc. But part of the checklist I
am forced to go through is estimated product life span, road map etc.
Unfortunately, It's here that I'm stumped. Has anyone else been through
this hoop-la-loop that your organization forced you to go through for
the introduction of Wicket? If so it'll be great if the information on
how that was achieved can be shared as it'll help me immensely in the
fight to get Wicket into my enterprise environment.
2) Recent Adoption Statistics (No of downloads, usage projections)
We need this to gauge the interest in the project. Has it peaked? What
is the pattern like?
++ Nice idea
a) Although there is examples and documentation available on Wicket main
site and Wicket stuff, I find that the organization of the information is
probably not friendly enough for easy viewing. E.g. the examples site
does
not contain source and viewable example together in an easy to read page.
This can be improved on significantly.
"you and your team are welcome to contribute, great ideas btw"
Planning to once I get up to speed.
Being such an easy to use component framework, I am really puzzled about
why the
plugin development seems so bare
One reason is that it's so easy to make plugins it feels unnecessary
to publish them.
Actually I kinda disagree. Take Delphi which was awesome for it's component
architecture and IDE. Writing components and packaging them was very easy
but it had a HUGE thriving component library market place where you can
literally purchase thousands of packages and libraries.
desktops apps are different, you can build any kind of component you
want. wicket works with server-side html and there is a limited set of
things you can build. if you need a slider then the chances are we
wont provide it, we dont need to, just use wicket to output a hidden
field and make a slider out of it using jquery or some other frontend
library. in about two minutes you can wrap that into a jqueryslider
component, would you take the time to share something that took two
minutes to build? some people do, there are a couple of projects out
there that provide integrations between wicket and jquery, but most
people dont end up sharing.
In terms of functionalities that users want that can be offered, they
are not that much different. When Desktop apps are common in the
enterprises, most desktop apps are just a front that baby sits a
database. True what you can achieve and how you achieve is very
different on desktops vs web, but what I'm comparing here is that Wicket
should leverage it's component aspect to advance itself as a product.
Technical excellence is rarely a determinant in deciding whether a
product achieves widespread adoption. Marketing, Mindshare, Support, are
very important. Look at the piece of junk JSF has achieved in terms of
adoption. After working a bit more with Wicket, I can see that what you
say is kinda true. But that does not mean that Wicket will not benefit
from a market place for the quick and easy solution. Need a component
that behaves like the once exactly, why just download a 20 bucks JAR and
pluck it into my app and saves 2 hours of coding/testing (I'm not at the
stage that I can build a component in 2 minutes yet =)).
A market place also indicates VERY accurately the adoption rates and
activity for new comers like myself. It is very reassuring to know that
the last component on sale/or distributed as freeware was released just
a couple of weeks ago and there are more that X components actively
maintained.
c) The mailing list is wonderful and I have had some questions very
quickly
answered, which points to an active and supportive community for which
I'm
grateful. If there is a way to harness this and make the information more
easily accessible, it'll be awesome.
Google reaches most of the discussion via nable/osdir.
Yea, that is how I got most of the solutions to my little set of problems.
=) Just wishing that it can be better.
hrm, you posted about six messages on our lists, and most times you
got an answer within a couple of hours. that is better then most
commercial support out there. and yet you are still complaining? :)
-igor
And I truly appreciate that =).
My 2cents worth ;)
**
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
