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
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> On Mon, Sep 29, 2008 at 1:18 PM, Jörn Zaefferer
>> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>>>> <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>>>>>> On Wed, Aug 27, 2008 at 12:50 AM, Jörn Zaefferer
>>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>>> On Tue, Aug 26, 2008 at 10:19 PM, Matej Knopp <[EMAIL PROTECTED]> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Tue, Aug 26, 2008 at 9:24 PM, jWeekend <[EMAIL PROTECTED]> wrote:
>>>>>>>>>
>>>>>>>>> Matej,
>>>>>>>>>
>>>>>>>>> What are the implications of the decision to "base Wicket Ajax Next
>>>>>>>>> Generation on YUI" in terms of choosing a Javascript library for
>>>>>>>>> future
>>>>>>>>> Wicket based web front ends?
>>>>>>>> actually, there really are none. The use of YUI will be more or less
>>>>>>>> internal to Wicket, so you can continue using jQuery, YUI2 or whatever
>>>>>>>> else you are using. Everything in Wicket (and YUI) is namespaced so
>>>>>>>> there are no conflicts.
>>>>>>>
>>>>>>> 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: [EMAIL PROTECTED]
>>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
