Given the fact that there is already wicket-jquery in wicketstoff-core,
I wonder how come it is simply possible to add another JQuery
integration to wicketstuff. What are the rules for adding stuff there?
Can committers just do whatever the like? Doesn't there have to be some
voting on the mailing list for things like that? If I was to add yet
another JQuery integration, could I just put it in there as well?
I'm currently doing a Wicket evaluation. Wicket may become one of the
standard frameworks of the company I work for. I really like what I've
seen so far, and working with Wicket can be really fun. But what looks
pretty messy to me is the way things are organized (documentation, wiki,
wicketstuff). To me wicketstuff presents itself as some inofficial
playground with lots of badly documented things in it. However,
wicketstuff-core (which is not even listed on the wicketstuff wiki
(except for a migration guide)) seems to have a somewhat more official
character. May the latter be taken as a production-ready supplement to
Wicket? I'd appreciate it if some restructuring and clarification came
along with the upcoming 1.4 release.
Thanks,
Reinhard
Tauren Mills schrieb:
Hi Richard,
I actually tried out WiQuery before deciding it wasn't the right tool
for me. I can't remember the exact specifics of the issues I had with
it, and I only spent about a day with it. But I remember feeling like
I was being forced to use it whenever and wherever I wanted to add ANY
jQuery to my project.
I can see how WiQuery would be good for a developer who doesn't want
to touch JS, and only code in Java. With WiQuery, I can add all the
functionality I need via the WiQuery API. I have nothing against the
project in this regard, it seems like a great solution for that
situation.
But in my case, I want a wicket/jquery tool that is lightweight and
stays out of my way. I would rather code client-side only stuff just
in jQuery and not have anything necessary in my server code. The only
time I want wicket components to be aware of my jQuery code is if
there needs to be some client-server ajax communication. For instance,
drag/drop information, or sorting a list of item, etc.
From my perspective, I could care less if wicket knows which accordion
panel is open in the browser, because *for my application*, that
doesn't matter. And I do realize there are *other applications* that
this would matter, for which an optional WiQuery accordion plugin
would be userful.
And when I want to use another add-on jQuery plugin such as
superfish.js, I don't want to have to resort to WiQuery hacks or to
create my own WiQuery plugin to support it. I am constantly adding
little jQuery code here and there, and to have to make WiQuery plugins
for it all or to code it using the WiQuery API would be a pain that
I'm not willing to put up with.
The following posting I made might give a little more insight into the
reason I stopped using WiQuery:
http://groups.google.com/group/wiquery/browse_thread/thread/190fc243777ea3ba/492092296e40fe10?lnk=gst&q=tauren#492092296e40fe10
I had already found WicketJQuery at the time I tried out WiQuery.
WiQuery seemed further along and was easier to add into my
application, so I tried it first. But when it failed for me, I gave
WicketJQuery a try. At the moment, WicketJQuery (now jWicket)
certainly isn't perfect either, but it is closer to meeting my needs.
So I offered my help to Stefan to get it mavenized and moved to
WicketStuff. We renamed it to jWicket during this transition. This
new location will make it more accessible and easier to use for other
developers.
Of course, I have nothing against joining forces, but I also needed
something to solve a problem, and I needed it now. WiQuery wasn't
doing it for me, and jWicket was. I also want a light weight tool, and
I felt like WiQuery was overkill for my needs. If there is a way to
join forces so that one tool can satisfy everyone without becoming
some big bloated thing, then I'm all for it!
Bottom line is I just want to be able to easily add jQuery code to the
client side whenever and wherever I want without having to deal with
server side code -- except for when I need client/server communication
of jQuery events. Maybe I'm not normal in this regard, but the
WiQuery API just doesn't do it for me. I'd rather code the client side
in JS/jQuery and keep it out of my java code.
Sorry for being long winded. Again, I have nothing against WiQuery,
and was quite impressed by it. But it just didn't seem like the right
tool for my needs. I'm certainly open to ideas on how to integrate the
projects, but from what I can tell, they really have different
visions.
Tauren
On Wed, Jul 22, 2009 at 11:15 AM,
richardwilko<richardjohnwilkin...@gmail.com> wrote:
Hi,
What are the advantages of jWicket over other Wicket jQuery projects
(specifically wiQuery)?
It would be nice if we could all work together on a single project. wiQuery
has already pooled the development resources of two other such projects.
wiQuery has Wicket behaviours for the core jQuery events / actions and
jQuery UI components. It also has a nice plugin mechanism for adding other
jQuery widgets / behaviours and it is under active development.
At jWeekend we have also just designed, developed and are testing a server
side state mechanism for wiQuery components.
Regards - Richard
jWeekend
OO, Wicket, Java Technologies - Training and Consultancy
http://jWeekend.com
Lionel Armanet wrote:
Hi,
Just to talk, there's another jQuery-Wicket integration project called
"WiQuery" (http://code.google.com/p/wiquery/) and supported by jWeekend
(http://www.jweekend.com/dev/LWUGReg/). Did you look at this project too ?
Lionel
tauren wrote:
jWicket has now been released as a wicketstuff project. jWicket is an
integration of Wicket and jQuery that was previously called
WicketJQuery (by Stefan Lindner). I realize there are already a few
Wicket/jQuery integrations, but I think that Stefan's WicketJQuery
implementation has some advantages over the others.
Stefan and I discussed how to best move the WicketJQuery project
forward and decided it was best if it became a standard maven project
to make it easy for others to use. We decided to host it at
wicketstuff so that it would be available via a maven repository. We
also decided to rename it since there were already wicketstuff
projects with very similar names. So it will now be known as
"jWicket".
At this point, the code committed to WicketStuff is essentially the
same codebase available on the original WicketJQuery SVN server. I
have refactored it with the org.wicketstuff.jwicket namespace and have
structured the project in a standard maven manner. I also split the
project into jwicket-parent, jwicket, and jwicket-examples. The demo
app is now separate from jwicket itself so that it doesn't need to be
imported into projects.
The original WIcketJQuery project developed by Stefan Lindner can be
found at:
http://subversion.visionet.de/project/WicketJQuery/wiki
Tauren
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-----
http://richard-wilkinson.co.uk My blog: http://richard-wilkinson.co.uk
--
View this message in context:
http://www.nabble.com/jWicket----jQuery-with-Wicket-integration-tp24584280p24611730.html
Sent from the Wicket - User 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
---------------------------------------------------------------------
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
