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