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