+1 for including support for cometd in wicket core
I expect server side push the next great thing in web development :)
my 2 pct
Am 26.08.2008 um 22:19 schrieb Matej Knopp:
Hi,
On Tue, Aug 26, 2008 at 9:24 PM, jWeekend
<[EMAIL PROTECTED]> wrote:
Matej,
What are the implications of the decision to "base Wicket Ajax Next
Generation on YUI" in terms of choosing a Javascript library for
future
Wicket based web front ends?
actually, there really are none. The use of YUI will be more or less
internal to Wicket, so you can continue using jQuery, YUI2 or whatever
else you are using. Everything in Wicket (and YUI) is namespaced so
there are no conflicts.
We too were tending towards jQuery, mainly because
+ code based on jQuery can be quite terse yet still easy to read and
elegant.
I think same goes for YUI, especially with YUI3 Node class.
+ it doesn't require any great Javascript expertise (in particular,
no
obvious cross-browser issues to worry about so far).
I don't see how this is different than what YUI does
+ it's got a small footprint and seems to be fast enough, even
using the
(really useful) CSS selectors.
CSS selectors are of no use for Wicket Ajax, of course they might be
useful for the actual application or other components. However YUI
also have CSS selectors, even though i haven't profiled them. Anyway,
in general i don't think that CSS selector speed matters too much. For
anything really have you would have to cache the results somehow (like
i did for grid).
+ there's huge number and variety of jQuery plugins for those
special
occasions.
Unfortunately the quality of plugins varies. For actual wicket ajax
implementation i prefer to stick with the core thing, and that's where
YUI definitely beats jquery. I don't say that there are no plugins for
jQuery that covers YUI functionality. Question is how well are those
plugins supported and maintained.
+ there's a big developer community/interest with plenty of reference
material, blogs etc...
+ the lack of any licensing concerns.
+ it's really easy to use and it just works.
Again, I don't see why this wouldn't apply to YUI as well.
Since you have no doubt carefully looked at the options and chosen
YUI as
the most appropriate for Wicket 1.5 (or, shall we just call it
Wicket 5),
and having seen the magic you have performed with your inmethod
grids, I
imagine that most of the above can be said for YUI too, and then
some.
Could be :)
So ... would it make more sense to start preferring YUI for use in
new
Wicket applications or will it not make any real difference which
Javascript
library is used by the application developer?
Really it won't. I used YUI because i liked it more. I went through
the jQuery source code when I was evaluating it and I found YUI to be
much more readable. This is a personal opinion though.
It's more about the approach. I like YUI approach to things. I like
the way the YUI API is designed. It like the things that are in YUI
core and that only are available as plugin to jquery.
Anyway, as I say, this doesn't make any implication to Wicket users or
3rd party components. The reason why wicket ajax is based on another
framework is to get rid of most of the low level browser specific code
we have currently so that I wouldn't have to maintain it :)
-Matej
Matej Knopp-2 wrote:
Hi,
I haven't announced yet publicly but for some time I was working on
Ajax implementation for 1.5.
The work is available in
/repos/asf/wicket/sandbox/knopp/experimental/wicket
I will put together a wiki page when I have some free time.
I have of course considered jquery. I gave it a proper look but I
decided to go with YUI instead because I like it's approach more.
Also
some functionality that YUI provides in core (dom manipulations) is
only available as plugin to Jquery. New Wicket Ajax the is based on
YUI3 which provides new node module that allows method chaining and
kinda feels like jquery.
Also personally I consider YUI source code much more readable than
jquery
-Matej
On Tue, Aug 26, 2008 at 6:10 PM, Scott Swank <[EMAIL PROTECTED]>
wrote:
Has jquery been considered for WANG, or am I coming into this
conversation late?
Scott
On Tue, Aug 26, 2008 at 5:51 AM, Martijn Dashorst
<[EMAIL PROTECTED]> wrote:
Probably something for 1.5 (with WANG–Wicket Ajax Next
Generation–being based on YUI)
Martijn
On Tue, Aug 26, 2008 at 2:25 PM, Nino Saturnino Martinez Vazquez
Wael
<[EMAIL PROTECTED]> wrote:
I've been hearing some rants on how merging resources can up the
performance, should wicket be able todo this? I mean merging
several
css's
into one etc.. I know it wont work for dynamic css/js/images.
But on
static
it could, even yslow recommends you merge your resources into
one...
Images
might be stretching it too far?
WDYT?
http://workingwithrails.com/railsplugin/5317-asset-packager
http://www.kaboomerang.com/blog/2007/11/29/getting-to-10-actiontastic-actionatr-gwt-and-automagic-rest/
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
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]
--
View this message in context:
http://www.nabble.com/%22WANG%E2%80%93Wicket-Ajax-Next-Generation%E2%80%93being-based-on-YUI%22-%28MD%29-tp19168620p19168620.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
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]
