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 mo
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
On Tue, Sep 30, 2008 at 3:27 PM, Matej Knopp <[EMAIL PROTECTED]> 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.). La
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
Thanks for the response.
On Tue, Sep 30, 2008 at 5:11 AM, Jörn Zaefferer
<[EMAIL PROTECTED]> 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 c
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 implementi
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 a
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
be
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
completel
Wicket.replaceOuterHTML(element, ""); would be this in jQuery:
$(element).after("").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
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-n
On Mon, Sep 29, 2008 at 11:13 PM, Jörn Zaefferer
<[EMAIL PROTECTED]> 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
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 i
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 rela
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 p
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
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
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 companie
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 ge
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
<[EMAIL PROTECTED]> wrote:
> There is something new to cons
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 W
>>
>> 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
>>
You can have annotation based validation already. It is possible to do
even with Wicket 1.3. I don't see how that is related to comet
support
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 t
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 libr
I'm generally not against having push in core, so any suggestion about
how the api should look like is appreciated.
-Matej
On Tue, Aug 26, 2008 at 11:12 PM, Peter Ertl <[EMAIL PROTECTED]> wrote:
> +1 for including support for cometd in wicket core
>
> I expect server side push the next great thin
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
26 matches
Mail list logo