On Mon, Sep 29, 2008 at 11: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). 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 <[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]