If we take that view everyone rolls their own and repeats the same thing. While I've added new components I'd rather use pre packaged ones, swapping out the components for alternates as and when we need to for improved functionality / appearance.
When learning / working with a framework I don't want to spend time wondering if my code isn't working because of a home made component but rather assume the up to date packaged components work and its likely my usage that's at fault. I have this confidence for textfield, dropdownchoice, datatable etc. but not for the JS based ones. Some of the other libs aren't kept up to date. If one of those jquery ui based libs was built immediately after Wicket builds it would help. I've already hit odd behavior with wiquery and wicket 6.3 which was resolved by using the latest jquery-ui ultimately removing wiquery. I'd rather not do that. As a framework trying to appeal to a broad base of users I think we should provide a good base of components. The flexibility of Wicket is already there - if you know how to use it - but there's quite a learning curve. Jquery-ui vs bootstrap vs another doesn't matter to me - as long as I can get something functional as soon as I can and then worry about tweaking components later on. If wicket-bootstrap was to become a core supported lib then I'd switch my current project purely from a support standpoint and belief that as a core lib it would have broader usage, generate more questions etc. Why don't we put together a survey to ask folks? N On Dec 14, 2012 3:20 AM, "Martin Grigorov" <mgrigo...@apache.org> wrote: > My personal experience is like Martin Sachs' one. > So far the projects I was working on never used the pre-build rich > components because they didn't fit the "company standards" either because > of the used technology or because of the UI mismatch. > > I think the current YUI datetime component needs a change because: > - it uses YUI 2.x which is no more supported > - Wicket comes with jQuery by default and using YUI for a widget just > contributes to the slower responses > > Why I think Apache Wicket doesn't need its own date component ? > Because there are several out there already (wiquery, wicket-jquery-ui, > wicket-bootstrap, jqwicket, jwicket, ....) > > Maybe we should adopt some of those ? > If we decide to do that then we have to invite their developers too because > at the moment we have no resources to maintain it ourselves. > > Few months ago I was in favour of jQueryUI, lately I like Twitter Bootstrap > more and more, and I'm not sure what new fancy JS UI library will arise > next year, that's why I think Wicket should not provide "default" UI > widgets by itself. The above listed libraries do this good enough. Some > users prefer WiQuery, other - Wicket Bootstrap, third prefer to make their > own components ... > > > > On Fri, Dec 14, 2012 at 1:23 AM, tetsuo <ronald.tet...@gmail.com> wrote: > > > Wicket already uses jquery for its ajax support. A jquery-ui module > > (thus the dependency to jquery-ui.js) would be completely optional, as > > is the embedded yui library currently used by wicket-extensions. > > > > > > > > On Thu, Dec 13, 2012 at 8:29 PM, Michael Haitz <michael.ha...@1und1.de> > > wrote: > > > I think wicket should only provide basic components without > dependencies > > to keep clean and simple (and extendable). Libraries like jquery-ui or > > bootstrap would break this and everyone who wants to use wicket has to > use > > the choosen ui lib too. And there isn't a "all in one" lib suitable for > > every purpose. > > > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com <http://jweekend.com/> >
