You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Jörn Zaefferer <jo...@googlemail.com> on 2008/09/29 04:01:48 UTC
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
There is something new to consider when choosing a JavaScript library
as Wicket's base:
http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
Jörn
On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com> wrote:
> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
> <jo...@googlemail.com> wrote:
>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>> Hi,
>>>
>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <jw...@cabouge.com> 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.
>>
>> Of course there is the overhead of including two or more libraries in
>> an application, which don't find desirable.
>
> Wicket uses only part of YUI, the compressed minified required YUI
> javascript is about 20kb big. I would understand the concern if I used
> dojo or some other behemoth with 200+ kb of compressed javascript.
>
>>
>>>> + 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.
>>
>> You are well on the point that the variety of plugins varies. I see it
>> this way: jQuery core is small, very stable and the base for
>> everything else JS-related. jQuery UI is the official project
>> providing the same stability and quality for various high-level UI
>> components (like dialogs) and also low-level components (like
>> drag&drop, sortables). We'll see at least two major releases this year
>> that add more components to the mix. Anything else that isn't covered
>> by core or UI is almost always covered by some third-party plugin.
>> While these plugin can be of bady quality (eg. no
>> documentation/demos), they can still provide a good starting point, so
>> that you don't have to start from scratch. Even if you do a full
>> rewrite, the existing plugin can expose useful information like
>> potential browser-bug-traps.
> Problem is that the jQuery core doesn't cut it. And rewriting plugins
> from scratch? Are you serious? This is exactly the reason why I
> decided to use YUI. The stuff that I need is there, it is supported
> and maintained.
>>
>>> 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 :)
>>
>> Whatever the framework, I think its a good idea to start with
>> something well supported and tested. Thats why I use Wicket, though
>> I'd like it even more with jQuery as the base framework :-)
>
> At this point, I really don't see any advantage that YUI would give me
> over jQuery.
> Also it is possible that InMethod grid will be part of Wicket 1.5
> extensions which is another point for using YUI. Rewriting the grid
> with jquery would be a huge pain.
>
> -Matej
>
>>
>> Jörn
>>
>> PS: Comet support is a nice to have, but I think there a way more
>> important things for core than that, eg. annotation-based validation
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Scott Swank <sc...@gmail.com>.
And Nokia
http://www.s60.com/life/thisiss60/s60indetail/technologiesandfeatures/webruntime
http://www.s60.com/life/thisiss60/s60indetail/technologiesandfeatures/webruntime/webruntimedetail
On Sun, Sep 28, 2008 at 7:01 PM, Jörn Zaefferer
<jo...@googlemail.com> wrote:
> There is something new to consider when choosing a JavaScript library
> as Wicket's base:
> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
>
> Jörn
>
> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com> wrote:
>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>> <jo...@googlemail.com> wrote:
>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <jw...@cabouge.com> 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.
>>>
>>> Of course there is the overhead of including two or more libraries in
>>> an application, which don't find desirable.
>>
>> Wicket uses only part of YUI, the compressed minified required YUI
>> javascript is about 20kb big. I would understand the concern if I used
>> dojo or some other behemoth with 200+ kb of compressed javascript.
>>
>>>
>>>>> + 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.
>>>
>>> You are well on the point that the variety of plugins varies. I see it
>>> this way: jQuery core is small, very stable and the base for
>>> everything else JS-related. jQuery UI is the official project
>>> providing the same stability and quality for various high-level UI
>>> components (like dialogs) and also low-level components (like
>>> drag&drop, sortables). We'll see at least two major releases this year
>>> that add more components to the mix. Anything else that isn't covered
>>> by core or UI is almost always covered by some third-party plugin.
>>> While these plugin can be of bady quality (eg. no
>>> documentation/demos), they can still provide a good starting point, so
>>> that you don't have to start from scratch. Even if you do a full
>>> rewrite, the existing plugin can expose useful information like
>>> potential browser-bug-traps.
>> Problem is that the jQuery core doesn't cut it. And rewriting plugins
>> from scratch? Are you serious? This is exactly the reason why I
>> decided to use YUI. The stuff that I need is there, it is supported
>> and maintained.
>>>
>>>> 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 :)
>>>
>>> Whatever the framework, I think its a good idea to start with
>>> something well supported and tested. Thats why I use Wicket, though
>>> I'd like it even more with jQuery as the base framework :-)
>>
>> At this point, I really don't see any advantage that YUI would give me
>> over jQuery.
>> Also it is possible that InMethod grid will be part of Wicket 1.5
>> extensions which is another point for using YUI. Rewriting the grid
>> with jquery would be a huge pain.
>>
>> -Matej
>>
>>>
>>> Jörn
>>>
>>> PS: Comet support is a nice to have, but I think there a way more
>>> important things for core than that, eg. annotation-based validation
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Jörn Zaefferer <jo...@googlemail.com>.
Wicket.replaceOuterHTML(element, "<newmarkup>"); would be this in jQuery:
$(element).after("<newmarkup>").remove();
That inserts the new stuff after the element, then removes the
element, leaving only the new content in the DOM. after() takes care
of cleanup stuff for table colgroups, rows and cells, legends, options
and so on.
Jörn
On Mon, Sep 29, 2008 at 11:31 PM, Matej Knopp <ma...@gmail.com> wrote:
> On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
> <jo...@googlemail.com> wrote:
>> I guess I didn't quite get the file upload example in the first place.
>> Uploading via iframe is supported by jQuery's form plugin, which is
>> one of the best plugins we have. We plan to add it, together with
>> other related plugins, to jQuery UI forms (or something like that).
> Well, that's what I'm talking about. It's a separate plugin. I don't
> know how good the plugin is. How actively it is mantained. Can I rely
> on it? Those are the questions I do not need to ask when dealing with
> YUI.
>>
>> About selectors: jQuery promotes progressive enhancement a lot, and
>> selectors are essential for that. One example for that is that we
>> avoid inline onclick=".." and similar stuff. I'm not sure how that
>> would be handled by Wicket, and if using jQuery would open ways to
>> handle things differently.
>
> In wicket 1.5 there won't be any inline handlers in the markup. All
> events will be attached separately.
>
>>
>> I can't give you too many details on replaceOuterHtml, though that
>> sounds like I can easily get more info on. Currently jQuery does a lot
>> of work cleaning html input that is appended into the DOM, which seems
>> to be basically the same usecase here. Also executing script-tags is
>> something we cover.
>> Could you give me an example how exactly replaceOuterHTML is currently used?
>
> It is used every time Ajax request replaces component on page.
> Wicket.replaceOuterHTML(element, "<newmarkup>");
> It replaces the element (the tag itself) with the new markup.
> But it takes care of some things such as when the element is a table
> row or cell, or if there are script tag embedded in the markup.
>
>>
>> About the Microsoft argument: True, from a technical perspective that
>> doesn't matter. But its an important political aspect: I already read
>> a few comments from people that couldn't use jQuery due to a general
>> "no open-source" policy - but now that Microsoft, that had exactly
>> that policy, is changed theirs, it could enable others to adopt it,
>> too.
>
> Well, I consider YAHOO to be a player that is major enough when the
> political questions arise.
> As for Microsoft and it's "no open-source" policy, well, until vista
> they have been using BSD network stack and had no problems with that
> as far as i can tell :)
>
> -Matej
>
>>
>> Jörn
>>
>> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
>> Dojo, YUI and jQuery. One question was: "What library would you
>> recommend but your own?". Two of the three non-jQuery guys recommened
>> jQuery
>>
>> On Mon, Sep 29, 2008 at 1:41 PM, Matej Knopp <ma...@gmail.com> wrote:
>>> On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer
>>> <jo...@googlemail.com> wrote:
>>>> It would be a big plus for me if Wicket would adopt jQuery. Drupal
>>>> does that, and anyone writing a Drupal module can rely on the fact
>>>> that jQuery is available. Same for Wordpress, where plugin authors can
>>>> rely on the availability of jQuery. And not having to load more than
>>>> one library, internal or not, is a good thing performance-wise.
>>>>
>>>> In response to your examples:
>>>>
>>>> Unbinding only particular event handlers without having a reference to
>>>> the handler function can be achieved with namespaces:
>>>> $(element).bind("click.somethingUnique", handleClick);
>>>> $(element).unbind("click.somethingUnique");
>>>
>>> But that's not quite the same. This requires me to use generate and
>>> keep a unique string. Anyway, this is a cosmetic issue only.
>>>
>>>>
>>>> That way you don't have to keep a reference at all, while its possible
>>>> to group multiple events into one namespace. This is now heavily used
>>>> by most jQuery UI components when destroyed, to clean up their own
>>>> event handlers without affecting any other.
>>>>
>>>> Multiple file upload we'll eventually have as part of jQuery UI. That
>>>> would then be the same level of official and supported component that
>>>> YUI provides. The descision to add new components is partly
>>>> community-driven. So if you think multipart ajax uploads should be
>>>> added, just ask for it.
>>> This is not about "multiple file upload". We already have such
>>> component in Wicket. This is about support for <input type="file"> on
>>> ajax uploads - just use hidden frame instead of xml http request.
>>>
>>>>
>>>> About selectors: John Resig is currently working on a new selector
>>>> engine that likely outperformances any other selector engine available
>>>> so far. Its developed as a standalone library, so its likely that
>>>> MochKit and Prototype will use it, too.
>>> That sure is nice, but the selectors are not used in Wicket core at all.
>>>
>>>> jQuery 1.3. will also provide heavy performance improvements for DOM
>>>> manipulations, which I'm very exited about as that is usually where
>>>> most time is spent. Its easy to avoid running certain selectors too
>>>> often, but its hard to optimize DOM manipulation in clientcode.
>>>
>>> While we at this, I'd like to ask. Significant part of Wicket ajax is
>>> Wicket.replaceOuterHtml method. This was really a major pain to
>>> implement and stabilize. What it does is basically a replaceOuterHTML
>>> call for all browser but it works in totally cross browser consistent
>>> way. I.e. it allows table rows, cells etc replaced in internet
>>> explorer and it also executes embedded <script> tags on browsers that
>>> would normally not do that (basically all except for Firefox). So my
>>> question is, just out of curiosity, is there/will there be similar
>>> functionality provided by jQuery?
>>>>
>>>> Anyway, thanks for taking the time to discuss this again.
>>>
>>> Sure. Keep in mind that the decision is not carved to stone. I'm open
>>> to argument, but I'm really interested in technical aspect. Having
>>> "Microsoft will use jQuery" is not really a valid argument to me :)
>>>
>>> -Matej
>>>
>>>>
>>>> Jörn
>>>>
>>>> On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>>> Are you really that surprised that Microsoft is not shipping YUI after
>>>>> the failed attempts to take over Yahoo? :)
>>>>>
>>>>> Seriously, there are technical reasons why I considered to use YUI,
>>>>> not political. Just because some companies use jQuery it doesn't mean
>>>>> Wicket should use it. Say most of the companies use JSF, does it mean
>>>>> we should?
>>>>>
>>>>> As I said, I really like the way YUI api is designed. Also there are
>>>>> things in YUI "core" that are only available as jQuery plugins. The
>>>>> plugins have different lifecycle than the core and are mantained
>>>>> differently.
>>>>>
>>>>> Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket.
>>>>>
>>>>> Let me give you an example where I find YUI (3) api more elegant.
>>>>> That's just one of many things and it is of course my personal
>>>>> opinion.
>>>>>
>>>>> If i want to unbind event in jQuery, i need to remember event name and
>>>>> the exact handler instance. For YUI, i get event handler on bind that
>>>>> i can just call detach on and the event is unbound.
>>>>>
>>>>> var h = Y.on("click", handleClick, element);
>>>>> h.detach();
>>>>>
>>>>> Of course it is possible to mock the behavior with jQuery, but that's
>>>>> not really the point, is it?
>>>>>
>>>>> Another this is functionality provided in core. YUI can handle
>>>>> multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's
>>>>> very likely it will be as it was supported in 2.x). For jQuery, i need
>>>>> to use a plugin for it.
>>>>>
>>>>> The reason why I feel so uneasy about plugins is that I've tried some.
>>>>> And the quality really varies.
>>>>>
>>>>> I think selectors might be the part where jQuery really shines. But
>>>>> that's the part not needed by Wicket at all. Plus YUI has selectors
>>>>> too (although maybe not that fast - I don't know, haven't profiled
>>>>> them). Also the new YUI3 node API resembles jQuery chaining API for
>>>>> those who like it.
>>>>>
>>>>> -Matej
>>>>>
>>>>> On Mon, Sep 29, 2008 at 4:01 AM, Jörn Zaefferer
>>>>> <jo...@googlemail.com> wrote:
>>>>>> There is something new to consider when choosing a JavaScript library
>>>>>> as Wicket's base:
>>>>>> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
>>>>>> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
>>>>>>
>>>>>> Jörn
>>>>>>
>>>>>> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com> wrote:
>>>>>>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>>>>>>> <jo...@googlemail.com> wrote:
>>>>>>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <jw...@cabouge.com> 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.
>>>>>>>>
>>>>>>>> Of course there is the overhead of including two or more libraries in
>>>>>>>> an application, which don't find desirable.
>>>>>>>
>>>>>>> Wicket uses only part of YUI, the compressed minified required YUI
>>>>>>> javascript is about 20kb big. I would understand the concern if I used
>>>>>>> dojo or some other behemoth with 200+ kb of compressed javascript.
>>>>>>>
>>>>>>>>
>>>>>>>>>> + 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.
>>>>>>>>
>>>>>>>> You are well on the point that the variety of plugins varies. I see it
>>>>>>>> this way: jQuery core is small, very stable and the base for
>>>>>>>> everything else JS-related. jQuery UI is the official project
>>>>>>>> providing the same stability and quality for various high-level UI
>>>>>>>> components (like dialogs) and also low-level components (like
>>>>>>>> drag&drop, sortables). We'll see at least two major releases this year
>>>>>>>> that add more components to the mix. Anything else that isn't covered
>>>>>>>> by core or UI is almost always covered by some third-party plugin.
>>>>>>>> While these plugin can be of bady quality (eg. no
>>>>>>>> documentation/demos), they can still provide a good starting point, so
>>>>>>>> that you don't have to start from scratch. Even if you do a full
>>>>>>>> rewrite, the existing plugin can expose useful information like
>>>>>>>> potential browser-bug-traps.
>>>>>>> Problem is that the jQuery core doesn't cut it. And rewriting plugins
>>>>>>> from scratch? Are you serious? This is exactly the reason why I
>>>>>>> decided to use YUI. The stuff that I need is there, it is supported
>>>>>>> and maintained.
>>>>>>>>
>>>>>>>>> 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 :)
>>>>>>>>
>>>>>>>> Whatever the framework, I think its a good idea to start with
>>>>>>>> something well supported and tested. Thats why I use Wicket, though
>>>>>>>> I'd like it even more with jQuery as the base framework :-)
>>>>>>>
>>>>>>> At this point, I really don't see any advantage that YUI would give me
>>>>>>> over jQuery.
>>>>>>> Also it is possible that InMethod grid will be part of Wicket 1.5
>>>>>>> extensions which is another point for using YUI. Rewriting the grid
>>>>>>> with jquery would be a huge pain.
>>>>>>>
>>>>>>> -Matej
>>>>>>>
>>>>>>>>
>>>>>>>> Jörn
>>>>>>>>
>>>>>>>> PS: Comet support is a nice to have, but I think there a way more
>>>>>>>> important things for core than that, eg. annotation-based validation
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Matej Knopp <ma...@gmail.com>.
On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
<jo...@googlemail.com> wrote:
> I guess I didn't quite get the file upload example in the first place.
> Uploading via iframe is supported by jQuery's form plugin, which is
> one of the best plugins we have. We plan to add it, together with
> other related plugins, to jQuery UI forms (or something like that).
Well, that's what I'm talking about. It's a separate plugin. I don't
know how good the plugin is. How actively it is mantained. Can I rely
on it? Those are the questions I do not need to ask when dealing with
YUI.
>
> About selectors: jQuery promotes progressive enhancement a lot, and
> selectors are essential for that. One example for that is that we
> avoid inline onclick=".." and similar stuff. I'm not sure how that
> would be handled by Wicket, and if using jQuery would open ways to
> handle things differently.
In wicket 1.5 there won't be any inline handlers in the markup. All
events will be attached separately.
>
> I can't give you too many details on replaceOuterHtml, though that
> sounds like I can easily get more info on. Currently jQuery does a lot
> of work cleaning html input that is appended into the DOM, which seems
> to be basically the same usecase here. Also executing script-tags is
> something we cover.
> Could you give me an example how exactly replaceOuterHTML is currently used?
It is used every time Ajax request replaces component on page.
Wicket.replaceOuterHTML(element, "<newmarkup>");
It replaces the element (the tag itself) with the new markup.
But it takes care of some things such as when the element is a table
row or cell, or if there are script tag embedded in the markup.
>
> About the Microsoft argument: True, from a technical perspective that
> doesn't matter. But its an important political aspect: I already read
> a few comments from people that couldn't use jQuery due to a general
> "no open-source" policy - but now that Microsoft, that had exactly
> that policy, is changed theirs, it could enable others to adopt it,
> too.
Well, I consider YAHOO to be a player that is major enough when the
political questions arise.
As for Microsoft and it's "no open-source" policy, well, until vista
they have been using BSD network stack and had no problems with that
as far as i can tell :)
-Matej
>
> Jörn
>
> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
> Dojo, YUI and jQuery. One question was: "What library would you
> recommend but your own?". Two of the three non-jQuery guys recommened
> jQuery
>
> On Mon, Sep 29, 2008 at 1:41 PM, Matej Knopp <ma...@gmail.com> wrote:
>> On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer
>> <jo...@googlemail.com> wrote:
>>> It would be a big plus for me if Wicket would adopt jQuery. Drupal
>>> does that, and anyone writing a Drupal module can rely on the fact
>>> that jQuery is available. Same for Wordpress, where plugin authors can
>>> rely on the availability of jQuery. And not having to load more than
>>> one library, internal or not, is a good thing performance-wise.
>>>
>>> In response to your examples:
>>>
>>> Unbinding only particular event handlers without having a reference to
>>> the handler function can be achieved with namespaces:
>>> $(element).bind("click.somethingUnique", handleClick);
>>> $(element).unbind("click.somethingUnique");
>>
>> But that's not quite the same. This requires me to use generate and
>> keep a unique string. Anyway, this is a cosmetic issue only.
>>
>>>
>>> That way you don't have to keep a reference at all, while its possible
>>> to group multiple events into one namespace. This is now heavily used
>>> by most jQuery UI components when destroyed, to clean up their own
>>> event handlers without affecting any other.
>>>
>>> Multiple file upload we'll eventually have as part of jQuery UI. That
>>> would then be the same level of official and supported component that
>>> YUI provides. The descision to add new components is partly
>>> community-driven. So if you think multipart ajax uploads should be
>>> added, just ask for it.
>> This is not about "multiple file upload". We already have such
>> component in Wicket. This is about support for <input type="file"> on
>> ajax uploads - just use hidden frame instead of xml http request.
>>
>>>
>>> About selectors: John Resig is currently working on a new selector
>>> engine that likely outperformances any other selector engine available
>>> so far. Its developed as a standalone library, so its likely that
>>> MochKit and Prototype will use it, too.
>> That sure is nice, but the selectors are not used in Wicket core at all.
>>
>>> jQuery 1.3. will also provide heavy performance improvements for DOM
>>> manipulations, which I'm very exited about as that is usually where
>>> most time is spent. Its easy to avoid running certain selectors too
>>> often, but its hard to optimize DOM manipulation in clientcode.
>>
>> While we at this, I'd like to ask. Significant part of Wicket ajax is
>> Wicket.replaceOuterHtml method. This was really a major pain to
>> implement and stabilize. What it does is basically a replaceOuterHTML
>> call for all browser but it works in totally cross browser consistent
>> way. I.e. it allows table rows, cells etc replaced in internet
>> explorer and it also executes embedded <script> tags on browsers that
>> would normally not do that (basically all except for Firefox). So my
>> question is, just out of curiosity, is there/will there be similar
>> functionality provided by jQuery?
>>>
>>> Anyway, thanks for taking the time to discuss this again.
>>
>> Sure. Keep in mind that the decision is not carved to stone. I'm open
>> to argument, but I'm really interested in technical aspect. Having
>> "Microsoft will use jQuery" is not really a valid argument to me :)
>>
>> -Matej
>>
>>>
>>> Jörn
>>>
>>> On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>> Are you really that surprised that Microsoft is not shipping YUI after
>>>> the failed attempts to take over Yahoo? :)
>>>>
>>>> Seriously, there are technical reasons why I considered to use YUI,
>>>> not political. Just because some companies use jQuery it doesn't mean
>>>> Wicket should use it. Say most of the companies use JSF, does it mean
>>>> we should?
>>>>
>>>> As I said, I really like the way YUI api is designed. Also there are
>>>> things in YUI "core" that are only available as jQuery plugins. The
>>>> plugins have different lifecycle than the core and are mantained
>>>> differently.
>>>>
>>>> Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket.
>>>>
>>>> Let me give you an example where I find YUI (3) api more elegant.
>>>> That's just one of many things and it is of course my personal
>>>> opinion.
>>>>
>>>> If i want to unbind event in jQuery, i need to remember event name and
>>>> the exact handler instance. For YUI, i get event handler on bind that
>>>> i can just call detach on and the event is unbound.
>>>>
>>>> var h = Y.on("click", handleClick, element);
>>>> h.detach();
>>>>
>>>> Of course it is possible to mock the behavior with jQuery, but that's
>>>> not really the point, is it?
>>>>
>>>> Another this is functionality provided in core. YUI can handle
>>>> multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's
>>>> very likely it will be as it was supported in 2.x). For jQuery, i need
>>>> to use a plugin for it.
>>>>
>>>> The reason why I feel so uneasy about plugins is that I've tried some.
>>>> And the quality really varies.
>>>>
>>>> I think selectors might be the part where jQuery really shines. But
>>>> that's the part not needed by Wicket at all. Plus YUI has selectors
>>>> too (although maybe not that fast - I don't know, haven't profiled
>>>> them). Also the new YUI3 node API resembles jQuery chaining API for
>>>> those who like it.
>>>>
>>>> -Matej
>>>>
>>>> On Mon, Sep 29, 2008 at 4:01 AM, Jörn Zaefferer
>>>> <jo...@googlemail.com> wrote:
>>>>> There is something new to consider when choosing a JavaScript library
>>>>> as Wicket's base:
>>>>> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
>>>>> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
>>>>>
>>>>> Jörn
>>>>>
>>>>> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com> wrote:
>>>>>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>>>>>> <jo...@googlemail.com> wrote:
>>>>>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <jw...@cabouge.com> 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.
>>>>>>>
>>>>>>> Of course there is the overhead of including two or more libraries in
>>>>>>> an application, which don't find desirable.
>>>>>>
>>>>>> Wicket uses only part of YUI, the compressed minified required YUI
>>>>>> javascript is about 20kb big. I would understand the concern if I used
>>>>>> dojo or some other behemoth with 200+ kb of compressed javascript.
>>>>>>
>>>>>>>
>>>>>>>>> + 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.
>>>>>>>
>>>>>>> You are well on the point that the variety of plugins varies. I see it
>>>>>>> this way: jQuery core is small, very stable and the base for
>>>>>>> everything else JS-related. jQuery UI is the official project
>>>>>>> providing the same stability and quality for various high-level UI
>>>>>>> components (like dialogs) and also low-level components (like
>>>>>>> drag&drop, sortables). We'll see at least two major releases this year
>>>>>>> that add more components to the mix. Anything else that isn't covered
>>>>>>> by core or UI is almost always covered by some third-party plugin.
>>>>>>> While these plugin can be of bady quality (eg. no
>>>>>>> documentation/demos), they can still provide a good starting point, so
>>>>>>> that you don't have to start from scratch. Even if you do a full
>>>>>>> rewrite, the existing plugin can expose useful information like
>>>>>>> potential browser-bug-traps.
>>>>>> Problem is that the jQuery core doesn't cut it. And rewriting plugins
>>>>>> from scratch? Are you serious? This is exactly the reason why I
>>>>>> decided to use YUI. The stuff that I need is there, it is supported
>>>>>> and maintained.
>>>>>>>
>>>>>>>> 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 :)
>>>>>>>
>>>>>>> Whatever the framework, I think its a good idea to start with
>>>>>>> something well supported and tested. Thats why I use Wicket, though
>>>>>>> I'd like it even more with jQuery as the base framework :-)
>>>>>>
>>>>>> At this point, I really don't see any advantage that YUI would give me
>>>>>> over jQuery.
>>>>>> Also it is possible that InMethod grid will be part of Wicket 1.5
>>>>>> extensions which is another point for using YUI. Rewriting the grid
>>>>>> with jquery would be a huge pain.
>>>>>>
>>>>>> -Matej
>>>>>>
>>>>>>>
>>>>>>> Jörn
>>>>>>>
>>>>>>> PS: Comet support is a nice to have, but I think there a way more
>>>>>>> important things for core than that, eg. annotation-based validation
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Igor Vaynberg <ig...@gmail.com>.
and what happens when microsoft forks jquery and hires all of its
developers to work on its proprietary version? to me this is more a
risk then anything else....
-igor
On Mon, Sep 29, 2008 at 2:13 PM, Jörn Zaefferer
<jo...@googlemail.com> wrote:
> I guess I didn't quite get the file upload example in the first place.
> Uploading via iframe is supported by jQuery's form plugin, which is
> one of the best plugins we have. We plan to add it, together with
> other related plugins, to jQuery UI forms (or something like that).
>
> About selectors: jQuery promotes progressive enhancement a lot, and
> selectors are essential for that. One example for that is that we
> avoid inline onclick=".." and similar stuff. I'm not sure how that
> would be handled by Wicket, and if using jQuery would open ways to
> handle things differently.
>
> I can't give you too many details on replaceOuterHtml, though that
> sounds like I can easily get more info on. Currently jQuery does a lot
> of work cleaning html input that is appended into the DOM, which seems
> to be basically the same usecase here. Also executing script-tags is
> something we cover.
> Could you give me an example how exactly replaceOuterHTML is currently used?
>
> About the Microsoft argument: True, from a technical perspective that
> doesn't matter. But its an important political aspect: I already read
> a few comments from people that couldn't use jQuery due to a general
> "no open-source" policy - but now that Microsoft, that had exactly
> that policy, is changed theirs, it could enable others to adopt it,
> too.
>
> Jörn
>
> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
> Dojo, YUI and jQuery. One question was: "What library would you
> recommend but your own?". Two of the three non-jQuery guys recommened
> jQuery
>
> On Mon, Sep 29, 2008 at 1:41 PM, Matej Knopp <ma...@gmail.com> wrote:
>> On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer
>> <jo...@googlemail.com> wrote:
>>> It would be a big plus for me if Wicket would adopt jQuery. Drupal
>>> does that, and anyone writing a Drupal module can rely on the fact
>>> that jQuery is available. Same for Wordpress, where plugin authors can
>>> rely on the availability of jQuery. And not having to load more than
>>> one library, internal or not, is a good thing performance-wise.
>>>
>>> In response to your examples:
>>>
>>> Unbinding only particular event handlers without having a reference to
>>> the handler function can be achieved with namespaces:
>>> $(element).bind("click.somethingUnique", handleClick);
>>> $(element).unbind("click.somethingUnique");
>>
>> But that's not quite the same. This requires me to use generate and
>> keep a unique string. Anyway, this is a cosmetic issue only.
>>
>>>
>>> That way you don't have to keep a reference at all, while its possible
>>> to group multiple events into one namespace. This is now heavily used
>>> by most jQuery UI components when destroyed, to clean up their own
>>> event handlers without affecting any other.
>>>
>>> Multiple file upload we'll eventually have as part of jQuery UI. That
>>> would then be the same level of official and supported component that
>>> YUI provides. The descision to add new components is partly
>>> community-driven. So if you think multipart ajax uploads should be
>>> added, just ask for it.
>> This is not about "multiple file upload". We already have such
>> component in Wicket. This is about support for <input type="file"> on
>> ajax uploads - just use hidden frame instead of xml http request.
>>
>>>
>>> About selectors: John Resig is currently working on a new selector
>>> engine that likely outperformances any other selector engine available
>>> so far. Its developed as a standalone library, so its likely that
>>> MochKit and Prototype will use it, too.
>> That sure is nice, but the selectors are not used in Wicket core at all.
>>
>>> jQuery 1.3. will also provide heavy performance improvements for DOM
>>> manipulations, which I'm very exited about as that is usually where
>>> most time is spent. Its easy to avoid running certain selectors too
>>> often, but its hard to optimize DOM manipulation in clientcode.
>>
>> While we at this, I'd like to ask. Significant part of Wicket ajax is
>> Wicket.replaceOuterHtml method. This was really a major pain to
>> implement and stabilize. What it does is basically a replaceOuterHTML
>> call for all browser but it works in totally cross browser consistent
>> way. I.e. it allows table rows, cells etc replaced in internet
>> explorer and it also executes embedded <script> tags on browsers that
>> would normally not do that (basically all except for Firefox). So my
>> question is, just out of curiosity, is there/will there be similar
>> functionality provided by jQuery?
>>>
>>> Anyway, thanks for taking the time to discuss this again.
>>
>> Sure. Keep in mind that the decision is not carved to stone. I'm open
>> to argument, but I'm really interested in technical aspect. Having
>> "Microsoft will use jQuery" is not really a valid argument to me :)
>>
>> -Matej
>>
>>>
>>> Jörn
>>>
>>> On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>> Are you really that surprised that Microsoft is not shipping YUI after
>>>> the failed attempts to take over Yahoo? :)
>>>>
>>>> Seriously, there are technical reasons why I considered to use YUI,
>>>> not political. Just because some companies use jQuery it doesn't mean
>>>> Wicket should use it. Say most of the companies use JSF, does it mean
>>>> we should?
>>>>
>>>> As I said, I really like the way YUI api is designed. Also there are
>>>> things in YUI "core" that are only available as jQuery plugins. The
>>>> plugins have different lifecycle than the core and are mantained
>>>> differently.
>>>>
>>>> Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket.
>>>>
>>>> Let me give you an example where I find YUI (3) api more elegant.
>>>> That's just one of many things and it is of course my personal
>>>> opinion.
>>>>
>>>> If i want to unbind event in jQuery, i need to remember event name and
>>>> the exact handler instance. For YUI, i get event handler on bind that
>>>> i can just call detach on and the event is unbound.
>>>>
>>>> var h = Y.on("click", handleClick, element);
>>>> h.detach();
>>>>
>>>> Of course it is possible to mock the behavior with jQuery, but that's
>>>> not really the point, is it?
>>>>
>>>> Another this is functionality provided in core. YUI can handle
>>>> multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's
>>>> very likely it will be as it was supported in 2.x). For jQuery, i need
>>>> to use a plugin for it.
>>>>
>>>> The reason why I feel so uneasy about plugins is that I've tried some.
>>>> And the quality really varies.
>>>>
>>>> I think selectors might be the part where jQuery really shines. But
>>>> that's the part not needed by Wicket at all. Plus YUI has selectors
>>>> too (although maybe not that fast - I don't know, haven't profiled
>>>> them). Also the new YUI3 node API resembles jQuery chaining API for
>>>> those who like it.
>>>>
>>>> -Matej
>>>>
>>>> On Mon, Sep 29, 2008 at 4:01 AM, Jörn Zaefferer
>>>> <jo...@googlemail.com> wrote:
>>>>> There is something new to consider when choosing a JavaScript library
>>>>> as Wicket's base:
>>>>> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
>>>>> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
>>>>>
>>>>> Jörn
>>>>>
>>>>> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com> wrote:
>>>>>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>>>>>> <jo...@googlemail.com> wrote:
>>>>>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <jw...@cabouge.com> 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.
>>>>>>>
>>>>>>> Of course there is the overhead of including two or more libraries in
>>>>>>> an application, which don't find desirable.
>>>>>>
>>>>>> Wicket uses only part of YUI, the compressed minified required YUI
>>>>>> javascript is about 20kb big. I would understand the concern if I used
>>>>>> dojo or some other behemoth with 200+ kb of compressed javascript.
>>>>>>
>>>>>>>
>>>>>>>>> + 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.
>>>>>>>
>>>>>>> You are well on the point that the variety of plugins varies. I see it
>>>>>>> this way: jQuery core is small, very stable and the base for
>>>>>>> everything else JS-related. jQuery UI is the official project
>>>>>>> providing the same stability and quality for various high-level UI
>>>>>>> components (like dialogs) and also low-level components (like
>>>>>>> drag&drop, sortables). We'll see at least two major releases this year
>>>>>>> that add more components to the mix. Anything else that isn't covered
>>>>>>> by core or UI is almost always covered by some third-party plugin.
>>>>>>> While these plugin can be of bady quality (eg. no
>>>>>>> documentation/demos), they can still provide a good starting point, so
>>>>>>> that you don't have to start from scratch. Even if you do a full
>>>>>>> rewrite, the existing plugin can expose useful information like
>>>>>>> potential browser-bug-traps.
>>>>>> Problem is that the jQuery core doesn't cut it. And rewriting plugins
>>>>>> from scratch? Are you serious? This is exactly the reason why I
>>>>>> decided to use YUI. The stuff that I need is there, it is supported
>>>>>> and maintained.
>>>>>>>
>>>>>>>> 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 :)
>>>>>>>
>>>>>>> Whatever the framework, I think its a good idea to start with
>>>>>>> something well supported and tested. Thats why I use Wicket, though
>>>>>>> I'd like it even more with jQuery as the base framework :-)
>>>>>>
>>>>>> At this point, I really don't see any advantage that YUI would give me
>>>>>> over jQuery.
>>>>>> Also it is possible that InMethod grid will be part of Wicket 1.5
>>>>>> extensions which is another point for using YUI. Rewriting the grid
>>>>>> with jquery would be a huge pain.
>>>>>>
>>>>>> -Matej
>>>>>>
>>>>>>>
>>>>>>> Jörn
>>>>>>>
>>>>>>> PS: Comet support is a nice to have, but I think there a way more
>>>>>>> important things for core than that, eg. annotation-based validation
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
Ok I hear you.
But could'nt be something as simple as being able to roll your own js
instead of the default wicket js ones? I mean just define the functions
requried in the wicket name space.. Again im just tossing out ideas
here.. And it might just be possible as everything are now..
Matej Knopp wrote:
> I'm not keen on this at all. It would require me to specify stable
> API, specify proper contracts and stick to it. Wicket ajax should be
> treated as something opaque.
>
> Plus it would be hell to support. With every problem I'd have to
> investigate what implementation user uses, what "bridge" and if the
> problem is Wicket-Ajax related at all.
>
> -Matej
>
> On Tue, Sep 30, 2008 at 10:03 AM, Nino Saturnino Martinez Vazquez Wael
> <ni...@jayway.dk> wrote:
>
>> Hi Matej
>>
>> I was just thinking if WANG Wicket Ajax comes loosely coupled to the js lib?
>> If it does, then people could then implement their own js bridge to what
>> ever js framework they like... Im just thinking aloud here...
>>
>> Btw, I don't care which js lib you are gonna use as long as it's the best
>> for wicket and you.
>>
>> Matej Knopp wrote:
>>
>>> Okay, let's keep this focused.
>>> Here is my experimental branch.
>>>
>>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
>>>
>>> There is new Ajax implementation here:
>>>
>>>
>>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
>>>
>>> and the main AjaxBehavior here:
>>>
>>>
>>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
>>>
>>> What I'd like to hear is what exactly is wrong with it and how using
>>> jQuery (or any other framework for that matter) could improve things.
>>>
>>> -Matej
>>>
>>> On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
>>> <ma...@gmail.com> wrote:
>>>
>>>
>>>> On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
>>>> <jo...@googlemail.com> wrote:
>>>>
>>>>
>>>>> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
>>>>> Dojo, YUI and jQuery. One question was: "What library would you
>>>>> recommend but your own?". Two of the three non-jQuery guys recommened
>>>>> jQuery
>>>>>
>>>>>
>>>> So you're saying that 75% of the leading JS framework community think
>>>> jquery is second best.
>>>>
>>>> Please keep the jquery marketing BS and fanboyism to the jquery
>>>> forums. It serves nobody any good. In fact it makes me cringe and want
>>>> to -1 any and all votes for adopting anything near jquery.
>>>>
>>>> Martijn
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>> --
>> -Wicket for love
>>
>> Nino Martinez Wael
>> Java Specialist @ Jayway DK
>> http://www.jayway.dk
>> +45 2936 7684
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Matej Knopp <ma...@gmail.com>.
I'm not keen on this at all. It would require me to specify stable
API, specify proper contracts and stick to it. Wicket ajax should be
treated as something opaque.
Plus it would be hell to support. With every problem I'd have to
investigate what implementation user uses, what "bridge" and if the
problem is Wicket-Ajax related at all.
-Matej
On Tue, Sep 30, 2008 at 10:03 AM, Nino Saturnino Martinez Vazquez Wael
<ni...@jayway.dk> wrote:
> Hi Matej
>
> I was just thinking if WANG Wicket Ajax comes loosely coupled to the js lib?
> If it does, then people could then implement their own js bridge to what
> ever js framework they like... Im just thinking aloud here...
>
> Btw, I don't care which js lib you are gonna use as long as it's the best
> for wicket and you.
>
> Matej Knopp wrote:
>>
>> Okay, let's keep this focused.
>> Here is my experimental branch.
>>
>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
>>
>> There is new Ajax implementation here:
>>
>>
>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
>>
>> and the main AjaxBehavior here:
>>
>>
>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
>>
>> What I'd like to hear is what exactly is wrong with it and how using
>> jQuery (or any other framework for that matter) could improve things.
>>
>> -Matej
>>
>> On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
>> <ma...@gmail.com> wrote:
>>
>>>
>>> On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
>>> <jo...@googlemail.com> wrote:
>>>
>>>>
>>>> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
>>>> Dojo, YUI and jQuery. One question was: "What library would you
>>>> recommend but your own?". Two of the three non-jQuery guys recommened
>>>> jQuery
>>>>
>>>
>>> So you're saying that 75% of the leading JS framework community think
>>> jquery is second best.
>>>
>>> Please keep the jquery marketing BS and fanboyism to the jquery
>>> forums. It serves nobody any good. In fact it makes me cringe and want
>>> to -1 any and all votes for adopting anything near jquery.
>>>
>>> Martijn
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> --
> -Wicket for love
>
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> +45 2936 7684
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
From checking wicket ajax and wicket event as is now, it's not that
many lines of code. I guess you should just be able to drop in your own
version of them I guess.. But if people are never to do the bridgin then
it's just a vaste of time.
Jörn Zaefferer wrote:
> ExtJS actually tried implementing bridges to other libraries when they
> tried to get independent of YUI. The ended with rolling their own and
> removing all bridges. Unfortunately its still a bloated intertangled
> web of dependencies, with over 200k for just some basics...
>
> Jörn
>
> On Tue, Sep 30, 2008 at 10:03 AM, Nino Saturnino Martinez Vazquez Wael
> <ni...@jayway.dk> wrote:
>
>> Hi Matej
>>
>> I was just thinking if WANG Wicket Ajax comes loosely coupled to the js lib?
>> If it does, then people could then implement their own js bridge to what
>> ever js framework they like... Im just thinking aloud here...
>>
>> Btw, I don't care which js lib you are gonna use as long as it's the best
>> for wicket and you.
>>
>> Matej Knopp wrote:
>>
>>> Okay, let's keep this focused.
>>> Here is my experimental branch.
>>>
>>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
>>>
>>> There is new Ajax implementation here:
>>>
>>>
>>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
>>>
>>> and the main AjaxBehavior here:
>>>
>>>
>>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
>>>
>>> What I'd like to hear is what exactly is wrong with it and how using
>>> jQuery (or any other framework for that matter) could improve things.
>>>
>>> -Matej
>>>
>>> On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
>>> <ma...@gmail.com> wrote:
>>>
>>>
>>>> On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
>>>> <jo...@googlemail.com> wrote:
>>>>
>>>>
>>>>> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
>>>>> Dojo, YUI and jQuery. One question was: "What library would you
>>>>> recommend but your own?". Two of the three non-jQuery guys recommened
>>>>> jQuery
>>>>>
>>>>>
>>>> So you're saying that 75% of the leading JS framework community think
>>>> jquery is second best.
>>>>
>>>> Please keep the jquery marketing BS and fanboyism to the jquery
>>>> forums. It serves nobody any good. In fact it makes me cringe and want
>>>> to -1 any and all votes for adopting anything near jquery.
>>>>
>>>> Martijn
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>> --
>> -Wicket for love
>>
>> Nino Martinez Wael
>> Java Specialist @ Jayway DK
>> http://www.jayway.dk
>> +45 2936 7684
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Jörn Zaefferer <jo...@googlemail.com>.
ExtJS actually tried implementing bridges to other libraries when they
tried to get independent of YUI. The ended with rolling their own and
removing all bridges. Unfortunately its still a bloated intertangled
web of dependencies, with over 200k for just some basics...
Jörn
On Tue, Sep 30, 2008 at 10:03 AM, Nino Saturnino Martinez Vazquez Wael
<ni...@jayway.dk> wrote:
> Hi Matej
>
> I was just thinking if WANG Wicket Ajax comes loosely coupled to the js lib?
> If it does, then people could then implement their own js bridge to what
> ever js framework they like... Im just thinking aloud here...
>
> Btw, I don't care which js lib you are gonna use as long as it's the best
> for wicket and you.
>
> Matej Knopp wrote:
>>
>> Okay, let's keep this focused.
>> Here is my experimental branch.
>>
>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
>>
>> There is new Ajax implementation here:
>>
>>
>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
>>
>> and the main AjaxBehavior here:
>>
>>
>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
>>
>> What I'd like to hear is what exactly is wrong with it and how using
>> jQuery (or any other framework for that matter) could improve things.
>>
>> -Matej
>>
>> On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
>> <ma...@gmail.com> wrote:
>>
>>>
>>> On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
>>> <jo...@googlemail.com> wrote:
>>>
>>>>
>>>> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
>>>> Dojo, YUI and jQuery. One question was: "What library would you
>>>> recommend but your own?". Two of the three non-jQuery guys recommened
>>>> jQuery
>>>>
>>>
>>> So you're saying that 75% of the leading JS framework community think
>>> jquery is second best.
>>>
>>> Please keep the jquery marketing BS and fanboyism to the jquery
>>> forums. It serves nobody any good. In fact it makes me cringe and want
>>> to -1 any and all votes for adopting anything near jquery.
>>>
>>> Martijn
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> --
> -Wicket for love
>
> Nino Martinez Wael
> Java Specialist @ Jayway DK
> http://www.jayway.dk
> +45 2936 7684
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Nino Saturnino Martinez Vazquez Wael <ni...@jayway.dk>.
Hi Matej
I was just thinking if WANG Wicket Ajax comes loosely coupled to the js
lib? If it does, then people could then implement their own js bridge to
what ever js framework they like... Im just thinking aloud here...
Btw, I don't care which js lib you are gonna use as long as it's the
best for wicket and you.
Matej Knopp wrote:
> Okay, let's keep this focused.
> Here is my experimental branch.
>
> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
>
> There is new Ajax implementation here:
>
> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
>
> and the main AjaxBehavior here:
>
> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
>
> What I'd like to hear is what exactly is wrong with it and how using
> jQuery (or any other framework for that matter) could improve things.
>
> -Matej
>
> On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
> <ma...@gmail.com> wrote:
>
>> On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
>> <jo...@googlemail.com> wrote:
>>
>>> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
>>> Dojo, YUI and jQuery. One question was: "What library would you
>>> recommend but your own?". Two of the three non-jQuery guys recommened
>>> jQuery
>>>
>> So you're saying that 75% of the leading JS framework community think
>> jquery is second best.
>>
>> Please keep the jquery marketing BS and fanboyism to the jquery
>> forums. It serves nobody any good. In fact it makes me cringe and want
>> to -1 any and all votes for adopting anything near jquery.
>>
>> Martijn
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
-Wicket for love
Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
+45 2936 7684
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Frank Bille <fr...@apache.org>.
On Tue, Sep 30, 2008 at 3:27 PM, Matej Knopp <ma...@gmail.com> wrote:
> One thing that has crossed my mind too. YUI contains API for getting
> "absolute" coordinates of element as well as settings absolute
> coordinates to element (it takes care of setting proper position
> attributes, etc.). Last time I checked this was only available as a
> separate plugin for jQuery. This is a functionality that is really
> useful, if not for the base wicket API, then for the extentions. Is
> this part of jQuery core, or will it be in future?
>
I think the Dimensions plugin is now merged into jquery as of 1.2.6.
Frank
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Jörn Zaefferer <jo...@googlemail.com>.
About removing events when removing elements: jQuery always removes
events when removing an element from the DOM. If you want to actually
move an element to insert it somewhere else, you can do that just as
well, you just may not use it with remove. Eg.
$(element).insertAfter(otherElement); will move element somewhere
else, keeping all events intact.
The replaceOuterHTML-replacement should be already heavily optimized,
though thats actually something that should work much better in jQuery
1.3, which is planned for fall 2008.
About get/post: True, if you use method: "post", all data-parameters
are posted. Though you can still just use $.param to seriliaze the
get-parameters and append it manually to the URL.
$.ajax({
url: "...?" + $.param(getParams),
data: postParams
});
Offset and position computations were part of the dimensions plugin,
which is now merged into jQuery core, so that is readily available and
official.
Jörn
On Tue, Sep 30, 2008 at 3:27 PM, Matej Knopp <ma...@gmail.com> wrote:
> Thanks for the response.
>
> On Tue, Sep 30, 2008 at 5:11 AM, Jörn Zaefferer
> <jo...@googlemail.com> wrote:
>> I'll go through a few things in the wicket-ajax-ng.js file, to give an
>> idea how that could look like when putting it on top of jQuery. I skip
>> all stuff where I can't guess while scanning the code whats its
>> supposed to do.
>>
>> W.$ looks like it selects one or more elements by id. Selecting is
>> completely encapsulated in the jQuery-function, so you would change
>> the usage a bit:
>>
>> W.$("myID") == $("#myID").get(0)
>> W.$("id1", "id2") == $("#id1, #id2").get()
>>
>
> well, since we are not using any selector but # here, this is more
> like a cosmetic thing.
>
>> Usually you won't need to reference the DOM elements, so you could
>> remove the get(0) and get() calls.
>>
>> W.$$ would just use:
>>
>> if ($("#id").size() ) {
>> // element exists
>> }
> That's not entirely corrent i believe. If you pass element instance to
> W.$$ it checks if the element is part of active document. That's very
> important for wicket to determine if the queued ajax request is still
> valid.
>>
>> copyArray can be replaced with jQuery.makeArray
>> (http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1130), which
>> is heavily optimized and takes stuff like passing window as an
>> argument into account.
> We only copy small arrays, the performance of array copy has never
> bothered me much :)
>>
>> iterateArray could be replaced with jQuery.each, though the symantics
>> are slightly different. jQuery.each iterates over both objects and
>> arrays.
>>
>> The GarbageCollector wouldn't be necessary: jQuery cleans up all event
>> listeneres when removing elements from the DOM. You don't have to
>> bother with that at all.
> Well, this is a rather unfortunate thing with YUI. If you bind event
> to element and then remove the element, yui only seem to release the
> element when window is being unloaded, which causes certain problems
> in IE. The memory consumption grows over time if you stay on single
> page, though it's not really a leak because the memory gets reclaimed
> on page reload. That's why i built the garbage collector that goes
> over elements and checks if they are still in the document.
>
> So I'm a bit curious here, how does jQuery know that element has been
> removed from document? And how does it know that I don't want to use
> it anymore? Or are all the events released when I use jQuery API to
> remove element from document? But what if i keep reference to that
> element myself (after removing it from the document) and I don't want
> the events to be removed (this part isn't really solved with current
> version of the "Garbage Collectior" either).
>
>>
>> Like I mentioned earlier, replaceOuterHtmlXXX shouldn't be necessary
>> at all, jQuery handles that automatically for all DOM manipulation
>> methods.
> That's a good news if the method really works as advertised (plus has
> decent performance for replacing large chunks of markup, which I'd
> have to test first though).
>
>>
>> mapToUrlParameters would be handled by jQuery.param. Though usually
>> when using jQuery's ajax methods, you don't have to worry about that.
>> For example, to post some parameters to the server, you'd just use
>> jQuery.ajax with the data option:
>
> Sure, as long as jQuery allows me to make distinction between GET and
> POST parameters. If it doesn't, I'd still have to encode the
> parameters for query string myself.
>
>>
>> $.ajax({
>> url: ...,
>> method: "post"
>> data: {
>> key1: "value1",
>> key2: "value2"
>> }
>> });
>>
>> And so far I've covered only jQuery core functionality. What do you think?
>
> Well, so far the element replacement method would be a benefit if it
> really works like Wicket.replaceOuterHTML does. As well as no
> "leaking" when removing elements with attached events from document,
> if it, indeed, works :)
>
> One thing that has crossed my mind too. YUI contains API for getting
> "absolute" coordinates of element as well as settings absolute
> coordinates to element (it takes care of setting proper position
> attributes, etc.). Last time I checked this was only available as a
> separate plugin for jQuery. This is a functionality that is really
> useful, if not for the base wicket API, then for the extentions. Is
> this part of jQuery core, or will it be in future?
>
> -Matej
>
>>
>> Jörn
>>
>> On Mon, Sep 29, 2008 at 11:50 PM, Matej Knopp <ma...@gmail.com> wrote:
>>> Okay, let's keep this focused.
>>> Here is my experimental branch.
>>>
>>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
>>>
>>> There is new Ajax implementation here:
>>>
>>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
>>>
>>> and the main AjaxBehavior here:
>>>
>>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
>>>
>>> What I'd like to hear is what exactly is wrong with it and how using
>>> jQuery (or any other framework for that matter) could improve things.
>>>
>>> -Matej
>>>
>>> On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
>>> <ma...@gmail.com> wrote:
>>>> On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
>>>> <jo...@googlemail.com> wrote:
>>>>> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
>>>>> Dojo, YUI and jQuery. One question was: "What library would you
>>>>> recommend but your own?". Two of the three non-jQuery guys recommened
>>>>> jQuery
>>>>
>>>> So you're saying that 75% of the leading JS framework community think
>>>> jquery is second best.
>>>>
>>>> Please keep the jquery marketing BS and fanboyism to the jquery
>>>> forums. It serves nobody any good. In fact it makes me cringe and want
>>>> to -1 any and all votes for adopting anything near jquery.
>>>>
>>>> Martijn
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Matej Knopp <ma...@gmail.com>.
Thanks for the response.
On Tue, Sep 30, 2008 at 5:11 AM, Jörn Zaefferer
<jo...@googlemail.com> wrote:
> I'll go through a few things in the wicket-ajax-ng.js file, to give an
> idea how that could look like when putting it on top of jQuery. I skip
> all stuff where I can't guess while scanning the code whats its
> supposed to do.
>
> W.$ looks like it selects one or more elements by id. Selecting is
> completely encapsulated in the jQuery-function, so you would change
> the usage a bit:
>
> W.$("myID") == $("#myID").get(0)
> W.$("id1", "id2") == $("#id1, #id2").get()
>
well, since we are not using any selector but # here, this is more
like a cosmetic thing.
> Usually you won't need to reference the DOM elements, so you could
> remove the get(0) and get() calls.
>
> W.$$ would just use:
>
> if ($("#id").size() ) {
> // element exists
> }
That's not entirely corrent i believe. If you pass element instance to
W.$$ it checks if the element is part of active document. That's very
important for wicket to determine if the queued ajax request is still
valid.
>
> copyArray can be replaced with jQuery.makeArray
> (http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1130), which
> is heavily optimized and takes stuff like passing window as an
> argument into account.
We only copy small arrays, the performance of array copy has never
bothered me much :)
>
> iterateArray could be replaced with jQuery.each, though the symantics
> are slightly different. jQuery.each iterates over both objects and
> arrays.
>
> The GarbageCollector wouldn't be necessary: jQuery cleans up all event
> listeneres when removing elements from the DOM. You don't have to
> bother with that at all.
Well, this is a rather unfortunate thing with YUI. If you bind event
to element and then remove the element, yui only seem to release the
element when window is being unloaded, which causes certain problems
in IE. The memory consumption grows over time if you stay on single
page, though it's not really a leak because the memory gets reclaimed
on page reload. That's why i built the garbage collector that goes
over elements and checks if they are still in the document.
So I'm a bit curious here, how does jQuery know that element has been
removed from document? And how does it know that I don't want to use
it anymore? Or are all the events released when I use jQuery API to
remove element from document? But what if i keep reference to that
element myself (after removing it from the document) and I don't want
the events to be removed (this part isn't really solved with current
version of the "Garbage Collectior" either).
>
> Like I mentioned earlier, replaceOuterHtmlXXX shouldn't be necessary
> at all, jQuery handles that automatically for all DOM manipulation
> methods.
That's a good news if the method really works as advertised (plus has
decent performance for replacing large chunks of markup, which I'd
have to test first though).
>
> mapToUrlParameters would be handled by jQuery.param. Though usually
> when using jQuery's ajax methods, you don't have to worry about that.
> For example, to post some parameters to the server, you'd just use
> jQuery.ajax with the data option:
Sure, as long as jQuery allows me to make distinction between GET and
POST parameters. If it doesn't, I'd still have to encode the
parameters for query string myself.
>
> $.ajax({
> url: ...,
> method: "post"
> data: {
> key1: "value1",
> key2: "value2"
> }
> });
>
> And so far I've covered only jQuery core functionality. What do you think?
Well, so far the element replacement method would be a benefit if it
really works like Wicket.replaceOuterHTML does. As well as no
"leaking" when removing elements with attached events from document,
if it, indeed, works :)
One thing that has crossed my mind too. YUI contains API for getting
"absolute" coordinates of element as well as settings absolute
coordinates to element (it takes care of setting proper position
attributes, etc.). Last time I checked this was only available as a
separate plugin for jQuery. This is a functionality that is really
useful, if not for the base wicket API, then for the extentions. Is
this part of jQuery core, or will it be in future?
-Matej
>
> Jörn
>
> On Mon, Sep 29, 2008 at 11:50 PM, Matej Knopp <ma...@gmail.com> wrote:
>> Okay, let's keep this focused.
>> Here is my experimental branch.
>>
>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
>>
>> There is new Ajax implementation here:
>>
>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
>>
>> and the main AjaxBehavior here:
>>
>> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
>>
>> What I'd like to hear is what exactly is wrong with it and how using
>> jQuery (or any other framework for that matter) could improve things.
>>
>> -Matej
>>
>> On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
>> <ma...@gmail.com> wrote:
>>> On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
>>> <jo...@googlemail.com> wrote:
>>>> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
>>>> Dojo, YUI and jQuery. One question was: "What library would you
>>>> recommend but your own?". Two of the three non-jQuery guys recommened
>>>> jQuery
>>>
>>> So you're saying that 75% of the leading JS framework community think
>>> jquery is second best.
>>>
>>> Please keep the jquery marketing BS and fanboyism to the jquery
>>> forums. It serves nobody any good. In fact it makes me cringe and want
>>> to -1 any and all votes for adopting anything near jquery.
>>>
>>> Martijn
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Jörn Zaefferer <jo...@googlemail.com>.
I'll go through a few things in the wicket-ajax-ng.js file, to give an
idea how that could look like when putting it on top of jQuery. I skip
all stuff where I can't guess while scanning the code whats its
supposed to do.
W.$ looks like it selects one or more elements by id. Selecting is
completely encapsulated in the jQuery-function, so you would change
the usage a bit:
W.$("myID") == $("#myID").get(0)
W.$("id1", "id2") == $("#id1, #id2").get()
Usually you won't need to reference the DOM elements, so you could
remove the get(0) and get() calls.
W.$$ would just use:
if ($("#id").size() ) {
// element exists
}
copyArray can be replaced with jQuery.makeArray
(http://dev.jquery.com/browser/trunk/jquery/src/core.js#L1130), which
is heavily optimized and takes stuff like passing window as an
argument into account.
iterateArray could be replaced with jQuery.each, though the symantics
are slightly different. jQuery.each iterates over both objects and
arrays.
The GarbageCollector wouldn't be necessary: jQuery cleans up all event
listeneres when removing elements from the DOM. You don't have to
bother with that at all.
Like I mentioned earlier, replaceOuterHtmlXXX shouldn't be necessary
at all, jQuery handles that automatically for all DOM manipulation
methods.
mapToUrlParameters would be handled by jQuery.param. Though usually
when using jQuery's ajax methods, you don't have to worry about that.
For example, to post some parameters to the server, you'd just use
jQuery.ajax with the data option:
$.ajax({
url: ...,
method: "post"
data: {
key1: "value1",
key2: "value2"
}
});
And so far I've covered only jQuery core functionality. What do you think?
Jörn
On Mon, Sep 29, 2008 at 11:50 PM, Matej Knopp <ma...@gmail.com> wrote:
> Okay, let's keep this focused.
> Here is my experimental branch.
>
> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
>
> There is new Ajax implementation here:
>
> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
>
> and the main AjaxBehavior here:
>
> http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
>
> What I'd like to hear is what exactly is wrong with it and how using
> jQuery (or any other framework for that matter) could improve things.
>
> -Matej
>
> On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
> <ma...@gmail.com> wrote:
>> On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
>> <jo...@googlemail.com> wrote:
>>> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
>>> Dojo, YUI and jQuery. One question was: "What library would you
>>> recommend but your own?". Two of the three non-jQuery guys recommened
>>> jQuery
>>
>> So you're saying that 75% of the leading JS framework community think
>> jquery is second best.
>>
>> Please keep the jquery marketing BS and fanboyism to the jquery
>> forums. It serves nobody any good. In fact it makes me cringe and want
>> to -1 any and all votes for adopting anything near jquery.
>>
>> Martijn
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Matej Knopp <ma...@gmail.com>.
Okay, let's keep this focused.
Here is my experimental branch.
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/
There is new Ajax implementation here:
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/js/wicket-ajax-ng.js
and the main AjaxBehavior here:
http://svn.apache.org/repos/asf/wicket/sandbox/knopp/experimental/wicket/src/main/java/org/apache/_wicket/ajax/AjaxBehavior.java
What I'd like to hear is what exactly is wrong with it and how using
jQuery (or any other framework for that matter) could improve things.
-Matej
On Mon, Sep 29, 2008 at 11:45 PM, Martijn Dashorst
<ma...@gmail.com> wrote:
> On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
> <jo...@googlemail.com> wrote:
>> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
>> Dojo, YUI and jQuery. One question was: "What library would you
>> recommend but your own?". Two of the three non-jQuery guys recommened
>> jQuery
>
> So you're saying that 75% of the leading JS framework community think
> jquery is second best.
>
> Please keep the jquery marketing BS and fanboyism to the jquery
> forums. It serves nobody any good. In fact it makes me cringe and want
> to -1 any and all votes for adopting anything near jquery.
>
> Martijn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Martijn Dashorst <ma...@gmail.com>.
On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
<jo...@googlemail.com> wrote:
> PS: I'm currently sitting on a panel with PPK and guys from Prototype,
> Dojo, YUI and jQuery. One question was: "What library would you
> recommend but your own?". Two of the three non-jQuery guys recommened
> jQuery
So you're saying that 75% of the leading JS framework community think
jquery is second best.
Please keep the jquery marketing BS and fanboyism to the jquery
forums. It serves nobody any good. In fact it makes me cringe and want
to -1 any and all votes for adopting anything near jquery.
Martijn
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Jörn Zaefferer <jo...@googlemail.com>.
I guess I didn't quite get the file upload example in the first place.
Uploading via iframe is supported by jQuery's form plugin, which is
one of the best plugins we have. We plan to add it, together with
other related plugins, to jQuery UI forms (or something like that).
About selectors: jQuery promotes progressive enhancement a lot, and
selectors are essential for that. One example for that is that we
avoid inline onclick=".." and similar stuff. I'm not sure how that
would be handled by Wicket, and if using jQuery would open ways to
handle things differently.
I can't give you too many details on replaceOuterHtml, though that
sounds like I can easily get more info on. Currently jQuery does a lot
of work cleaning html input that is appended into the DOM, which seems
to be basically the same usecase here. Also executing script-tags is
something we cover.
Could you give me an example how exactly replaceOuterHTML is currently used?
About the Microsoft argument: True, from a technical perspective that
doesn't matter. But its an important political aspect: I already read
a few comments from people that couldn't use jQuery due to a general
"no open-source" policy - but now that Microsoft, that had exactly
that policy, is changed theirs, it could enable others to adopt it,
too.
Jörn
PS: I'm currently sitting on a panel with PPK and guys from Prototype,
Dojo, YUI and jQuery. One question was: "What library would you
recommend but your own?". Two of the three non-jQuery guys recommened
jQuery
On Mon, Sep 29, 2008 at 1:41 PM, Matej Knopp <ma...@gmail.com> wrote:
> On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer
> <jo...@googlemail.com> wrote:
>> It would be a big plus for me if Wicket would adopt jQuery. Drupal
>> does that, and anyone writing a Drupal module can rely on the fact
>> that jQuery is available. Same for Wordpress, where plugin authors can
>> rely on the availability of jQuery. And not having to load more than
>> one library, internal or not, is a good thing performance-wise.
>>
>> In response to your examples:
>>
>> Unbinding only particular event handlers without having a reference to
>> the handler function can be achieved with namespaces:
>> $(element).bind("click.somethingUnique", handleClick);
>> $(element).unbind("click.somethingUnique");
>
> But that's not quite the same. This requires me to use generate and
> keep a unique string. Anyway, this is a cosmetic issue only.
>
>>
>> That way you don't have to keep a reference at all, while its possible
>> to group multiple events into one namespace. This is now heavily used
>> by most jQuery UI components when destroyed, to clean up their own
>> event handlers without affecting any other.
>>
>> Multiple file upload we'll eventually have as part of jQuery UI. That
>> would then be the same level of official and supported component that
>> YUI provides. The descision to add new components is partly
>> community-driven. So if you think multipart ajax uploads should be
>> added, just ask for it.
> This is not about "multiple file upload". We already have such
> component in Wicket. This is about support for <input type="file"> on
> ajax uploads - just use hidden frame instead of xml http request.
>
>>
>> About selectors: John Resig is currently working on a new selector
>> engine that likely outperformances any other selector engine available
>> so far. Its developed as a standalone library, so its likely that
>> MochKit and Prototype will use it, too.
> That sure is nice, but the selectors are not used in Wicket core at all.
>
>> jQuery 1.3. will also provide heavy performance improvements for DOM
>> manipulations, which I'm very exited about as that is usually where
>> most time is spent. Its easy to avoid running certain selectors too
>> often, but its hard to optimize DOM manipulation in clientcode.
>
> While we at this, I'd like to ask. Significant part of Wicket ajax is
> Wicket.replaceOuterHtml method. This was really a major pain to
> implement and stabilize. What it does is basically a replaceOuterHTML
> call for all browser but it works in totally cross browser consistent
> way. I.e. it allows table rows, cells etc replaced in internet
> explorer and it also executes embedded <script> tags on browsers that
> would normally not do that (basically all except for Firefox). So my
> question is, just out of curiosity, is there/will there be similar
> functionality provided by jQuery?
>>
>> Anyway, thanks for taking the time to discuss this again.
>
> Sure. Keep in mind that the decision is not carved to stone. I'm open
> to argument, but I'm really interested in technical aspect. Having
> "Microsoft will use jQuery" is not really a valid argument to me :)
>
> -Matej
>
>>
>> Jörn
>>
>> On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp <ma...@gmail.com> wrote:
>>> Are you really that surprised that Microsoft is not shipping YUI after
>>> the failed attempts to take over Yahoo? :)
>>>
>>> Seriously, there are technical reasons why I considered to use YUI,
>>> not political. Just because some companies use jQuery it doesn't mean
>>> Wicket should use it. Say most of the companies use JSF, does it mean
>>> we should?
>>>
>>> As I said, I really like the way YUI api is designed. Also there are
>>> things in YUI "core" that are only available as jQuery plugins. The
>>> plugins have different lifecycle than the core and are mantained
>>> differently.
>>>
>>> Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket.
>>>
>>> Let me give you an example where I find YUI (3) api more elegant.
>>> That's just one of many things and it is of course my personal
>>> opinion.
>>>
>>> If i want to unbind event in jQuery, i need to remember event name and
>>> the exact handler instance. For YUI, i get event handler on bind that
>>> i can just call detach on and the event is unbound.
>>>
>>> var h = Y.on("click", handleClick, element);
>>> h.detach();
>>>
>>> Of course it is possible to mock the behavior with jQuery, but that's
>>> not really the point, is it?
>>>
>>> Another this is functionality provided in core. YUI can handle
>>> multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's
>>> very likely it will be as it was supported in 2.x). For jQuery, i need
>>> to use a plugin for it.
>>>
>>> The reason why I feel so uneasy about plugins is that I've tried some.
>>> And the quality really varies.
>>>
>>> I think selectors might be the part where jQuery really shines. But
>>> that's the part not needed by Wicket at all. Plus YUI has selectors
>>> too (although maybe not that fast - I don't know, haven't profiled
>>> them). Also the new YUI3 node API resembles jQuery chaining API for
>>> those who like it.
>>>
>>> -Matej
>>>
>>> On Mon, Sep 29, 2008 at 4:01 AM, Jörn Zaefferer
>>> <jo...@googlemail.com> wrote:
>>>> There is something new to consider when choosing a JavaScript library
>>>> as Wicket's base:
>>>> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
>>>> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
>>>>
>>>> Jörn
>>>>
>>>> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com> wrote:
>>>>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>>>>> <jo...@googlemail.com> wrote:
>>>>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <jw...@cabouge.com> 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.
>>>>>>
>>>>>> Of course there is the overhead of including two or more libraries in
>>>>>> an application, which don't find desirable.
>>>>>
>>>>> Wicket uses only part of YUI, the compressed minified required YUI
>>>>> javascript is about 20kb big. I would understand the concern if I used
>>>>> dojo or some other behemoth with 200+ kb of compressed javascript.
>>>>>
>>>>>>
>>>>>>>> + 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.
>>>>>>
>>>>>> You are well on the point that the variety of plugins varies. I see it
>>>>>> this way: jQuery core is small, very stable and the base for
>>>>>> everything else JS-related. jQuery UI is the official project
>>>>>> providing the same stability and quality for various high-level UI
>>>>>> components (like dialogs) and also low-level components (like
>>>>>> drag&drop, sortables). We'll see at least two major releases this year
>>>>>> that add more components to the mix. Anything else that isn't covered
>>>>>> by core or UI is almost always covered by some third-party plugin.
>>>>>> While these plugin can be of bady quality (eg. no
>>>>>> documentation/demos), they can still provide a good starting point, so
>>>>>> that you don't have to start from scratch. Even if you do a full
>>>>>> rewrite, the existing plugin can expose useful information like
>>>>>> potential browser-bug-traps.
>>>>> Problem is that the jQuery core doesn't cut it. And rewriting plugins
>>>>> from scratch? Are you serious? This is exactly the reason why I
>>>>> decided to use YUI. The stuff that I need is there, it is supported
>>>>> and maintained.
>>>>>>
>>>>>>> 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 :)
>>>>>>
>>>>>> Whatever the framework, I think its a good idea to start with
>>>>>> something well supported and tested. Thats why I use Wicket, though
>>>>>> I'd like it even more with jQuery as the base framework :-)
>>>>>
>>>>> At this point, I really don't see any advantage that YUI would give me
>>>>> over jQuery.
>>>>> Also it is possible that InMethod grid will be part of Wicket 1.5
>>>>> extensions which is another point for using YUI. Rewriting the grid
>>>>> with jquery would be a huge pain.
>>>>>
>>>>> -Matej
>>>>>
>>>>>>
>>>>>> Jörn
>>>>>>
>>>>>> PS: Comet support is a nice to have, but I think there a way more
>>>>>> important things for core than that, eg. annotation-based validation
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Matej Knopp <ma...@gmail.com>.
On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer
<jo...@googlemail.com> wrote:
> It would be a big plus for me if Wicket would adopt jQuery. Drupal
> does that, and anyone writing a Drupal module can rely on the fact
> that jQuery is available. Same for Wordpress, where plugin authors can
> rely on the availability of jQuery. And not having to load more than
> one library, internal or not, is a good thing performance-wise.
>
> In response to your examples:
>
> Unbinding only particular event handlers without having a reference to
> the handler function can be achieved with namespaces:
> $(element).bind("click.somethingUnique", handleClick);
> $(element).unbind("click.somethingUnique");
But that's not quite the same. This requires me to use generate and
keep a unique string. Anyway, this is a cosmetic issue only.
>
> That way you don't have to keep a reference at all, while its possible
> to group multiple events into one namespace. This is now heavily used
> by most jQuery UI components when destroyed, to clean up their own
> event handlers without affecting any other.
>
> Multiple file upload we'll eventually have as part of jQuery UI. That
> would then be the same level of official and supported component that
> YUI provides. The descision to add new components is partly
> community-driven. So if you think multipart ajax uploads should be
> added, just ask for it.
This is not about "multiple file upload". We already have such
component in Wicket. This is about support for <input type="file"> on
ajax uploads - just use hidden frame instead of xml http request.
>
> About selectors: John Resig is currently working on a new selector
> engine that likely outperformances any other selector engine available
> so far. Its developed as a standalone library, so its likely that
> MochKit and Prototype will use it, too.
That sure is nice, but the selectors are not used in Wicket core at all.
> jQuery 1.3. will also provide heavy performance improvements for DOM
> manipulations, which I'm very exited about as that is usually where
> most time is spent. Its easy to avoid running certain selectors too
> often, but its hard to optimize DOM manipulation in clientcode.
While we at this, I'd like to ask. Significant part of Wicket ajax is
Wicket.replaceOuterHtml method. This was really a major pain to
implement and stabilize. What it does is basically a replaceOuterHTML
call for all browser but it works in totally cross browser consistent
way. I.e. it allows table rows, cells etc replaced in internet
explorer and it also executes embedded <script> tags on browsers that
would normally not do that (basically all except for Firefox). So my
question is, just out of curiosity, is there/will there be similar
functionality provided by jQuery?
>
> Anyway, thanks for taking the time to discuss this again.
Sure. Keep in mind that the decision is not carved to stone. I'm open
to argument, but I'm really interested in technical aspect. Having
"Microsoft will use jQuery" is not really a valid argument to me :)
-Matej
>
> Jörn
>
> On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp <ma...@gmail.com> wrote:
>> Are you really that surprised that Microsoft is not shipping YUI after
>> the failed attempts to take over Yahoo? :)
>>
>> Seriously, there are technical reasons why I considered to use YUI,
>> not political. Just because some companies use jQuery it doesn't mean
>> Wicket should use it. Say most of the companies use JSF, does it mean
>> we should?
>>
>> As I said, I really like the way YUI api is designed. Also there are
>> things in YUI "core" that are only available as jQuery plugins. The
>> plugins have different lifecycle than the core and are mantained
>> differently.
>>
>> Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket.
>>
>> Let me give you an example where I find YUI (3) api more elegant.
>> That's just one of many things and it is of course my personal
>> opinion.
>>
>> If i want to unbind event in jQuery, i need to remember event name and
>> the exact handler instance. For YUI, i get event handler on bind that
>> i can just call detach on and the event is unbound.
>>
>> var h = Y.on("click", handleClick, element);
>> h.detach();
>>
>> Of course it is possible to mock the behavior with jQuery, but that's
>> not really the point, is it?
>>
>> Another this is functionality provided in core. YUI can handle
>> multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's
>> very likely it will be as it was supported in 2.x). For jQuery, i need
>> to use a plugin for it.
>>
>> The reason why I feel so uneasy about plugins is that I've tried some.
>> And the quality really varies.
>>
>> I think selectors might be the part where jQuery really shines. But
>> that's the part not needed by Wicket at all. Plus YUI has selectors
>> too (although maybe not that fast - I don't know, haven't profiled
>> them). Also the new YUI3 node API resembles jQuery chaining API for
>> those who like it.
>>
>> -Matej
>>
>> On Mon, Sep 29, 2008 at 4:01 AM, Jörn Zaefferer
>> <jo...@googlemail.com> wrote:
>>> There is something new to consider when choosing a JavaScript library
>>> as Wicket's base:
>>> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
>>> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
>>>
>>> Jörn
>>>
>>> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com> wrote:
>>>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>>>> <jo...@googlemail.com> wrote:
>>>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <jw...@cabouge.com> 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.
>>>>>
>>>>> Of course there is the overhead of including two or more libraries in
>>>>> an application, which don't find desirable.
>>>>
>>>> Wicket uses only part of YUI, the compressed minified required YUI
>>>> javascript is about 20kb big. I would understand the concern if I used
>>>> dojo or some other behemoth with 200+ kb of compressed javascript.
>>>>
>>>>>
>>>>>>> + 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.
>>>>>
>>>>> You are well on the point that the variety of plugins varies. I see it
>>>>> this way: jQuery core is small, very stable and the base for
>>>>> everything else JS-related. jQuery UI is the official project
>>>>> providing the same stability and quality for various high-level UI
>>>>> components (like dialogs) and also low-level components (like
>>>>> drag&drop, sortables). We'll see at least two major releases this year
>>>>> that add more components to the mix. Anything else that isn't covered
>>>>> by core or UI is almost always covered by some third-party plugin.
>>>>> While these plugin can be of bady quality (eg. no
>>>>> documentation/demos), they can still provide a good starting point, so
>>>>> that you don't have to start from scratch. Even if you do a full
>>>>> rewrite, the existing plugin can expose useful information like
>>>>> potential browser-bug-traps.
>>>> Problem is that the jQuery core doesn't cut it. And rewriting plugins
>>>> from scratch? Are you serious? This is exactly the reason why I
>>>> decided to use YUI. The stuff that I need is there, it is supported
>>>> and maintained.
>>>>>
>>>>>> 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 :)
>>>>>
>>>>> Whatever the framework, I think its a good idea to start with
>>>>> something well supported and tested. Thats why I use Wicket, though
>>>>> I'd like it even more with jQuery as the base framework :-)
>>>>
>>>> At this point, I really don't see any advantage that YUI would give me
>>>> over jQuery.
>>>> Also it is possible that InMethod grid will be part of Wicket 1.5
>>>> extensions which is another point for using YUI. Rewriting the grid
>>>> with jquery would be a huge pain.
>>>>
>>>> -Matej
>>>>
>>>>>
>>>>> Jörn
>>>>>
>>>>> PS: Comet support is a nice to have, but I think there a way more
>>>>> important things for core than that, eg. annotation-based validation
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Jörn Zaefferer <jo...@googlemail.com>.
It would be a big plus for me if Wicket would adopt jQuery. Drupal
does that, and anyone writing a Drupal module can rely on the fact
that jQuery is available. Same for Wordpress, where plugin authors can
rely on the availability of jQuery. And not having to load more than
one library, internal or not, is a good thing performance-wise.
In response to your examples:
Unbinding only particular event handlers without having a reference to
the handler function can be achieved with namespaces:
$(element).bind("click.somethingUnique", handleClick);
$(element).unbind("click.somethingUnique");
That way you don't have to keep a reference at all, while its possible
to group multiple events into one namespace. This is now heavily used
by most jQuery UI components when destroyed, to clean up their own
event handlers without affecting any other.
Multiple file upload we'll eventually have as part of jQuery UI. That
would then be the same level of official and supported component that
YUI provides. The descision to add new components is partly
community-driven. So if you think multipart ajax uploads should be
added, just ask for it.
About selectors: John Resig is currently working on a new selector
engine that likely outperformances any other selector engine available
so far. Its developed as a standalone library, so its likely that
MochKit and Prototype will use it, too.
jQuery 1.3. will also provide heavy performance improvements for DOM
manipulations, which I'm very exited about as that is usually where
most time is spent. Its easy to avoid running certain selectors too
often, but its hard to optimize DOM manipulation in clientcode.
Anyway, thanks for taking the time to discuss this again.
Jörn
On Mon, Sep 29, 2008 at 12:54 PM, Matej Knopp <ma...@gmail.com> wrote:
> Are you really that surprised that Microsoft is not shipping YUI after
> the failed attempts to take over Yahoo? :)
>
> Seriously, there are technical reasons why I considered to use YUI,
> not political. Just because some companies use jQuery it doesn't mean
> Wicket should use it. Say most of the companies use JSF, does it mean
> we should?
>
> As I said, I really like the way YUI api is designed. Also there are
> things in YUI "core" that are only available as jQuery plugins. The
> plugins have different lifecycle than the core and are mantained
> differently.
>
> Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket.
>
> Let me give you an example where I find YUI (3) api more elegant.
> That's just one of many things and it is of course my personal
> opinion.
>
> If i want to unbind event in jQuery, i need to remember event name and
> the exact handler instance. For YUI, i get event handler on bind that
> i can just call detach on and the event is unbound.
>
> var h = Y.on("click", handleClick, element);
> h.detach();
>
> Of course it is possible to mock the behavior with jQuery, but that's
> not really the point, is it?
>
> Another this is functionality provided in core. YUI can handle
> multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's
> very likely it will be as it was supported in 2.x). For jQuery, i need
> to use a plugin for it.
>
> The reason why I feel so uneasy about plugins is that I've tried some.
> And the quality really varies.
>
> I think selectors might be the part where jQuery really shines. But
> that's the part not needed by Wicket at all. Plus YUI has selectors
> too (although maybe not that fast - I don't know, haven't profiled
> them). Also the new YUI3 node API resembles jQuery chaining API for
> those who like it.
>
> -Matej
>
> On Mon, Sep 29, 2008 at 4:01 AM, Jörn Zaefferer
> <jo...@googlemail.com> wrote:
>> There is something new to consider when choosing a JavaScript library
>> as Wicket's base:
>> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
>> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
>>
>> Jörn
>>
>> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com> wrote:
>>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>>> <jo...@googlemail.com> wrote:
>>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <jw...@cabouge.com> 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.
>>>>
>>>> Of course there is the overhead of including two or more libraries in
>>>> an application, which don't find desirable.
>>>
>>> Wicket uses only part of YUI, the compressed minified required YUI
>>> javascript is about 20kb big. I would understand the concern if I used
>>> dojo or some other behemoth with 200+ kb of compressed javascript.
>>>
>>>>
>>>>>> + 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.
>>>>
>>>> You are well on the point that the variety of plugins varies. I see it
>>>> this way: jQuery core is small, very stable and the base for
>>>> everything else JS-related. jQuery UI is the official project
>>>> providing the same stability and quality for various high-level UI
>>>> components (like dialogs) and also low-level components (like
>>>> drag&drop, sortables). We'll see at least two major releases this year
>>>> that add more components to the mix. Anything else that isn't covered
>>>> by core or UI is almost always covered by some third-party plugin.
>>>> While these plugin can be of bady quality (eg. no
>>>> documentation/demos), they can still provide a good starting point, so
>>>> that you don't have to start from scratch. Even if you do a full
>>>> rewrite, the existing plugin can expose useful information like
>>>> potential browser-bug-traps.
>>> Problem is that the jQuery core doesn't cut it. And rewriting plugins
>>> from scratch? Are you serious? This is exactly the reason why I
>>> decided to use YUI. The stuff that I need is there, it is supported
>>> and maintained.
>>>>
>>>>> 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 :)
>>>>
>>>> Whatever the framework, I think its a good idea to start with
>>>> something well supported and tested. Thats why I use Wicket, though
>>>> I'd like it even more with jQuery as the base framework :-)
>>>
>>> At this point, I really don't see any advantage that YUI would give me
>>> over jQuery.
>>> Also it is possible that InMethod grid will be part of Wicket 1.5
>>> extensions which is another point for using YUI. Rewriting the grid
>>> with jquery would be a huge pain.
>>>
>>> -Matej
>>>
>>>>
>>>> Jörn
>>>>
>>>> PS: Comet support is a nice to have, but I think there a way more
>>>> important things for core than that, eg. annotation-based validation
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Matej Knopp <ma...@gmail.com>.
Are you really that surprised that Microsoft is not shipping YUI after
the failed attempts to take over Yahoo? :)
Seriously, there are technical reasons why I considered to use YUI,
not political. Just because some companies use jQuery it doesn't mean
Wicket should use it. Say most of the companies use JSF, does it mean
we should?
As I said, I really like the way YUI api is designed. Also there are
things in YUI "core" that are only available as jQuery plugins. The
plugins have different lifecycle than the core and are mantained
differently.
Also keep in mind that the javascript Wicket-Ajax uses is internal to Wicket.
Let me give you an example where I find YUI (3) api more elegant.
That's just one of many things and it is of course my personal
opinion.
If i want to unbind event in jQuery, i need to remember event name and
the exact handler instance. For YUI, i get event handler on bind that
i can just call detach on and the event is unbound.
var h = Y.on("click", handleClick, element);
h.detach();
Of course it is possible to mock the behavior with jQuery, but that's
not really the point, is it?
Another this is functionality provided in core. YUI can handle
multipart Ajax uploads (well, it can't do that in 3.0 yet, but it's
very likely it will be as it was supported in 2.x). For jQuery, i need
to use a plugin for it.
The reason why I feel so uneasy about plugins is that I've tried some.
And the quality really varies.
I think selectors might be the part where jQuery really shines. But
that's the part not needed by Wicket at all. Plus YUI has selectors
too (although maybe not that fast - I don't know, haven't profiled
them). Also the new YUI3 node API resembles jQuery chaining API for
those who like it.
-Matej
On Mon, Sep 29, 2008 at 4:01 AM, Jörn Zaefferer
<jo...@googlemail.com> wrote:
> There is something new to consider when choosing a JavaScript library
> as Wicket's base:
> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
>
> Jörn
>
> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com> wrote:
>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>> <jo...@googlemail.com> wrote:
>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <jw...@cabouge.com> 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.
>>>
>>> Of course there is the overhead of including two or more libraries in
>>> an application, which don't find desirable.
>>
>> Wicket uses only part of YUI, the compressed minified required YUI
>> javascript is about 20kb big. I would understand the concern if I used
>> dojo or some other behemoth with 200+ kb of compressed javascript.
>>
>>>
>>>>> + 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.
>>>
>>> You are well on the point that the variety of plugins varies. I see it
>>> this way: jQuery core is small, very stable and the base for
>>> everything else JS-related. jQuery UI is the official project
>>> providing the same stability and quality for various high-level UI
>>> components (like dialogs) and also low-level components (like
>>> drag&drop, sortables). We'll see at least two major releases this year
>>> that add more components to the mix. Anything else that isn't covered
>>> by core or UI is almost always covered by some third-party plugin.
>>> While these plugin can be of bady quality (eg. no
>>> documentation/demos), they can still provide a good starting point, so
>>> that you don't have to start from scratch. Even if you do a full
>>> rewrite, the existing plugin can expose useful information like
>>> potential browser-bug-traps.
>> Problem is that the jQuery core doesn't cut it. And rewriting plugins
>> from scratch? Are you serious? This is exactly the reason why I
>> decided to use YUI. The stuff that I need is there, it is supported
>> and maintained.
>>>
>>>> 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 :)
>>>
>>> Whatever the framework, I think its a good idea to start with
>>> something well supported and tested. Thats why I use Wicket, though
>>> I'd like it even more with jQuery as the base framework :-)
>>
>> At this point, I really don't see any advantage that YUI would give me
>> over jQuery.
>> Also it is possible that InMethod grid will be part of Wicket 1.5
>> extensions which is another point for using YUI. Rewriting the grid
>> with jquery would be a huge pain.
>>
>> -Matej
>>
>>>
>>> Jörn
>>>
>>> PS: Comet support is a nice to have, but I think there a way more
>>> important things for core than that, eg. annotation-based validation
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by jWeekend <jw...@cabouge.com>.
Igor,
I should say that I was convinced already, by Matej's first response [1] to
my original post on this thread, that this decision (not to mention Matej's
expertise and hard work) will give us a robust, flexible and maintainable
underlying infrastructure with no perceivable impact on the component or
application developers' range of client-side library choices.
Regads - Cemal
http://www.jWeekend.co.uk http://jWeekend.co.uk
[ http://www.nabble.com/forum/ViewPost.jtp?post=19169614&framed=y 1 ]
igor.vaynberg wrote:
>
> im not sure why you guys are making such a big deal out of this. we
> are talking about javascript that is entirely internal to wicket. you
> never see it, you never touch it. it is completely namespaced in
> wicket's namespace.
>
> we have chosen a library that we are comfortable working with. if we
> can get our stuff done faster and easier with yui then that is what we
> are going to use...
>
> sure, we might use it to write some high level components (eg modal
> window) that we ship with wicket, but those do not use any internal
> api. there is absolutely nothing stopping you from writing your own
> jquery-driven modal window component.
>
> so my question to you guys is: why does it matter to you which
> javascript framework we use under the hood?
>
> -igor
>
> On Sun, Sep 28, 2008 at 7:01 PM, Jörn Zaefferer
> <jo...@googlemail.com> wrote:
>> There is something new to consider when choosing a JavaScript library
>> as Wicket's base:
>> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
>> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
>>
>> Jörn
>>
>> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com>
>> wrote:
>>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>>> <jo...@googlemail.com> wrote:
>>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend
>>>>> <jw...@cabouge.com> 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.
>>>>
>>>> Of course there is the overhead of including two or more libraries in
>>>> an application, which don't find desirable.
>>>
>>> Wicket uses only part of YUI, the compressed minified required YUI
>>> javascript is about 20kb big. I would understand the concern if I used
>>> dojo or some other behemoth with 200+ kb of compressed javascript.
>>>
>>>>
>>>>>> + 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.
>>>>
>>>> You are well on the point that the variety of plugins varies. I see it
>>>> this way: jQuery core is small, very stable and the base for
>>>> everything else JS-related. jQuery UI is the official project
>>>> providing the same stability and quality for various high-level UI
>>>> components (like dialogs) and also low-level components (like
>>>> drag&drop, sortables). We'll see at least two major releases this year
>>>> that add more components to the mix. Anything else that isn't covered
>>>> by core or UI is almost always covered by some third-party plugin.
>>>> While these plugin can be of bady quality (eg. no
>>>> documentation/demos), they can still provide a good starting point, so
>>>> that you don't have to start from scratch. Even if you do a full
>>>> rewrite, the existing plugin can expose useful information like
>>>> potential browser-bug-traps.
>>> Problem is that the jQuery core doesn't cut it. And rewriting plugins
>>> from scratch? Are you serious? This is exactly the reason why I
>>> decided to use YUI. The stuff that I need is there, it is supported
>>> and maintained.
>>>>
>>>>> 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 :)
>>>>
>>>> Whatever the framework, I think its a good idea to start with
>>>> something well supported and tested. Thats why I use Wicket, though
>>>> I'd like it even more with jQuery as the base framework :-)
>>>
>>> At this point, I really don't see any advantage that YUI would give me
>>> over jQuery.
>>> Also it is possible that InMethod grid will be part of Wicket 1.5
>>> extensions which is another point for using YUI. Rewriting the grid
>>> with jquery would be a huge pain.
>>>
>>> -Matej
>>>
>>>>
>>>> Jörn
>>>>
>>>> PS: Comet support is a nice to have, but I think there a way more
>>>> important things for core than that, eg. annotation-based validation
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
--
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-tp19168620p19720842.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: "WANG–Wicket Ajax Next Generation–being based on YUI" (MD)
Posted by Igor Vaynberg <ig...@gmail.com>.
im not sure why you guys are making such a big deal out of this. we
are talking about javascript that is entirely internal to wicket. you
never see it, you never touch it. it is completely namespaced in
wicket's namespace.
we have chosen a library that we are comfortable working with. if we
can get our stuff done faster and easier with yui then that is what we
are going to use...
sure, we might use it to write some high level components (eg modal
window) that we ship with wicket, but those do not use any internal
api. there is absolutely nothing stopping you from writing your own
jquery-driven modal window component.
so my question to you guys is: why does it matter to you which
javascript framework we use under the hood?
-igor
On Sun, Sep 28, 2008 at 7:01 PM, Jörn Zaefferer
<jo...@googlemail.com> wrote:
> There is something new to consider when choosing a JavaScript library
> as Wicket's base:
> http://www.jondavis.net/blog/post/2008/09/jQuery-Has-Won-The-3-Year-Javascript-Framework-Battle-As-Far-As-Im-Concerned.aspx
> http://www.hanselman.com/blog/jQuerytoshipwithASPNETMVCandVisualStudio.aspx
>
> Jörn
>
> On Wed, Aug 27, 2008 at 1:05 AM, Matej Knopp <ma...@gmail.com> wrote:
>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>> <jo...@googlemail.com> wrote:
>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <ma...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <jw...@cabouge.com> 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.
>>>
>>> Of course there is the overhead of including two or more libraries in
>>> an application, which don't find desirable.
>>
>> Wicket uses only part of YUI, the compressed minified required YUI
>> javascript is about 20kb big. I would understand the concern if I used
>> dojo or some other behemoth with 200+ kb of compressed javascript.
>>
>>>
>>>>> + 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.
>>>
>>> You are well on the point that the variety of plugins varies. I see it
>>> this way: jQuery core is small, very stable and the base for
>>> everything else JS-related. jQuery UI is the official project
>>> providing the same stability and quality for various high-level UI
>>> components (like dialogs) and also low-level components (like
>>> drag&drop, sortables). We'll see at least two major releases this year
>>> that add more components to the mix. Anything else that isn't covered
>>> by core or UI is almost always covered by some third-party plugin.
>>> While these plugin can be of bady quality (eg. no
>>> documentation/demos), they can still provide a good starting point, so
>>> that you don't have to start from scratch. Even if you do a full
>>> rewrite, the existing plugin can expose useful information like
>>> potential browser-bug-traps.
>> Problem is that the jQuery core doesn't cut it. And rewriting plugins
>> from scratch? Are you serious? This is exactly the reason why I
>> decided to use YUI. The stuff that I need is there, it is supported
>> and maintained.
>>>
>>>> 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 :)
>>>
>>> Whatever the framework, I think its a good idea to start with
>>> something well supported and tested. Thats why I use Wicket, though
>>> I'd like it even more with jQuery as the base framework :-)
>>
>> At this point, I really don't see any advantage that YUI would give me
>> over jQuery.
>> Also it is possible that InMethod grid will be part of Wicket 1.5
>> extensions which is another point for using YUI. Rewriting the grid
>> with jquery would be a huge pain.
>>
>> -Matej
>>
>>>
>>> Jörn
>>>
>>> PS: Comet support is a nice to have, but I think there a way more
>>> important things for core than that, eg. annotation-based validation
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org