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 <[EMAIL PROTECTED]> wrote:
> 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]
>
>
