[Prototype-core] Re: function for script loading
Why not use JSLoad directly ? Best, Tobie On Nov 19, 12:41 pm, Yaffle [EMAIL PROTECTED] wrote: hello I can't find in prototype.js function, that can load javascript such as jsload http://code.google.com/p/jsload/downloads/list It may be very useful. How about add to prototype lite version of this function? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $$ function needs context attribute?
On 10/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think is is good to create a new function called $$$ or something like that to make a short selector function and supports context. We use Element#select to constrain the lookup to a certain element: $(foo).select(img) We discussed adding a context argument to $$ a while ago, but it just didn't turn out worthwhile, I guess. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $$ function needs context attribute?
Oh, the select method, I haven't use it, and the context is
important for the css selector, and in the case
Selector.findChildElements supports the context, So only change the $
$ function and to check whether the last argument is HTML element or
not is enough. And context is really very important for css selector,
it make the selector much more flexible.especially in the
$$().each(function(node){
$$(,node).doSomething()
})
On Oct 17, 6:43 pm, Mislav Marohni [EMAIL PROTECTED]
wrote:
On 10/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I think is is good to create a new function
called $$$ or something like that to make a short selector function
and supports context.
We use Element#select to constrain the lookup to a certain element:
$(foo).select(img)
We discussed adding a context argument to $$ a while ago, but it just didn't
turn out worthwhile, I guess.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
Finally, an aside on not having control over the HTML source: I ran into this issue when using the radio_button_tag helper method in Rails, which inconveniently used the name of the input as the id - unhelpful, as all the radio buttons in a group have the same name in order to group them. That's somewhat brain-dead behavior on the part of Rails. I'd encourage you to file a bug report on the ActionView component. Indeed, and at the time, the bug was already fixed in trunk, and the fix finally made it into rails 1.2. If you're interested, see http://dev.rubyonrails.org/ticket/3353 Rebecca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
I'd like to add a bit of OT to the discussion, but relating to the $ function itself. Currently, $ wil not return an element, whose id is a number, whereas getElementById will. The fix, as you can imagine, is pretty simple. I myself just changed the following line: if (typeof element == 'string') to: if (typeof element == 'string' || typeof element == 'number') I don't know if this is the most optimized way though. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On 6/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Currently, $ wil not return an element, whose id is a number, whereas getElementById will. A number is an illegal ID value. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
As advised here: http://www.w3.org/TR/html401/types.html#type-name ID and NAME tokens must begin with a letter ([A-Za-z]) [...] Which clearly implies that ids cannot be number only. On Jun 24, 1:25 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'd like to add a bit of OT to the discussion, but relating to the $ function itself. Currently, $ wil not return an element, whose id is a number, whereas getElementById will. The fix, as you can imagine, is pretty simple. I myself just changed the following line: if (typeof element == 'string') to: if (typeof element == 'string' || typeof element == 'number') I don't know if this is the most optimized way though. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On Jun 21, 6:30 am, Rebecca Blyth [EMAIL PROTECTED] wrote: Finally, an aside on not having control over the HTML source: I ran into this issue when using the radio_button_tag helper method in Rails, which inconveniently used the name of the input as the id - unhelpful, as all the radio buttons in a group have the same name in order to group them. That's somewhat brain-dead behavior on the part of Rails. I'd encourage you to file a bug report on the ActionView component. Cheers, Andrew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
I know I'm a little late on this one, but as the person who originally filed the bug report, I thought I'd put in a word... Personally, I'm happy with leaving the $() function untouched. People who get caught out by it will now be able to see what the problem is and what the workarounds are, and even have code they can use as a wrapper if they want, thanks to the patch on Trac and the messages here that include code. Finally, an aside on not having control over the HTML source: I ran into this issue when using the radio_button_tag helper method in Rails, which inconveniently used the name of the input as the id - unhelpful, as all the radio buttons in a group have the same name in order to group them. This may be the sort of thing people are talking about when they say they don't have control over the HTML source - changing what your HTML generator outputs can be fiddly, if you've not looked at how it works. Fiddling with rails was actually fairly easy, but I've had to do similar things to another templating engine and that was a lot harder! Rebecca --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
input type=text value=this should be returned name=test id=www /
input type=text value=this should not be returned ff2.0 bug not
appeared in ff3.0 a5 name=test id=www /
This is not valid HTML. It has 2 different elements with the same ID, in
which you get unexpected behavior with getElementById.
1.In ie the only way to change a input element's attribute name is
to change outerHTML?
Yes, you are basically re-writing the element. That is never smart.
3.Is there a regular expression to get out the name attribute from
these two strings 'input type=button value=aaa lll name=lll /'
and'input type=button value=aaa lll name=lll l /' one name with
one without, and the method to modify it. Thanks
Of course there is, but there is no sense in making it. I think you now need
to stop trying to solve this with outerHTML because it's just plain wrong
and you'll just have problems down the line.
There are only 3 possible options we're facing:
1. Don't change the $ function, leave everything as-is;
2. Fix the issue in $ by using $$('*[id=foo]');
3. Don't fix the issue, throw error instead.
I don't believe we need to discuss anything else but these.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
My solution, maybe too complicated, one path for opera which is pretty
good and with good performance, the path for internet explorer which
is complicated, and for my testing it is stable, hope it can make $ to
be much more cross-browser, I believe the js framework should fix the
browser's bug, the path for ie won't work on opera and of course the
path for opera won't work on ie, complicated.
function $(element) {
if (arguments.length 1) {
for (var i = 0, elements = [], length = arguments.length; i
length; i++)
elements.push($(arguments[i]));
return elements;
}
if (typeof element == 'string')
{
var id=element;
element = document.getElementById(element);
var tmp=[];
var t=document.getElementById(id);
if (Prototype.Browser.IE)
{
while(t!=null t.id!=id)
{
var e=t.outerHTML;
t.outerHTML=t.outerHTML.indexOf('name=')!=-1?
t.outerHTML.replace('name='+t.name+'','name='+t.name
+'_tmp_'):t.outerHTML.replace('name='+t.name,'name='+t.name+'_tmp_')
tmp.push([document.getElementById(t.name+_tmp_),e])
t=document.getElementById(id);
}
tmp.each(function(node){node[0].outerHTML=node[1]});
}
else if(Prototype.Browser.Opera)
{
while(t!=null t.id!=id)
{
tmp.push([t,t.name])
t.name+=_tmp_;
t=document.getElementById(id);
}
tmp.each(function(node){node[0].name=node[1]});
}
element=t;
}
return Element.extend(element);
}
On Jun 18, 3:01 pm, Mislav Marohnić [EMAIL PROTECTED]
wrote:
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
input type=text value=this should be returned name=test id=www /
input type=text value=this should not be returned ff2.0 bug not
appeared in ff3.0 a5 name=test id=www /
This is not valid HTML. It has 2 different elements with the same ID, in
which you get unexpected behavior with getElementById.
1.In ie the only way to change a input element's attribute name is
to change outerHTML?
Yes, you are basically re-writing the element. That is never smart.
3.Is there a regular expression to get out the name attribute from
these two strings 'input type=button value=aaa lll name=lll /'
and'input type=button value=aaa lll name=lll l /' one name with
one without, and the method to modify it. Thanks
Of course there is, but there is no sense in making it. I think you now need
to stop trying to solve this with outerHTML because it's just plain wrong
and you'll just have problems down the line.
There are only 3 possible options we're facing:
1. Don't change the $ function, leave everything as-is;
2. Fix the issue in $ by using $$('*[id=foo]');
3. Don't fix the issue, throw error instead.
I don't believe we need to discuss anything else but these.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My solution, maybe too complicated, one path for opera which is pretty good and with good performance, the path for internet explorer which is complicated, and for my testing it is stable Your solution may suit you but we will not accept anything that messes with the document. So now let this discussion go in the direction of the 3 items I suggested. No alternative solutions will be accepted (unless they are something brilliant we haven't thought of before). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
The only solution that could be faster than this is to temporary delete the name of the found element and repeat the $() call, after which the name would be restored. Unfortunately it isn't possible. I think my solution is something like what you said, I doubt it will get a better performance, especially in ie, so many outerHTML changing, and for $ function, because this is really an edge case, $$(*[id=...]) should fix it only the performance hit, ie and opera's misbehaving on the input's name is unreasonable, so correcting it by $$ should be the best. And for my solution, it is too ugly, I won't use it, just prove you can change the name and fix it. On Jun 18, 5:33 pm, Mislav Marohnić [EMAIL PROTECTED] wrote: On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: My solution, maybe too complicated, one path for opera which is pretty good and with good performance, the path for internet explorer which is complicated, and for my testing it is stable Your solution may suit you but we will not accept anything that messes with the document. So now let this discussion go in the direction of the 3 items I suggested. No alternative solutions will be accepted (unless they are something brilliant we haven't thought of before). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
And for my solution, it is too ugly, I won't use it, just prove you can change the name and fix it. Ya, unfortunately, in the process you've also removed any event handler that could have been set on the element. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
Tks, I quite do not understand outerHTML, oh this would remove all the event handlers, in opera only change name attribute won't remove the event handlers? I think so. IE, misbahaving make me confused on you, why does IE implement the DOM basic method like this, any reasonable reason? Thanks ;) On Jun 18, 6:07 pm, Tobie Langel [EMAIL PROTECTED] wrote: And for my solution, it is too ugly, I won't use it, just prove you can change the name and fix it. Ya, unfortunately, in the process you've also removed any event handler that could have been set on the element. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
outerHTML is proprietary... so we can't really say it misbehaves ;) On Jun 18, 6:23 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tks, I quite do not understand outerHTML, oh this would remove all the event handlers, in opera only change name attribute won't remove the event handlers? I think so. IE, misbahaving make me confused on you, why does IE implement the DOM basic method like this, any reasonable reason? Thanks ;) On Jun 18, 6:07 pm, Tobie Langel [EMAIL PROTECTED] wrote: And for my solution, it is too ugly, I won't use it, just prove you can change the name and fix it. Ya, unfortunately, in the process you've also removed any event handler that could have been set on the element. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
Not only IE and Opera, of course firefox, look at this code
script src=prototype.js/script
input type=text value=this should be returned name=test
id=www /
input type=text value=this should not be returned ff2.0 bug not
appeared in ff3.0 a5
name=test id=www /
script
alert($(www).value)
window.setTimeout(function(){alert($(www).value)},1000)
/script
This page give out the same result on ie opera safari, but in ff2.0,
the second alert return the second id matched element, and I have
downloaded the ff3.0 alpha5, it give the result which the ie opera
gives, and be different with ff2.0, so I believe this is may be a
gecko 1.8* rendering problem, and be fixed in the gecko 1.9*, even the
firefox has some problems on getElementById, so do not care too much
about that thing.
On Jun 18, 11:07 pm, Радослав Станков [EMAIL PROTECTED] wrote:
I really think that name and id should be different no to overload $()
with more functionality.
Besides it is easy to catch such error if there are names equal to ids
even in complicated JS scripts.
here http://video.yahoo.com/video/play?vid=410472near 10 minute to
see more problems with IE and Opera with getElementById
p.s. In my last project I found that I was call $ over 7070 times
when I pass throw main features in 3-5 minutes, and think on IE what
will happen if we have additonal $$ or some stuff like that !
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Not only IE and Opera, of course firefox, look at this code Dude, I told you ... you have 2 elements with the same ID ... and you want us to fix it in the framework?? Can't do, sorry. You'll just have to learn to code better. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: and the firefox because I call the getElementById has disturb his understanding on the DOM structure and the second call return me the second matched Look how much I care about this problem: http://prototypejs.org/assets/2007/3/13/mislav.jpg It's time to stop talking about this and concentrate on the real issues: http://dev.rubyonrails.org/query?status=newstatus=assignedstatus=reopenedgroup=typecomponent=Prototypeorder=iddesc=1 Thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On Jun 18, 2:01 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
There are only 3 possible options we're facing:
1. Don't change the $ function, leave everything as-is;
2. Fix the issue in $ by using $$('*[id=foo]');
3. Don't fix the issue, throw error instead.
My vote is for #1. The $ function is intended to be a light wrapper
around document.getElementById. The impulse is noble to want to
correct IE's incorrect behavior (and Opera's emulation thereof), but I
think it's just a little too heavy.
Cheers,
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
my vote is #1
It is up to the devs to a) use the name and id attributes properly, and b)
wrap anything you want any way you want in some custom wrappers file that
you load in after prototype (or whatever library it is you are creating the
wrapper for).
For instance, I have never had this problem, nor do I think I ever will (if
an element i want does not have an id, I can either add one or get the
reference via some other selector on a case by case basis -- basically the
name attribute has no value to me whatsoever)... but if I had this need I'd
know I can just rely on the mutable nature of javascript and redefine the
$() within my app to behave however I want.
If this type of change _does_ make it into prototype, it would be an
addition of unnecessary code, IMHO.
On 6/18/07, Adam McCrea [EMAIL PROTECTED] wrote:
So sorry to beat this dead horse, but I just want to weigh in my thoughts
on this before it gets shot down. I agree that $ should only be a light
wrapper around getElementById, but unfortunately getElementById is broken
across browsers. I'm surprised to hear that you think the fix is heavy. In
my eyes it is a lightweight fix to save some major headaches for those who
don't have control over the HTML source.
My vote is for #2!
- Adam
On 6/18/07, Andrew Dupont [EMAIL PROTECTED] wrote:
On Jun 18, 2:01 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
There are only 3 possible options we're facing:
1. Don't change the $ function, leave everything as-is;
2. Fix the issue in $ by using $$('*[id=foo]');
3. Don't fix the issue, throw error instead.
My vote is for #1. The $ function is intended to be a light wrapper
around document.getElementById . The impulse is noble to want to
correct IE's incorrect behavior (and Opera's emulation thereof), but I
think it's just a little too heavy.
Cheers,
Andrew
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
but if I had this need I'd know I can just rely on the mutable nature of
javascript and redefine the $() within my app to behave however I want.
Very true, and I have done just that. My goal was not only to help myself,
but also others in the future who might not realize what is happening and
why. I can certainly understand and respect why don't think it belongs,
though.
- Adam
On 6/18/07, Ryan Gahl [EMAIL PROTECTED] wrote:
my vote is #1
It is up to the devs to a) use the name and id attributes properly, and b)
wrap anything you want any way you want in some custom wrappers file that
you load in after prototype (or whatever library it is you are creating the
wrapper for).
For instance, I have never had this problem, nor do I think I ever will
(if an element i want does not have an id, I can either add one or get the
reference via some other selector on a case by case basis -- basically the
name attribute has no value to me whatsoever)... but if I had this need I'd
know I can just rely on the mutable nature of javascript and redefine the
$() within my app to behave however I want.
If this type of change _does_ make it into prototype, it would be an
addition of unnecessary code, IMHO.
On 6/18/07, Adam McCrea [EMAIL PROTECTED] wrote:
So sorry to beat this dead horse, but I just want to weigh in my
thoughts on this before it gets shot down. I agree that $ should only be a
light wrapper around getElementById, but unfortunately getElementById is
broken across browsers. I'm surprised to hear that you think the fix is
heavy. In my eyes it is a lightweight fix to save some major headaches for
those who don't have control over the HTML source.
My vote is for #2!
- Adam
On 6/18/07, Andrew Dupont [EMAIL PROTECTED] wrote:
On Jun 18, 2:01 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
There are only 3 possible options we're facing:
1. Don't change the $ function, leave everything as-is;
2. Fix the issue in $ by using $$('*[id=foo]');
3. Don't fix the issue, throw error instead.
My vote is for #1. The $ function is intended to be a light wrapper
around document.getElementById . The impulse is noble to want to
correct IE's incorrect behavior (and Opera's emulation thereof), but I
think it's just a little too heavy.
Cheers,
Andrew
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
Vote for #1 I think we as developers should think about the performance and code, and we should be aware of this traps . But to make fix which will be helpful for unaware people and lower the quality, I don't think It is a good idea. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
I think the most important thing is what is the goal of the $ function 1. if the goal is to create a shotpath function to the getElementById, so no changes will be done. 2.If the goal is let the people get the same result on cross browsers, and the $ function must add some checks and return the right element. 3.If the $ function have the responsibility of teaching people how to write good html code, it should just throw out a error message something like Maybe you are just using IE,and the IE is just misbehaving input's name with its id attribute, we suggest you check your html code, make all elements have the same value name and id attri so that is it. What is the $ function's goal judge how to fix it. On Jun 19, 4:36 am, Радослав Станков [EMAIL PROTECTED] wrote: Vote for #1 I think we as developers should think about the performance and code, and we should be aware of this traps . But to make fix which will be helpful for unaware people and lower the quality, I don't think It is a good idea. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
I think it's time to let it drop. You've had several of the core developers--the guys with commit access to the repository--say no. (Given that I'm not a core dev, I don't get much of a vote here, but FWIW I agree: leave $() alone. IE's practice is both misguided and easy to work around.) TAG On Jun 18, 2007, at 7:52 PM, [EMAIL PROTECTED] wrote: I think the most important thing is what is the goal of the $ function 1. if the goal is to create a shotpath function to the getElementById, so no changes will be done. 2.If the goal is let the people get the same result on cross browsers, and the $ function must add some checks and return the right element. 3.If the $ function have the responsibility of teaching people how to write good html code, it should just throw out a error message something like Maybe you are just using IE,and the IE is just misbehaving input's name with its id attribute, we suggest you check your html code, make all elements have the same value name and id attri so that is it. What is the $ function's goal judge how to fix it. On Jun 19, 4:36 am, Радослав Станков [EMAIL PROTECTED] wrote: Vote for #1 I think we as developers should think about the performance and code, and we should be aware of this traps . But to make fix which will be helpful for unaware people and lower the quality, I don't think It is a good idea. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
I agree with jdalton - performance hit.
I agree also that you shouldn't use the same values for name's and
id's.
$() is made for one purpose - to find elements with given id. It
should be VERY fast in every case as it's a base function of
Prototype.
IMO, if found' element's id isn't the same as given, maybe function
should even return null:
[...]
if (typeof element == 'string')
{
var id=element;
element = document.getElementById(element);
// not found
if (element === null || !element.id || element.id!=id) {
return null;
}
}
return Element.extend(element);
[...]
On Jun 17, 11:36 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Wait for your solution, however this performance hit only occur in the
ie and opera and you select the input without an id attribute, maybe
1%'s probability. Will $$(*).detect take a very long time? long than
2 seconds? Is that posibble? Thanks
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
element = $$('*[id=' + id + ']').first(); should be the same with
my element=$$(*).detect(function(node){return node.id==id}) is
there some performance difference between these two code? Thanks
On Jun 17, 9:14 pm, Adam McCrea [EMAIL PROTECTED] wrote:
While I agree that it is bad practice to use names and id's which conflict,
unfortunately we're not always scripting markup that we have control over.
I do think this should be handled in prototype, and the ticket is here:
http://dev.rubyonrails.org/ticket/6328
I recently reopened this ticket since it had been closed as a browser bug.
Prototype smooths over so many browser inconsistencies that I don't quite
understand that rationale. Hopefully it will be reconsidered since I added
a patch with a test. The performance hit should only occur in an edge case
in IE and Opera, so I don't see that as an issue. Even then, dollar-dollar
is pretty fast these days, so I doubt it would be noticeable.
If you have some suggestions regarding the patch, please add your comments
to the ticket.
- Adam
On 6/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I do not think so, what about this case:
script src=prototype.js/script
input type=text value=ie bug name=test /
input type=text value=this value should be returned id=test /
script
alert($(test).value)
/script
If use your $ in ie and opera it will return null, but it should
return the element which has the id test element, so I use $$ and
detect the first matched element. My purpose is let the $ function has
the same result on all the browsers. No matter ie opera or firefox or
safari
On Jun 17, 8:00 pm, DK [EMAIL PROTECTED] wrote:
I agree with jdalton - performance hit.
I agree also that you shouldn't use the same values for name's and
id's.
$() is made for one purpose - to find elements with given id. It
should be VERY fast in every case as it's a base function of
Prototype.
IMO, if found' element's id isn't the same as given, maybe function
should even return null:
[...]
if (typeof element == 'string')
{
var id=element;
element = document.getElementById(element);
// not found
if (element === null || !element.id || element.id!=id) {
return null;
}
}
return Element.extend(element);
[...]
On Jun 17, 11:36 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Wait for your solution, however this performance hit only occur in the
ie and opera and you select the input without an id attribute, maybe
1%'s probability. Will $$(*).detect take a very long time? long than
2 seconds? Is that posibble? Thanks- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
I support the reopening of this ticket. It is truly an edge case which, IMO,
should be handled. The proposed solution is quite nice, also. The only
solution that could be faster than this is to temporary delete the name of
the found element and repeat the $() call, after which the name would be
restored. Unfortunately it isn't possible.
On 6/17/07, Adam McCrea [EMAIL PROTECTED] wrote:
While I agree that it is bad practice to use names and id's which
conflict, unfortunately we're not always scripting markup that we have
control over. I do think this should be handled in prototype, and the
ticket is here:
http://dev.rubyonrails.org/ticket/6328
I recently reopened this ticket since it had been closed as a browser
bug. Prototype smooths over so many browser inconsistencies that I don't
quite understand that rationale. Hopefully it will be reconsidered since I
added a patch with a test. The performance hit should only occur in an edge
case in IE and Opera, so I don't see that as an issue. Even then,
dollar-dollar is pretty fast these days, so I doubt it would be noticeable.
If you have some suggestions regarding the patch, please add your comments
to the ticket.
- Adam
On 6/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I do not think so, what about this case:
script src=prototype.js/script
input type=text value=ie bug name=test /
input type=text value=this value should be returned id=test /
script
alert($(test).value)
/script
If use your $ in ie and opera it will return null, but it should
return the element which has the id test element, so I use $$ and
detect the first matched element. My purpose is let the $ function has
the same result on all the browsers. No matter ie opera or firefox or
safari
On Jun 17, 8:00 pm, DK [EMAIL PROTECTED] wrote:
I agree with jdalton - performance hit.
I agree also that you shouldn't use the same values for name's and
id's.
$() is made for one purpose - to find elements with given id. It
should be VERY fast in every case as it's a base function of
Prototype.
IMO, if found' element's id isn't the same as given, maybe function
should even return null:
[...]
if (typeof element == 'string')
{
var id=element;
element = document.getElementById(element);
// not found
if (element === null || !element.id || element.id!=id) {
return null;
}
}
return Element.extend(element);
[...]
On Jun 17, 11:36 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Wait for your solution, however this performance hit only occur in
the
ie and opera and you select the input without an id attribute, maybe
1%'s probability. Will $$(*).detect take a very long time? long
than
2 seconds? Is that posibble? Thanks- Hide quoted text -
- Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On 6/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
is there some performance difference between these two code? Thanks
Using the CSS selector instead of Enumerable enables the use of XPath. But
since IE doesn't support XPath and the hack above is for IE and Opera, I'd
dare to say that there is no much difference in execution time. One more
thing:
$$('*[id=' + id + ']')
Am I right when saying that this will fail if the ID was dynamically set (in
other words, it was not an attribute in HTML source)?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
What about this code:
if(!element.id || element.id!=id)
{
var tmp=[];
var t=document.getElementById(id);
while(t!=null t.id!=id)
{
tmp.push([t,t.name]);
t.name+=_tmp_;
t=document.getElementById(id);
}
element=t;
tmp.each(function(node){
node[0].name=node[1];
});
}
However the ie protect its input element and do not let setAttribute
change its name attribute, only way to change it is to change
outerHTML which is very ugly, so I believe $$(*).detect is the best
way.
On Jun 17, 9:34 pm, Mislav Marohnić [EMAIL PROTECTED]
wrote:
On 6/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
is there some performance difference between these two code? Thanks
Using the CSS selector instead of Enumerable enables the use of XPath. But
since IE doesn't support XPath and the hack above is for IE and Opera, I'd
dare to say that there is no much difference in execution time. One more
thing:
$$('*[id=' + id + ']')
Am I right when saying that this will fail if the ID was dynamically set (in
other words, it was not an attribute in HTML source)?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
I rewrite it like this, I know this is very ugly someone can improve
it?
if(!element.id || element.id!=id)
{
var tmp=[];var y=100;
var t=document.getElementById(id);
while(t!=null t.id!=id)
{
var e=t.outerHTML;
y++;
t.outerHTML=hr id='+y+';
tmp.push([document.getElementById(y),e]);
t=document.getElementById(id);
}
element=t;
tmp.each(function(node){
node[0].outerHTML=node[1];
});
}
However, it works, with the good performance which I believe. Thanks
for reply
On Jun 17, 11:11 pm, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
What about this code:
if(!element.id || element.id!=id)
{
var tmp=[];
var t=document.getElementById(id);
while(t!=null t.id!=id)
{
tmp.push([t,t.name]);
t.name+=_tmp_;
t=document.getElementById(id);
}
element=t;
tmp.each(function(node){
node[0].name=node[1];
});
}
However the ie protect its input element and do not let setAttribute
change its name attribute, only way to change it is to change
outerHTML which is very ugly, so I believe $$(*).detect is the best
way.
On Jun 17, 9:34 pm, Mislav Marohnić [EMAIL PROTECTED]
wrote:
On 6/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
is there some performance difference between these two code? Thanks
Using the CSS selector instead of Enumerable enables the use of XPath. But
since IE doesn't support XPath and the hack above is for IE and Opera, I'd
dare to say that there is no much difference in execution time. One more
thing:
$$('*[id=' + id + ']')
Am I right when saying that this will fail if the ID was dynamically set (in
other words, it was not an attribute in HTML source)?- Hide quoted text -
- Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On Jun 17, 8:34 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
Am I right when saying that this will fail if the ID was dynamically set (in
other words, it was not an attribute in HTML source)?
Adam's test is correct -- even dynamically-set ID attributes will
still be picked up by readAttribute in IE.
As for the difference between $('*').detect and $('*[id=foo]'): the
second is much faster in IE. The first must past each element on the
page through Element.extend. The second will extend only the matched
element.
I suggest using Element.down, since it always returns one node:
return $(document.body).down('*[id=foo]');
Cheers,
Andrew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
On 6/17/07, Andrew Dupont [EMAIL PROTECTED] wrote:
return $(document.body).down('*[id=foo]');
Nice. But there is an alternative that Tobie suggested: not fixing the
issue.
if (!element.id || element.id != id) throw Some helpful error message
The error would help people learn about this issue and change their sources
to avoid it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
Oh, if only we all had the luxury to change our sources. ;-)
On 6/17/07, Mislav Marohnić [EMAIL PROTECTED] wrote:
On 6/17/07, Andrew Dupont [EMAIL PROTECTED] wrote:
return $(document.body).down('*[id=foo]');
Nice. But there is an alternative that Tobie suggested: not fixing the
issue.
if (!element.id || element.id != id) throw Some helpful error message
The error would help people learn about this issue and change their
sources to avoid it.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $ function
I really like the throw error solution, that is great, I want to
modify this function because I face even a getElementById bug in the
firefox2.0,look at the code:
script src=prototype.js/script
input type=text value=this should be returned name=test
id=www /
input type=text value=this should not be returned ff2.0 bug not
appeared in ff3.0 a5
name=test id=www /
script
alert($(www).value)
window.setTimeout(function(){alert($(www).value)},1000)
/script
The code alert($(www).value) in the loading procession has changed
the ff2.0's getElementById's behaveor, and with ff3.0 alpha5 this bug
won't appeared, so maybe when you face the getELementById's
misbehaving the best solution is to use $$(*[id=...]), or just throw
a error message and change your html code. For my code:
if(!element.id || element.id!=id)
{
var tmp=[];var y=100;
var t=document.getElementById(id);
while(t!=null t.id!=id)
{
var e=t.outerHTML;
y++;
t.outerHTML=hr id='+y+';
tmp.push([document.getElementById(y),e]);
t=document.getElementById(id);
}
element=t;
tmp.each(function(node){
node[0].outerHTML=node[1];
});
}
I have some questions,
1.In ie the only way to change a input element's attribute name is
to change outerHTML?
2.when I change the one reference element's outerHTML, that reference
becomes invalid, I need to get it again, that is why I add var y and y+
+.
3.Is there a regular expression to get out the name attribute from
these two strings 'input type=button value=aaa lll name=lll /'
and'input type=button value=aaa lll name=lll l /' one name with
one without, and the method to modify it. Thanks
For the performacnce I think if you just use getELementById and change
the bug input's name it would be the fastest, even fast than $$
(*[id='']).
On Jun 18, 4:31 am, Adam McCrea [EMAIL PROTECTED] wrote:
Oh, if only we all had the luxury to change our sources. ;-)
On 6/17/07, Mislav Marohnić [EMAIL PROTECTED] wrote:
On 6/17/07, Andrew Dupont [EMAIL PROTECTED] wrote:
return $(document.body).down('*[id=foo]');
Nice. But there is an alternative that Tobie suggested: not fixing the
issue.
if (!element.id || element.id != id) throw Some helpful error message
The error would help people learn about this issue and change their
sources to avoid it.- Hide quoted text -
- Show quoted text -
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
