Joseph,

Well it is true the documentation is not updated and there is not much
to start with... but mind that WiQuery is maintained by people that do
this mostly on their free time... I think

1- support on the google group is rather good
2- the speed on fixing bugs and reacting to user input is hight...

Additionally some of use have tried to add some extensions integrating
different jquery plugins (components) (e.g. see [1] and [2]).

So, what else do you need? Someone to teach you step by step how to
use the projects?  What about getting the example project, see how the
examples works, look to the source code... and learn from there? IMHO
theses are basic skills someone trying to make a living as Java
programmer should have... and once you have learned something...  Why
not take your time and contribute some documentation?

Regards,

Ernesto

References,

1-http://code.google.com/p/wiquery-plugins/
2-https://github.com/hielkehoeve/wiquery-jqplot

On Thu, Apr 7, 2011 at 12:06 PM, Live Nono <[email protected]> wrote:
> 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]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to