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 jquery-dev@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
