| 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]
