Hi Hielke Nice to be able to discuss with some wiquery commiter.
Acutally, I was willing to use it some time ago but I found wiquery wasn't very good at selling itself. The wiki is pretty old and useless (http://code.google.com/p/wiquery/wiki/DocumentationHome?tm=6) and at the time I found no tutorial or example... Did it change in some way? I would still love to be able to have a better clue of it, since it looks intriguing, but I don't have enough time to do a proper investigation on how to use it... Regards 2011/4/7 Hielke Hoeve <[email protected]>: > WiQuery *has* matured a lot. We are working hard in our late hours to > implement and test interfaces to all facets of jQuery and are getting ready > for Wicket 1.5. > > Bruno is right that for some purposes it is easy using only jQuery, simply > add the jQuery js files you want and write a script tag with the > document.onready function. But I am curious how one handles ajax added panels > with jQuery functionality on a page or components that consume data or jquery > enabled components that have jQuery options set based on business logic or > components that have their visibility set based on business logic. Once a > component is replaced by an ajax call the jQuery functionality is removed > from this component. Not to speak of being able to reuse numerous components > on numerous pages... I don't even want to begin to think about how to handle > jquery component options based on business data. > > Now I do agree that in some cases (which do not cover the ones I described > above) WiQuery is absolutely not useful and a simple static js file and > static jQuery initialization statement is good enough. Not every jQuery > component is worth converting to a WiQuery component. The ones that are worth > are often: > - components that are ajax enabled and/or; > - components that have their jQuery options depend on data or logic and/or; > - components that have their visibility or are enabled based on data or logic > and/or; > - components that are added by an ajax request and not at page load; > > > The reason I started working on the WiQuery project is because my company > creates enterprise administration applications where we have *a lot* of pages > with ajax replaced panels, autocomplete text fields, accordion panels, tabbed > panels, feedback popups... you name it we have it. > With WiQuery we create reusable components, define which resources this > component needs and what bit of jQuery it needs to initialize after the page > (or ajax response) has been loaded, and simple add them to the page. The page > is on a need to know basis, it will define the layout not boss all components > around... WiQuery checks which resources are loaded, removes duplicates, adds > the jQuery Core, jQuery UI and jQuery UI Theme. While managing multiple > projects with over 1000+ pages, this takes away quite a load off our > shoulders. > > Maarten says: > Writing what should be JavaScript in your wicket Java code is quite > out-of-place, and generally all you need to do is place your code where it > belongs, in a .js or your markup. > > I wonder if he ever really used WiQuery or even looked how it's used. Or for > that matter used jQuery. What you *don't* need to do with WiQuery is write js > code in your java classes and we recommend to put all js code in js files and > load them as a resource! To create a jQuery wicket component you: > - write your jQuery js file and the html file that comes with it; > - write the java code that you need to insert any application data, behaviors > or validators; > - let your component implement an interface (so WiQuery can detect it upon > creation) to define which js/css files you want to be added as a resource and > define the jQuery initialization statement with java code (which is > translated most often something like "document.onready(.....);". > > > There are other libraries around that do about the same as WiQuery, and > perhaps better or faster, but my rant above is to clarify why the project > exists and why people are using it. And the best part of it is: you don't > have to use it... > > Regards, > > Hielke > > -----Original Message----- > From: Bruno Borges [mailto:[email protected]] > Sent: donderdag 7 april 2011 0:32 > To: [email protected] > Cc: Maarten Billemont > Subject: Re: Wiquery experiences > > Most of the things you want to do with jQuery, you don't need a library for. > > I totally agree with Maarten > > > Bruno Borges > www.brunoborges.com.br > +55 21 76727099 > > "The glory of great men should always be measured by the means they have used > to acquire it." > - Francois de La Rochefoucauld > > > > On Wed, Apr 6, 2011 at 6:15 AM, Maarten Billemont <[email protected]> wrote: > >> Unless WiQuery has matured a *lot* lately and the code has been >> cleaned up significantly, I can't recommend it, personally. >> >> Writing what should be JavaScript in your wicket Java code is quite >> out-of-place, and generally all you need to do is place your code >> where it belongs, in a .js or your markup. >> >> There may be some odd cases here or there where tighter integration of >> jQuery and Wicket can be beneficial, but those can usually be resolved >> some other way. >> >> I don't have enough experience or knowledge of the framework to cast a >> final vote though, all I'm saying is: beware of the quality of this >> library's code and make sure you actually need it first (I want to do >> jQuery stuff in my Wicket application is generally not reason enough). >> >> On 06 Apr 2011, at 11:09, [email protected] wrote: >> >> > Hi, >> > >> > We are thinking of using wiquery for a project. We are interested in >> > the >> experiences of people using it. Does wiquery work in the major >> browsers (IE7, IE8, IE9, FF3 and Chrome)? Are there any complications >> when different versions of jquery are used on other places in the >> HTML? What is the version of Wicket you used it? >> > >> > Please share your experiences. >> > >> > Thanks in advance, >> > >> > Haiko van der Schaaf >> > >> > >> > -------------------------------------------------------------------- >> > - 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]
