RE: Wiquery experiences
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:bruno.bor...@gmail.com] Sent: donderdag 7 april 2011 0:32 To: users@wicket.apache.org 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 lhun...@gmail.com 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, ha...@dds.nl wrote: Hi, We are thinking of using wiquery for a project. We are interested in the experiences
Re: Wiquery experiences
The best thing to do is use the right tool for the right job. I personally use both plain jquery and wiquery and I am happy with it. On Thu, Apr 7, 2011 at 10:54 AM, Hielke Hoeve hielke.ho...@topicus.nlwrote: 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:bruno.bor...@gmail.com] Sent: donderdag 7 april 2011 0:32 To: users@wicket.apache.org 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 lhun...@gmail.com 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
Re: Wiquery experiences
On 07 Apr 2011, at 09:54, Hielke Hoeve wrote:
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!
When I said Writing what *should* be JavaScript in your wicket Java code ...,
what I was referring to is things like (ref. wiQuery Quickstart):
JsScope.quickScope(alert('foo'));
to represent:
function() {
alert('foo');
}
Don't get me wrong, I'm sure wiQuery has its place and use. As I said, tightly
integrating jQuery components with your Wicket application logic is probably
much easier done with this abstraction layer.
It's just important to know that wiQuery isn't a requirement for being able to
do jQuery in a wicket application, or any sort of custom JS/AJAX for that
matter. And if wiQuery has indeed matured a lot, and you aren't at risk of
code injection, then sure, have at it - where it makes sense.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wiquery experiences
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 hielke.ho...@topicus.nl: 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:bruno.bor...@gmail.com] Sent: donderdag 7 april 2011 0:32 To: users@wicket.apache.org 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 lhun...@gmail.com 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
Re: Wiquery experiences
, 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:bruno.bor...@gmail.com] Sent: donderdag 7 april 2011 0:32 To: users@wicket.apache.org 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 lhun...@gmail.com 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, ha...@dds.nl 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wiquery experiences
The wiki is quite outdated, except for a small and somewhat hidden area: http://code.google.com/p/wiquery/wiki/QuickStart The WiQuery plugins project isn't really well known and our project site does not point to it, but it a good start to see how applications can be converted, as it also contains a simple WebApplication. Any other pointers as how to improve documentation and tutorials are most welcome! Hielke -Original Message- From: Ernesto Reinaldo Barreiro [mailto:reier...@gmail.com] Sent: donderdag 7 april 2011 12:26 To: users@wicket.apache.org Subject: Re: Wiquery experiences 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 liven...@gmail.com 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 hielke.ho...@topicus.nl: 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
Re: Wiquery experiences
Ernesto, Hielke thanks a lot for your answers At the time I looked at wiquery, it was for some specific task. This task didn't include explorating whether a full blown jquery/wicket integration framework would fit our needs. This is quite a task on its own imho, and there the lack of documentation is a real issue. For example, questions I had which would involve quite some time to figure out: - does wiquery support being used from a wicket ajax request nicely? If so, is it part of its intended aims and thus made across all its wrappers or just some of the wrapper being properly done? How does it handle the case of wiquery dependent component made visible through an ajax request? = Hielke already provided some answers which I'm glad to have read, but it doesn't cover it all - ease to use with other librairies, like JSLibraries (and its CDN integration) ? - reliability now and in the future: what about eventual bug I would find, would they be easy to fix on my own? Does the code make enough sense to me? In there a proper community around to help in case ? What's the plan for currently supported jquery versions and the future? = Ernesto also provided some answers, which is good, thanks :) I hope you understand better the questions which arise and why it would take a while to figure them out just by looking at the code. That's where more documentation/tutorial/feedbacks would help, to make the discovery cost lower. as a side note, I was already bitten by being early adopting some new frameworks, so now I tend to be more carefull, esp. for stuff that are directly seen by the users... regards - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wiquery experiences
-Original Message- From: msj121 [mailto:msj...@gmail.com] Sent: donderdag 7 april 2011 2:13 To: users@wicket.apache.org Subject: Re: Wiquery experiences I both agree and disagree with the aforementioned comments. I don't think anyone would disagree that writing JavaScript from wicket or using a decorator to write JavaScript is wrong. In fact quite often I may not know the id of an object until run-time and I may want the javascript to run on a specific textfield with no extra class names or additional tags marking it. To say that you need an extra .js file for a one-line or even 20 line simple js command is arguable I think. Hence we created the JsScope.quickScope(). However others, like Maarten, do not like this function as it allows people to write js code in a java class. There are more than 1 way to use WiQuery and everyone can use their favorite one. That being said, if you know JavaScript or jQuery, probably WiQuery is not the most necessary, it is really an object oriented interface to jQuery, not much more as I recall. That and resource manager. That is all it needs to be, because otherwise it would be slow, large in jar size and unmaintainable. The best advantage to WiQuery I find is that JQuery at page ready can run numerous sets of commands All you need to do with WiQuery is add these commands and they are all grouped together and run in a single document ready function. Similarly WiQuery will take care of keeping track of what object id to run the script against, JavaScript files to import etc It does simplify things, but do you NEED another library, some people want to keep as few dependencies as possible, some don't care. Remember the real engine is JQuery, WiQuery is just an interface to simplify. But look at writing javascript plainly in Wicket. If it is easy for you, probably don't bother, but if your getting a headache you might want to use WiQuery. Hooray for freedom of choice! :-) My main fear is how often it may be updated and how long will it be around. I have WiQuery in a current project I may take it out, I notice I mostly have been writing my own jQuery anyway. Since January we have released 4 new 1.2 versions in which we fixed a great deal of bugs and added new features, like the YUI compressor to compress resources when in production mode. We have started to work on a wicket 1.5 version and are nearing RC status. Hielke - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Wiquery experiences
Keep in mind I do use WiQuery myself primarily for the Resource Manager, my main point was that this is the main reason to use WiQuery, like you mentioned, and that it should only be viewed as an interface was in my opinion more of a compliment to well written code. And of course people who don't know jquery or javascript will gain a lot from WiQuery bypassing much of that knowledge. I do admit that there are regular updates to WiQuery, but there was some time where it did not convert its source jquery files to the newer versions of JQuery (which I understand requires testing etc... and cannot be done quickly), which I think now can be overriden more easily by the user. My other main fear is that with a couple of JQuery Wicket modules, which will stay and be adopted and which will go. I personally hope that WiQuery will continue to be updated and grow, but with only a couple of people as maintainers, I thought it could become extinct all of a sudden at any time. Though it is good to know that it is being used by an organization, which means there is monetary incentive for them to keep it afloat. But yes, I do think that WiQuery is a great project! Though I do need to one day solve issue 77, I am hoping with the new versions of wicket/wiquery it will have been somehow solved though I may have solved it by working around the problem which is probably better code. Hielke Hoeve-2 wrote: -Original Message- From: msj121 [mailto:msj...@gmail.com] Sent: donderdag 7 april 2011 2:13 To: users@wicket.apache.org Subject: Re: Wiquery experiences I both agree and disagree with the aforementioned comments. I don't think anyone would disagree that writing JavaScript from wicket or using a decorator to write JavaScript is wrong. In fact quite often I may not know the id of an object until run-time and I may want the javascript to run on a specific textfield with no extra class names or additional tags marking it. To say that you need an extra .js file for a one-line or even 20 line simple js command is arguable I think. Hence we created the JsScope.quickScope(). However others, like Maarten, do not like this function as it allows people to write js code in a java class. There are more than 1 way to use WiQuery and everyone can use their favorite one. That being said, if you know JavaScript or jQuery, probably WiQuery is not the most necessary, it is really an object oriented interface to jQuery, not much more as I recall. That and resource manager. That is all it needs to be, because otherwise it would be slow, large in jar size and unmaintainable. The best advantage to WiQuery I find is that JQuery at page ready can run numerous sets of commands All you need to do with WiQuery is add these commands and they are all grouped together and run in a single document ready function. Similarly WiQuery will take care of keeping track of what object id to run the script against, JavaScript files to import etc It does simplify things, but do you NEED another library, some people want to keep as few dependencies as possible, some don't care. Remember the real engine is JQuery, WiQuery is just an interface to simplify. But look at writing javascript plainly in Wicket. If it is easy for you, probably don't bother, but if your getting a headache you might want to use WiQuery. Hooray for freedom of choice! :-) My main fear is how often it may be updated and how long will it be around. I have WiQuery in a current project I may take it out, I notice I mostly have been writing my own jQuery anyway. Since January we have released 4 new 1.2 versions in which we fixed a great deal of bugs and added new features, like the YUI compressor to compress resources when in production mode. We have started to work on a wicket 1.5 version and are nearing RC status. Hielke - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wiquery-experiences-tp3430320p3433900.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wiquery experiences
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, ha...@dds.nl 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
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 lhun...@gmail.com 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, ha...@dds.nl 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: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wiquery experiences
I both agree and disagree with the aforementioned comments. I don't think anyone would disagree that writing javascript from wicket or using a decorator to write javascript is wrong. In fact quite often I may not know the id of an object until run-time and I may want the javascript to run on a specific textfield with no extra class names or additional tags marking it. To say that you need an extra .js file for a one-line or even 20 line simple js command is arguable I think. That being said, if you know javascript or jquery, probably WiQuery is not the most necessary, it is really an object oriented interface to jquery, not much more as I recall. The best advantage to wiquery I find is that JQuery at page ready can run numerous sets of commands All you need to do with WiQuery is add these commands and they are all grouped together and run in a single document ready function. Similarly WiQuery will take care of keeping track of what object id to run the script against, javascript files to import etc It does simplify things, but do you NEED another library, some people want to keep as few dependencies as possible, some don't care. Remember the real engine is JQuery, WiQuery is just an interface to simplify. But look at writing javascript plainly in Wicket. If it is easy for you, probably don't bother, but if your getting a headache you might want to use WiQuery. My main fear is how often it may be updated and how long will it be around. I have WiQuery in a current project I may take it out, I notice I mostly have been writing my own jquery anyway. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wiquery-experiences-tp3430320p3432209.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
