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]
