RE: Wiquery experiences

2011-04-07 Thread Hielke Hoeve
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

2011-04-07 Thread Ioannis Canellos
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

2011-04-07 Thread Maarten Billemont

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

2011-04-07 Thread Live Nono
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

2011-04-07 Thread Ernesto Reinaldo Barreiro
, 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

2011-04-07 Thread Hielke Hoeve
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

2011-04-07 Thread Live Nono
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

2011-04-07 Thread Hielke Hoeve
 
-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

2011-04-07 Thread msj121
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



Wiquery experiences

2011-04-06 Thread haiko

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



Re: Wiquery experiences

2011-04-06 Thread Maarten Billemont
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

2011-04-06 Thread Bruno Borges
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

2011-04-06 Thread msj121
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