-- create a jira issue for the datepicker please For the datepicker only? Shouldn't it be done on the component level and be a part of solid wicket API...? In fact I do not use the datapicker at all what I said was related to the problem that I faced writing my own components.
Hi Uwe, Why it should be so complicated... Isn't it better and simpler to be able to just add dependencies by hands overriding the defaults. It's the only practice in the javascript world. Look at YUI or whatever... every component has the inctructions... which libs to include...which css files... and how to use it. Personally I think that java and javascript should be kept as completely independent worlds with a clear conceptual separation since wicket do not even pretend to do such a thing like GWT or Volta do (java -> javascript translation). And so an interoperational aspect in wicket are very limited. The client side shouldn't be jailed by the server side anyhow. A javascript developer should always have a change to tweak the tricky nature of javascript. On Sun, Apr 27, 2008 at 11:21 AM, Uwe Schäfer <[EMAIL PROTECTED]> wrote: > Vitaly Tsaplin schrieb: > > > > -- personally i like to be able to simply include the datepicker and > not > > -- have to worry or research what javascript library it uses. > > > > > i´ve talked this over with some guys personally, and maybe this was > discussed before, but consider this: > > what if components could express contributions by a dependency descriptor > (maybe new Dependency(KnownLibs.XY, 1, 2) for xy 1.2) and provide wicket > with a javascript integration project, where some versions of XY and others > will be packaged? the page could resolve this dependency and actually > contribute the header. > > - first thing that comes to mind, is that if lib XY has init code, that > really should run once, and once only, the page has a chance of including it > only once, if two components request for it. > - second, assuming that later version are always compatible with earlier > [yes, i know :) ], the page could decide to resolve to a later version if > two components use two different versions of the same lib > > up to here, the cost of mainting these third party libs is as high, as > packaging them with a version descriptor. i really think, that would be > doable. > > - third (now really dreaming) if some version shift is known to break > compatibility, the page could ask an handler to resolve this situation or > (if unhandled) throw an exception. > > this makes it possible to a) be aware of using two components that depend > on different version of teh same lib and b) to get the PAGE in charge of > handling this situation and decide, what to do, as the page is the one > thing, the application coder has control over (whereas the components are > not). this would of course mean, that the libs desriptor needs to declare > that compatibility break and (and here comes the tricky part), those people > adding it to the "KnownLibs"-project have to know about it. > > what do you think? > > cu uwe > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
