Andrea, thanks but I'm not really looking for "workarounds" (right now
using [0] ... works) but rather I'm asking the devs of JQuery when is
this going to be taken care of in the official release (and not have
users waste hours trying to figure out what's wrong with their code
before they find the relevant topics (searching for object and jquery
doesn't help ... )
On Oct 30, 2:58 am, "Andrea Giammarchi" <[EMAIL PROTECTED]>
wrote:
> Ops,
>
> function __call__(name, args){
> this.each(function(){
> this[name].apply(this, args || []);
> });
> return this;
> };
>
> better ... this should let you do something like
>
> $("#objectid").Render();
>
> On Thu, Oct 30, 2008 at 9:57 AM, Andrea Giammarchi <
>
> [EMAIL PROTECTED]> wrote:
> > I am not sure I understand the problem, but as theoretical work around this
> > should work, does it?
>
> > jQuery.fn.init = function(init){
> > function __create__(name){
> > return __create__[name] || (__create__[name] = function(){
> > return __call__.call(this, name, arguments);
> > })
> > };
> > function __call__(name, arguments){
> > this.each(function(){
> > this[name].apply(this, arguments || []);
> > });
> > return this;
> > };
> > var object = /applet|embed|object/i;
> > return function(selector, context){
> > var ret = init.call(this, selector, context);
> > if(ret.length && object.test(ret[0].nodeName)){
> > ret = init.call(this, ret[0].nodeName.toLowerCase() + selector,
> > context);
> > for(var methods =
> > "Render.TCallLabel.OthersOptionally".split("."), i = 0, length =
> > methods.length; i < length; i++)
> > ret[methods[i]] = __create__(methods[i]);
> > };
> > return ret;
> > }
> > }(jQuery.fn.init);
>
> > I did not test it, it's just the concept, please let me know if it is what
> > you were looking for.
>
> > On Thu, Oct 30, 2008 at 9:31 AM, Valentin <[EMAIL PROTECTED]>wrote:
>
> >> Yes my natural instinct was to use $('#object_id').Render() ... I
> >> found out this doesn't work (funny it didn't work in Prototype, which
> >> I used to use until 3 days ago when I got annoyed with their zillion
> >> bugs ...)
>
> >> So I'm using $('object#object_id')[0].Render() right now.
>
> >> But what about hide(), show() or other usual stuff (set css, etc.)
> >> that should work, and I shouldn't have to write a whole new syntax for
> >> them ...
>
> >> (ie right now I have to write $('object#object_id')[0].hide() instead
> >> of $('#object_id').hide() ...
>
> >> Plus the error on the unload (which I fixed temporarily using the
> >> patch presented in the link above -- the last two posts, but I would
> >> rather have JQuery come up with an official solution for this -- as I
> >> said this is an important issue, right now and for the future.)
>
> >> On Oct 30, 1:03 am, "Andrea Giammarchi" <[EMAIL PROTECTED]>
> >> wrote:
> >> > Yes, the summary is this: $('object')[0].Render();
> >> > but Valentin probably expect same call for every matched object like:
>
> >> > $('object').each(function(){this.Render()});
>
> >> > sounds weird to me, but could be useful in some case, the problem is the
> >> > returned value witn a $('object').Render() or $('object').TCallLabel()
> >> ...
> >> > one result, an arry with every result for each index, or jQuery itself?
>
> >> > The specific plugin should be simple in every case, but we miss the
> >> expected
> >> > behavior ... Valentin?
>
> >> > On Thu, Oct 30, 2008 at 1:42 AM, Ariel Flesler <[EMAIL PROTECTED]>
> >> wrote:
>
> >> > > Definitely not something to add to the core, but easily doable with a
> >> > > plugin by overloading $.fn.init or by simply adding to $.fn.
>
> >> > > I haven't interacted with stuff like that, but if I'm not wrong, the
> >> > > gral pattern for this stuff would be something like:
> >> > > $('object')[0].Render();
>
> >> > > It's the first I see such an idea of adding methods to a jQuery object
> >> > > to handle specific elements inside it...
> >> > > Still.. why not ?
>
> >> > > One idea, what about using/adding the object's id as jquery cache's
> >> > > id ? It can't be just a number so no conflict can arise.
> >> > > Problem is, we're modifying the environment what we usually don't do.
>
> >> > > --
> >> > > Ariel Flesler
> >> > >http://flesler.blogspot.com/
>
> >> > > On Oct 29, 7:58 pm, "Andrea Giammarchi" <[EMAIL PROTECTED]>
> >> > > wrote:
> >> > > > $('#id_of_object').Render()
>
> >> > > > really interesting problem, I am thinking about JS to Flash
> >> dedicated
> >> > > > functions as well.
>
> >> > > > Since there is a __defineGetter__ or a watch that work pretty well
> >> but
> >> > > does
> >> > > > not make sense in IE, I think the core should be check if the
> >> element
> >> > > > nodeName is an object and in that case assign a list of "fake
> >> functions"
> >> > > > that invokes a specific one able to manage every case.
>
> >> > > > As example, the returned jQuery ArrayObject, if the element is an
> >> object,
> >> > > > should contain functions like:
> >> > > > Render:function(){
> >> > > > return objectCallback.call(this, 'Render', arguments);},
>
> >> > > > TCallLabel**:function(){
> >> > > > return objectCallback.call(this, 'TCallLabel**', arguments);}
>
> >> > > > and so on, with those functions pre defined externally to avoid
> >> creation
> >> > > of
> >> > > > hundreds of functions that do the same every time.
>
> >> > > > the objectCallback function should be something like
> >> > > > function objectCallback(fnName, arguments){
> >> > > > return this[0][fnName].apply(this[0], arguments || []);
>
> >> > > > }
>
> >> > > > this means prepare the core to accept every kind of calable method
> >> for
> >> > > > video, object, applet, whatever tag ... so I suppose it should be
> >> better
> >> > > to
> >> > > > let people be able to implement what they need, creating specific
> >> plugins
> >> > > > for every kind of tag.
>
> >> > > > Is my idea that bad?
>
> >> > > > Regards
>
> >> > > > On Wed, Oct 29, 2008 at 8:01 PM, Valentin <
> >> [EMAIL PROTECTED]
> >> > > >wrote:
>
> >> > > > > John,
>
> >> > > > > Thansk for the quick answer. On my testing environment I've
> >> applied
> >> > > > > the "patch" described in the bug ticket (the last two posts) and
> >> that
> >> > > > > took away the error on the unload. Still everything else remains
> >> > > > > there. The funny thing is that I discovered this morning that I
> >> can
> >> > > > > select an object with the following clause
>
> >> > > > > $('object#id_of_object') and the properties work on Firefox then
> >> > > > > (hide, show etc.)
>
> >> > > > > If I try $('#id_of_object') this doesn't work.
>
> >> > > > > Anyway, is there a time-table for the next version of the Jquery
> >> that
> >> > > > > addresses (at least part of) these issues?
>
> >> > > > > On Oct 29, 10:01 am, "John Resig" <[EMAIL PROTECTED]> wrote:
> >> > > > > > I definitely agree that this is a big issue. We've discussed
> >> this
> >> > > > > > before but were unclear as to the ramifications of not attaching
> >> > > > > > anything to these specific elements. Although since code is
> >> breaking
> >> > > > > > it definitely takes a high priority for us.
>
> >> > > > > > I'm not sure if the code to handle this should be in jQuery.data
> >> or
> >> > > > > > outside of it. I'm worried that if it's inside it'll
> >> significantly
> >> > > > > > slow down the number of cases where the method is referenced.
>
> >> > > > > > At the very least we've already resolved the unload issue in the
> >> > > > > > nightlies - it's just a matter of attempting to fix the other
> >> issues
> >> > > > > > at play (events, selectors, and hide/show mostly).
>
> >> > > > > > --John
>
> >> > > > > > On Wed, Oct 29, 2008 at 12:21 PM, Valentin <
> >> > > [EMAIL PROTECTED]>
> >> > > > > wrote:
>
> >> > > > > > > As some of you know JQuery (as well as Prototype -- this was
> >> > > initially
> >> > > > > > > one of the reasons for switching) has serious issues when
> >> dealing
> >> > > with
> >> > > > > > > the <object>, <embed> or <applet> tags.
>
> >> > > > > > > If one decides to be XHTML 1.0 strict compliant we have to use
> >> the
> >> > > > > > > <object> tag right now for Java applets, Flash movies, and
> >> other
> >> > > such
> >> > > > > > > stuff.
>
> >> > > > > > > But because of a bug in the internal code of Jquery (namely
> >> this
> >> > > one:
> >> > > > > > >http://dev.jquery.com/ticket/2349) we can't really use
> >> something
> >> > > > > > > like
>
> >> > > > > > > $('#id_of_object').hide() or even stuff that's relative to the
> >> > > applet
> >> > > > > > > (so say your applet has external function such as
> >> applet.Render()
> >> > > we
> >> > > > > > > can't use $('#id_of_object').Render() )
>
> >> > > > > > > Since the upcoming XHTML 2.0 Specs will require pretty much
> >> > > everything
> >> > > > > > > but text to be inside an object tag I'm curious when this
> >> problem
> >> > > is
> >> > > > > > > going to be solved and how ...
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
