create a jira issue for the datepicker please -igor
On Sat, Apr 26, 2008 at 7:21 PM, Vitaly Tsaplin <[EMAIL PROTECTED]> wrote: > -- personally i like to be able to simply include the datepicker and not > > -- have to worry or research what javascript library it uses. > > I would definitely do the same but the javascript often comes the > developer hell and any hidden includes injected by the component > itself can make things just worse. > I would definitely like to be able to turn it off instead of being > dictated whatever version of acriptaculous or prototype or YUI I > should finally use or to include 2,4,6 or more completely identical > versions of the same library just because it's not so obvious how to > spell the name of the library in the contributor script.aculos.us or > scriptaculosus. It can come to be just rediculous. > The situation can get worse as more serious commercial companies > having a lot of legacy staff and pages with preincluded libs will be > migrating to wicket. But it's just my personal opinion... > I think something like contributeDependencies seems be be a good > compromise. > > > > On Sun, Apr 27, 2008 at 3:39 AM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > personally i like to be able to simply include the datepicker and not > > have to worry or research what javascript library it uses. > > > > but sure, i guess we can add a simple boolean > > datepicker.contributeDependencies() that you can then override and > > return false. > > > > of course then it puts burden on any component that encapsulates a > > datepicker to forward this breakout... > > > > -igor > > > > > > On Sat, Apr 26, 2008 at 5:20 PM, Vitaly Tsaplin > > > > > > <[EMAIL PROTECTED]> wrote: > > > | if you contribute an incompatible version you are still left > with a > > > | nonworking component. so what is better now? > > > > > > At least I'll be able to include the latest one. > > > > > > Anyway in this scenario a component author will (I hope) properly > > > define the list of all libraries the component depends on specifying a > > > version of every library the component was tested with. You do the > > > same including velocity or spring to the wicket distribution. And I > > > can always change it. But doing a header contribution I can't change > > > anything due to the fact that wicket puts all contributed stuff just > > > after everything I already have included. So the contributed stuff > > > will always take a precedence. Is there any way to override? > > > > > > In addition I would point to the fact that the existing practice of > > > an inclusion of javascript libraries from a java package will finally > > > lead to an enormous count of included versions of the same library > > > taking time to be downloaded by a client's browser. But just the only > > > lastly included one is going to be really used. > > > > > > It's obviously more related to extension writers then to wicket > > > developers because it's clearly more the matter of the best practice > > > then a technical issue. > > > > > > > > > > > > On Sun, Apr 27, 2008 at 1:50 AM, Igor Vaynberg <[EMAIL PROTECTED]> > wrote: > > > > but what good will that do? so components do not automatically > > > > contribute the javascript. instead you have to now do it yourself, > and > > > > if you contribute an incompatible version you are still left with a > > > > nonworking component. so what is better now? > > > > > > > > wicket-datetime is not part of core, and even if it was you dont > have > > > > to use it. its a choice you make. you can see all the javascript it > > > > includes easily. i agree that it would be super awesome if > datepicker > > > > depended on our own internal and namespaced javascript. but looking > at > > > > the modal window and autocomplete textfield, i dont think that is a > > > > business we want to be in necessarily as it is a huge timesink. > > > > > > > > -igor > > > > > > > > On Sat, Apr 26, 2008 at 4:28 PM, Vitaly Tsaplin > > > > > > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > I am not talking about a level of wicket perfection :) I > really > > > > > like the idea to contribute to the header scripts that are > locally > > > > > stored in the java package if those scripts are somehow > proprietary > > > > > for the component being imported. But I am a bit worried about > the > > > > > fact that such commonly used components like datepicker or > whatever > > > > > are contributing YUI or prototype or some another library. It can > > > > > quickly turn into the problem once it's getting out of regular > > > > > support. You will end up with the fact that your application is > > > > > sensitive to the order in which your components are added to the > page. > > > > > It seems that you should somehow emphasize that fact and try to > > > > > somehow enforce extension writers to not include such libraries > to > > > > > they extensions locally but just put all required libs to they > zips > > > > > but out of the jar file. It's probably should be accepted as a > best > > > > > practice. I am just trying to discuss it... I guess it's quite > > > > > important since wicket is enforcing a component oriented design. > > > > > > > > > > > > > > > > > > > > On Sun, Apr 27, 2008 at 12:45 AM, Igor Vaynberg <[EMAIL > PROTECTED]> wrote: > > > > > > and so what do we do in this situation or how can we ever fix > it as a > > > > > > framework? you can always come up with a scenario that breaks > under > > > > > > some condition. nothing is perfect. > > > > > > > > > > > > if i code against jquery 1.2.1 and someone else codes against > jquery > > > > > > 1.0, then the two components are incompatible just like the > two > > > > > > versions of the library they use. there isnt much we can do > in terms > > > > > > of incompatibility resolution/prevention/whatever. > > > > > > > > > > > > and why should we try and solve it? we are a web application > > > > > > framework. we do not support whatever javascript our users > decide to > > > > > > include in their components. > > > > > > > > > > > > maybe when javascript has the same kind of library isolation > as osgi, > > > > > > or when the js library authors catch on and at least bother to > > > > > > namespace all their code life will be easier. > > > > > > > > > > > > -igor > > > > > > > > > > > > > > > > > > On Sat, Apr 26, 2008 at 3:05 PM, Vitaly Tsaplin > > > > > > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > And what does this mean? What if 2 different extensions are > > > > > > > contributing to a header 2 different versions of YUI or > prototype? Is > > > > > > > it possible in javascript? I think no. You will definitely > have a > > > > > > > conflict. One of this versions will take a precedence. > Being able to > > > > > > > include javascript libraries by hands you still have a > change to > > > > > > > choose a most compartible version or to solve the conflict > on the > > > > > > > script level somehow if you can (noConflict mode for > jquery for > > > > > > > instance). > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Apr 26, 2008 at 10:28 PM, Maurice Marrink <[EMAIL > PROTECTED]> wrote: > > > > > > > > But this still does not fully support different versions > of the lib. > > > > > > > > So if one extension uses version 1.0 of javascript lib > A and another > > > > > > > > uses version 2.0, chances are you have a problem. > because both > > > > > > > > extensions call some api that might not be available or > has changed in > > > > > > > > the other version. > > > > > > > > > > > > > > > > just my 2c, > > > > > > > > > > > > > > > > Maurice > > > > > > > > > > > > > > > > On Fri, Apr 25, 2008 at 6:24 PM, Nino Saturnino > Martinez Vazquez Wael > > > > > > > > > > > > > > > > > > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Vitaly Tsaplin wrote: > > > > > > > > > > > > > > > > > > > Isn't it often better to explicitly declare the > list of javascript > > > > > > > > > > libraries the component uses and let the user add > this libraries to > > > > > > > > > > the web content folder manually on his/her > preferred location? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I like that you package your component to run off > the fly, and then you can > > > > > > > > > overide so that you yourself can put in javascript > libs, just like the > > > > > > > > > prototip from minis, although I havent done this > myself this gives full > > > > > > > > > flexibility. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Apr 25, 2008 at 4:51 PM, Nino Saturnino > Martinez Vazquez Wael > > > > > > > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you just need the javascript library, I also > use header contribution. > > > > > > > > > > > > > > > > > > > > > > You can also take a look at wicket input events > or datepicker etc... > > > > > > > > > > > > > > > > > > > > > > If you have your js files locally(in your > project) you can use the > > > > > > > > > > > packagedRessource so it gets gziped.. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-stuff-contrib-input-events > > > > > > > > > > > > > > > > > > > > > > Vitaly Tsaplin wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > > > > > > > > > There are many usecases when it could be > necessary to write some > > > > > > > > > > > > javascript by hands directly in the html file. > So I need to reference > > > > > > > > > > > > the library I use in a head section of my html > file. But having a > > > > > > > > > > > > reusable component written in java which is > depending on the same > > > > > > > > > > > > javascript library I use a header contribution > to inject a reference > > > > > > > > > > > > to the library that I have somewhere in a java > package. So what is the > > > > > > > > > > > > preferred way to include a javascript library > to a wicket project? > > > > > > > > > > > > > > > > > > > > > > > > Vitaly > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > For additional commands, e-mail: [EMAIL > PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > -Wicket for love > > > > > > > > > > > > > > > > > > > > > > Nino Martinez Wael > > > > > > > > > > > Java Specialist @ Jayway DK > > > > > > > > > > > http://www.jayway.dk > > > > > > > > > > > +45 2936 7684 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > For additional commands, e-mail: [EMAIL > PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > -Wicket for love > > > > > > > > > > > > > > > > > > Nino Martinez Wael > > > > > > > > > Java Specialist @ Jayway DK > > > > > > > > > http://www.jayway.dk > > > > > > > > > +45 2936 7684 > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
