[Proto-Scripty] Re: Generating invalid HTML for purpose of custom attributes
On Mar 27, 11:43 am, Walter Lee Davis wa...@wdstudio.com wrote:
On Mar 26, 2011, at 9:37 PM, kstubs wrote:
Is it bad, or does it make parsing objects unstable if you append
custom attributes to an HTML tag? Lets say I want to keep track of
a number, maybe a customers ID, so I do something like:
var div = new Element('div', {'customerID':1234});
The issues are inadvertent overwriting of HTML attributes (so you
can't just use any attribute name, you have to be careful) and IE's
mishandling of DOM element attributes and properties.
To get consistency across browsers, you have to read the attributes
using getAttribute and set them (using code) with setAttribute.
Because IE munges attributes and properties, you should only ever use
DOM properties for HTML atributes.
So you need to be careful to distinguish between the two and only use
the appropriate method, which is why it is usually suggested to not
use custom attributes and to use a data object instead, that way you
only ever use one method that is consistent for all browsers.
which should result in:
div customerID=1234/div
Should being the operative word. Note that in IE, the div DOM
element will have a property of customerID, but it will not in
Firefox. That sort of inconsistency is why you should avoid custom
attributes and properties.
Perhaps that issue is fixed in IE 9, but it will be a very long time
before you can ignore all other versions of IE on the web.
HTML5 lets you do this, and pretty much anything else you like, by
adding a data- prefix to the attribute name. Have at it.
HTML5 is not a standard, nor is it widely supported yet.
--
Rob
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Sort Children of a DIV without using Element#remove
On Feb 24, 2:21 am, Walter Lee Davis wa...@wdstudio.com wrote:
I believe this is a requirement -- that I not use remove -- because
the elements I'm trying to move around all have form element observers
attached directly to their children, and I am pretty sure this will
mess me up. Please let me know if that's not true and I don't need to
worry.
You don't have to remove elements to move them. Just append them to
their new parent, that's it:
$('foo').appendChild($('bar'));
or in plain terms:
document.getElementById('foo').appendChild(document.getElementById('bar'));
URL: http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-184E7107
--
Rob
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Next dumb question
On Feb 18, 10:28 am, Jeffrey Lee jlee...@gmail.com wrote: So why is it that when Javascript is updating the document, does the source not show the change? Does show-source merely reflect that which was loaded, but not the actual current document? Why is that? View source shows the original HTML used to create a document, subsequent changes to the document do not modify that. It's just how browsrs work, they could show an HTML representation of the current document (the innerHTML property of the HTML element goes pretty close) if they wished. Since there are no standards for converting DOM to HTML, it is almost certain that the innerHTML for a non-trivial document will be different in different browsers. However, you should be able to load the HTML into any browser and see the same document (more or less, there may be some small differences such as default attribute values or style properties). -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: local variables for for() array iteration
On Jan 20, 4:50 pm, Ran Berenfeld berenfeld...@gmail.com wrote: Thank you for the advise. one more / last question to clarify. In one of the articles about javascript scopes I read that using var inside a class constructor actually creates a private member of the class. is it true ? No. There are no classes in ECMAScript. Functions can be called using the new keyword to use them as constructors. Various patterns can be used in ECMAScript to emulate features of classic object inheritance. The var keyword is used to keep the scope of a variable to the execution context that it is declared within (ECMAScript only has function level scope). It has a role in emulating private members but does not do so by itself. The pattern most commonly used is Richard Cornford's module pattern: http://groups.google.com/group/comp.lang.javascript/msg/ 9f58bd11bd67d937 if this is true, It isn't. then should I avoid using for (var i=0;iarr.length;i++) like statements inside a class constructor ? A consequence being that every variable inside your constructor will become a global variable when the statement assigning to them is executed (which will be after the constructor is called). because then i would become a class member, and then using var i inside class function is not safe. am I right ? No. -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: local variables for for() array iteration
On Jan 19, 11:31 pm, Ran Berenfeld berenfeld...@gmail.com wrote:
Hello all
sorry for this stupid question, but all these talks about the *this
pointer and the variable
scope in js got me confused.
A function's this keyword has nothing to do with scope.
support I have 2 functions, one calling the other inside array iteration.
can they both
use the same local variable for array index ?
Yes, if that's what you want to do. There are a number of ways to do
that.
should I use a var statement ?
Yes, always.
for example :
function B()
By convention, function names starting with a captial letter are
reserved for constructors.
{
for(i=0;iarray_b_length;i++)
You should declare i as a local variable (and I think you have a typo
with array_b_lengh), so:
for (var i=0; i array_b.length; i++)
Variables that aren't declared locally become global variables at the
point in execution when the statement that creates them is executed.
If neither A or B are called, or if the for loops are never executed,
this code will not create a global i variable.
{
...
}
}
function A()
{
for(i=0;iarray_a.length;i++)
{
B()
...
}
}
If this code is run unmodified, when A is called a global variable i
will be created. When A calls B, it will access the same variable.
Since the for loop in B initially assigns 0 to i, its loop will run
OK, but when control returns to A, the value of i will be whatever it
was when B finished with it (in this case, array_b.length). So if
array_a.length = array_b.length+1 then the for loop in A will only
run one loop.
--
Rob
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: finding absolute position of an element / IE7 browser detect?
On Dec 16, 12:36 am, doug douglass_da...@earthlink.net wrote: [...] Any ideas on how I can do this without an IE7 browser detect? Let me know if this works in IE 7: URL: http://www.cinsoft.net/position.html -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Traverse table cells
On Dec 3, 6:16 am, KenB kenber...@gmail.com wrote:
I am new to prototype and need to learn how to traverse an html table
and hide some columns. The only id I have is table id or the class it
is associated with. Can anyone give me an example?
Here is what I am trying to accomplish.
var tbl =
document.getElementById('ctl00_m_g_0ab7c148_0e6c_49e4_bc03_fd1064ca4b41_ctl00_Grid');
if (tbl != null){
var rows = tbl.getElementsByTagName('tr');
table elements have a rows property that is a collection of all the
rows in the table, so no need for getElementsByTagName:
var rows = tbl.rows;
var cols = rows[0].getElementsByTagName('th');
Table rows (TR) have a cells property that is a collection of all the
cells in the row, so if all the cells are TRs then:
var cols = rows[0].cells;
cols[0].style.width = '300px';
cols[1].style.display = 'none';
cols[2].style.display = 'none';
//Now loop through the data rows and hide specific cells
for (var row = 1; row rows.length; row++) {
var cels = rows[row].getElementsByTagName('td');
Same here, no need for getElementsByTagName:
var cels = rows[row].cells;
//alert(cels[1].valueOf);
cels[0].style.width = '300px';
cels[1].style.display = 'none';
cels[2].style.display = 'none';
}
}
Rather than looping over every cell in every row, consider creating
col[1] or colgroup[2] elements whose purpose is to provide a mechnaism
for applying styles to columns instead of each cell individually.
1. URL: http://www.w3.org/TR/html401/struct/tables.html#edef-COL
2. URL: http://www.w3.org/TR/html401/struct/tables.html#edef-COLGROUP
--
Rob
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
Re: Risky delay (was: Re: [Proto-Scripty] Re: Prototype / IE6 issue (bug?))
On Nov 18, 8:06 pm, T.J. Crowder t...@crowdersoftware.com wrote: On Nov 17, 2:07 pm, Phil Petree phil.pet...@gmail.com wrote: Hi, In the case of ie6, with less than 5% of all page views (and rapidly declining), it is now a footnote so why support it at all? The OP's issue has nothing to do with IE 6. The problem is using the wrong event, and probably the wrong control. Using onclick or onchange for a select element is a bad choice regardless of the browser being used. -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Deleting a class object releasing the memory.
On Oct 25, 9:40 pm, Paco Gómez pacogomezgrana...@gmail.com wrote:
Hi TJ,
I'm Jose's partner. The thing I don't understand is why we can recover
memory after creating any other kind of object, but not with DOM
elements.
I don't see the issue in either Firefox or IE 6.
[...]
Do you have any idea why is this happening? I believe that if we at
least can free this nodes in this simple example we could understand
why they are not being freed in our big application.
I'm guessing that it could be related to:
- Something in the initialize of element class (we add the element to
some cache)
- Something in the insert method
- References that are being stored in each element (to its parent and
child nodes) make it impossible for IE to remove them from memory.
Easy to test: use plain DOM instead and see if you get the same
result.
Here's an example:
function doTest(n) {
var elementArray = [];
while (n--) {
elementArray[n] = document.createElement('div').
appendChild(document.createTextNode('test
text'));
}
alert('Before destroy');
elementArray.length = 0;
alert('After destroy');
}
doTest(3000);
Incidentally, the above uses very little memory and is 10 to 40 times
faster, so you can see that Class.create() is a very inefficient
factory.
--
Rob
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Object extend magic
On Sep 1, 6:54 pm, Richard Quadling rquadl...@gmail.com wrote:
On 31 August 2010 20:16, kstubs kst...@gmail.com wrote:
I notice that if I intend to add class to an element that I must use
className and not class for my object. But what if I intend to name
my element? What do you use then? For example:
{ className : foo, innerHTML : bar }
On a newly defined TD yields:
td class=foobar/td
But if the object is:
{ name=somename, className : foo, innerHTML : }
The attribute name *does not appear* on my new TD element.
Originally, I was doing this:
{ class : foo, innerHTML : bar }
And was never getting class on my TD object. So how do you know which
names to use in order to get the result on the element you desire?
[...]
As I understand things, Prototype's Object.extend, when related to
elements, is using the DOM names and not the HTML names.
Object.extend simply copies properties from one object to another,
that's it. So if you use it to add properties to DOM elements, use DOM
property names, not HTML attribute names.
They are different. You have to learn them, sorry.
name is an attribute on form elements (input, select, textarea,
buttons, etc. - is there an etc. ? ).
Yes, such as applet, frame, iframe, a and so on. Specifications are
handy documents.
URL: http://www.w3.org/TR/html401/index/attributes.html
There are many online references. I like the SitePoint
oneshttp://reference.sitepoint.com/css,http://reference.sitepoint.com/html,http://reference.sitepoint.com/javascript.
The definitive reference is the appropriate W3C document.
--
Rob
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Prevent enter from submitting form
On Aug 31, 10:44 pm, jhaagmans jaap.haagm...@gmail.com wrote: You obviously didn't read the entire post, as the expected behaviour for an enter press is to submit the form that is currently visible and not the one that is hidden. That's what I'm trying to accomplish. I in fact figured out that I should add a return. Thanks anyway. No, you probably shouldn't. Instead use an onsubmit handler on the form so that if the form submits when only an ID has been entered, you can do whatever it is you want to do then and stop the form submitting. When both login and password are entered, allow submit to proceed (if that's what you want to do). That way you aren't messing with the user interface, snifing keys, whatever. -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Touch screen / mouse gesturing.
On Jul 29, 9:41 pm, Richard Quadling rquadl...@gmail.com wrote: Hi. I'm developing a tiny little web page app which allows vehicle inspectors to see the work last carried out on a vehicle. [...] For the touch screen systems, I'd like to be able to implement some touch screen support. [...] Any ideas/suggestions/etc. would be gratefully received. Much better to ask this question here: URL: http://groups.google.com/group/iphonewebdev?lnk= -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Problem with prototype and arrays.
On Aug 2, 3:43 pm, T.J. Crowder t...@crowdersoftware.com wrote: Hi, I found that array looping method online, I guess I will remove that page from my bookmarks. Yes, it's an extremely common misconception. What, that for..in iterates over an object's properties? It's per ECMA-262. There are strategies for dealing with properties on an array's internal prototype chain so that for..in works just fine, even when it's built-in prototype has been modified. -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: Problem with prototype and arrays.
On Aug 3, 2:19 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi, Yes, it's an extremely common misconception. What, that for..in iterates over an object's properties? No, that it loops over array indexes. I'm missing something here. Array indexes are properties, which is why they are included in for..in iteration. The OPs problem was how to deal with properties from the [[prototype]] chain, not that array properties were included in for..in. There are two issues to deal with when using for..in with a javascript array: 1. properties may have been added to Array.prototype, and 2. object properties are not guaranteed to be returned in any particular order Both the above are common to any use of for..in. Item 1 is easily dealt with. If order matters, a for, while or do loop can be used. Otherwise, there is no issue. -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: enumerate hash
On Apr 10, 8:36 pm, chrysanthe m chrysant...@gmail.com wrote:
Hi, again
Sorry for being obtuse. But can someone help me and even understand how to
write a function and call it on a hash that will take a value, compare it
against each of the keys in the hash, on match delete the key/value, and
return the hash. tia.
Consider using a plain object:
var o = {foo:'foo', bar:'bar'};
function removeProperty(obj, prop) {
if (prop in obj) {
delete obj[prop];
} else {
return prop + ' not in object';
}
}
alert(o.foo);
removeProperty(o, 'foo');
alert(o.foo);
No need to return the object, it is modified in place.
--
Rob
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: How would you check if a function is defined using prototype
On Feb 5, 5:31 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Hi,
If the function is expected as a property of some object (including
`window`), then I'd probably do this:
if (typeof obj.functionName == 'function')
So for instance:
if (typeof window.globalEval == 'function')
If you need to check whether a function is defined in the current
scope and not on a property (so, on the current variable object or one
of the others in the scope chain), I'd probably be a bit more
defensive:
var defined = false;
try {
defined = typeof functionName == 'function';
}
catch (e) {
}
Prototype also adds a function to `Object` that does the check:
if (Object.isFunction(window.globalEval))
...which is just a shorthand way of doing the typeof.
HTH,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / comwww.crowdersoftware.com
On Feb 4, 3:14 pm, RK rajkishore.puj...@gmail.com wrote:
How would you check if a function is defined using prototype
Thanks,
RK.
--
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: instantiate class problem on IE
On Dec 23, 4:17 am, david david.brill...@gmail.com wrote: Hi Loris, I think that your trouble is normal, because IE don't allow to instantiate method on native object. You might need to re-think that statement. From ECMA-262: Native Object A native object is any object supplied by an ECMAScript implementation independent of the host environment. Standard native objects are defined in this specification. Some native objects are built-in;others may be constructed during the course of execution of an ECMAScript program. Can you imagine the ramifications of IE not allowing native objects to have methods? :-) Perhaps you meant host object. But if that were true, most of Prototype.js would not work at all in IE. Generally it's not a good idea to extend native objects because your not sure that another JS will not use the same method name !! Perhaps you did mean host object. Yes, it's a bad idea to add *non- standard* properties to host objects. How do you reconcile that notion with the use of Prototype.js's $() function? -- Rob -- You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptacul...@googlegroups.com. To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
[Proto-Scripty] Re: IE Add Observers in Reverse Order?
On Sep 29, 8:45 am, KammylandSoftware kammyl...@gmail.com wrote: When ever you add oberservers to the same event such as Event.oberve(myElement, mousedown, someMethod_1()); Event.oberve(myElement, mousedown, someMethod_2()); does IE execute them in REVERSE order upon fire? They get executed by order of chronological assignment in FF. IE is a bloody-idiot. IE doesn't implement the W3C Event model and even if it did, it wouldn't necessarily help. The DOM 2 Events specificaton specifically says event listeners aren't guaranteed to execute in any particular order: Although all EventListeners on the EventTarget are guaranteed to be triggered by any event which is received by that EventTarget, no specification is made as to the order in which they will receive the event with regards to the other EventListeners on the EventTarget. URL: http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-basic However, the DOM 3 Events spec says order must be preserved. You may find this thread interesting: URL: http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/e7145c0d89caf0a1/e1eec62b11b29315?q=listener+order+group:comp.lang.javascript#e1eec62b11b29315 If you want an event registration system that will ensure listeners are called in the order they are added, you could use something like the code suggested here: URL; http://groups.google.com/group/comp.lang.javascript/msg/a318f930c21433d6 Read the rest of the thread, it is interesting. You could also read this one: URL: http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/e7145c0d89caf0a1/7dd914a8dfef0241#7dd914a8dfef0241 Don't use the code suggested by the OP, read the responses by Richard Cornford to get valuable insights into how to implement what you are after. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: weird behavior w/ prototype firefox
On Sep 29, 2:54 am, mhgrove mhgr...@gmail.com wrote:
I want to have the button call a function which first schedules a call
to show the busy spinner after say like 5 seconds. This way if the
call to the server is fast, there's no blip on screen of the spinner
just before the page redirects. The function should also defer a call
to a function which will actually make the call to the server. And
when the call is complete, the callback which redirects the page to
the result should be invoked.
Browsers already have methods that tell the user they are busy, much
better to teach users to recognise that general behaviour than deal
with different behaviours at each site.
[...]
In any case, putting a return false; at the end of the method called
by the click handler on the form submit button, and then returning
that value to the form seems to cancel the submission and my code
works as expected.
I'm not sure what you mean by the above, but submit listeners should
be attached to the form, not the submit button. The inline version is
something like:
form onsubmit=return doStuff(this); ...
If doStuff returns false, submission is cancelled. If it returns any
other value (even undefined or nul) the form will submit. The listener
can of course be added dynamically using something like:
form.onsubmit = function() {
var form = this;
// do stuff with form, decide whether to cancel submit or not
if (cancelSubmit) {
return false;
} else {
return whatever;
}
}
The key is to use the form's submit event, not the button's click
event.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: onChange event when div content changed
On Sep 3, 12:07 am, Hipnotik pork...@gmail.com wrote:
Hi
How to call some action if content of the div element has changed?
I'm talking about something like this:
$(my-div).observe(change, function(e) {
alert(hello);
});
Expecting behavior:
I have this
div id=my-divsome text/div
now I'm changing some text to some other text and alert(hello)
should be fired.
There is no change event specified for div elements, what you are
looking for is provided by DOM mutation events:
URL: http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MutationEvent
OK in Firefox, Opera, Safari and a few others, but not IE.
Some help here:
URL: http://www.howtocreate.co.uk/tutorials/javascript/domevents
The best cross-browser strategy is to get the function that modifies
the DOM to call the function you'd like to add as a DOMSubtreeModified
listener.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: array.indexOf fails sometimes in IE8
On Sep 3, 1:56 am, enigment enigm...@gmail.com wrote:
Hmmm, even outside the indexOf() question, this is a bit creepy to me.
I hadn't previously tested, but these are all true, at least in
Firefox 3.5 and IE8:
[...]
new String(mpg) !== new String(mpg)
new String(mpg) != new String(mpg)
Because that is comparing two different objects, which can never be
equal.
[...]
new Number(1) != new Number(1)
Same here.
[] != []
new Array() != new Array()
new Array() != []
new Object() != {}
And again. Object literal syntax is identical to using the new
operator, only faster.
Is it an identity test -- is it the same actual object? -- maybe
coupled with the way various types of data are stored internally? It
looks like once the string mpg has been created, another literal
msg is the same, but a new String object containing the same literal
is not. The analogous tests with Number, Array, and Object values
indicate somewhat different behavior, but since it's consistent across
IE and Firefox, it seems inherent in the language.
Can anyone explain, not *how* this actually works, but the logic
behind it?
That is how it is specified by the ECMA-262 specification, every
object has a unique identity.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Automatically Converting HTML to DOM (e.g. new Element ...)
On Aug 19, 5:30 am, drewB dbats...@gmail.com wrote: As I see it the advantages of doing it client-side are: - The server can handle more users because less work is done there Unlikely. There is very little difference in computation effort between generating JSON, XML, HTML or delimited text at the server. There is a much greater computational effort on the client to convert JSON, XML or delmiited data to HTML DOM elements. If the data is going to be presented as HTML, then create HTML at the server and send that. Use the browsers highly optimised ability to convert HTML to DOM (and the server's to convert data to HTML) and you're done. - Cleaner delineation for presentation layer. If I want to change the way things look, there are fewer places I need to go. So why put it in two places? Why turn data into say JSON just so you can later turn it into HTML? Just create HTML in the first place using a template on the server. - Possibly better user experience because there is no delay between adding an item and it showing on on there screen. The greatest time taken is in getting the data from the server, which will be (pretty much) the same regardless of how the data is formatted. The benefit of AJAX is they don't see the whole page re- load. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: I can't work with xml files in prototype
On Jun 23, 5:29 am, dy3g0s dy3...@gmail.com wrote:
Hi,
I actually work with Slideshare API, php and prototype. I make a cURL
call in php to consume a certain Slideshare API method, the php script
return an xml result with the header header('Content-type: text/
xml'); I obtain a xml response, the current API does not returns json
or other format.
My ajax code is:
new Ajax.Request('slideshare.php',
{ method: 'get', encoding: 'UTF-8',
parameters: {
query: myQuery,
type: functionType
},
onComplete: function(request){
var response = request.responseXML;
widget.setEstadosService(response);
var slidesLength =
response.getElementsByTagName
(Slideshow).length;
if (slidesLength == 0){
$('estadoSlideshare_'+id).update('It is not exist results');
}else{
widget.setLimiteXmlOrJson(slidesLength);
loadSlides(id);
}
}
}
In the end, the problem is not the response, neither php script or
structure of ajax call. The problem is when I try to work and accede
to XML file, I received the response with request.responseXML and
when I try e.g.:
var response = request.responseXML;
//this no work :(
alert(response.getElementsByTagName('Slideshow').childNodes
[0].nodeValue);
getElementsByTagName returns a collection that doesn't have a
childNodes property. You want to do something like:
...getElementsByTagName('Slideshow')[0].childNodes...
I have found it best to use getElementsByTagNameNS('*','Slideshow')
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Bizzarre goings on
On Jun 10, 7:09 am, david david.brill...@gmail.com wrote:
Hi Alex,
If the code WAS working, the error could be on the received JSON ?
One though, IE don't like misplaced comma on JSON. For exemple, last
element of an array that is followed by a comma don't work on IE.
What do don't like and don't work mean? IE mishandles elisions in
arrays, e.g.:
alert( [,,].length );
should show 2, but IE shows 3. But that just creates an extra empty
member of the array and doesn't not cause a runtime error.
IE will error if an extra comma is included in an object literal, e.g.
var obj = {name:'fred',};
will be fine in Firefox (and others) but error in IE (per the
ECMAScript (ES) spec). As far as I know, ES 5 will allow trailing
commas in object literals, so in perhaps 10 years time they can be
used with reasonable safety. In the meantime, write for ES 3.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Last table row
On Jun 5, 8:15 pm, Jeztah webmas...@thecarmarketplace.com wrote:
Morning...
Very silly and easy question but my brain isn't working today
How can i get the last row of a table (table id=foo) ...
Tables have a rows collection that includes all rows in the table.
Try:
var rows = document.getElementById(tableID).rows;
var lastRow = rows[rows.length -1];
Or if you want something much faster in IE:
var rows = document.getElementById(tableID).getElementsByTagName
('tr');
var lastRow = rows[rows.length -1];
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Cant get focus to work with change event when tabbing out of input
On Jun 2, 5:32 am, molo maurice_lowent...@ssga.com wrote:
I could use some help. I've been looking at this all day and cannot
come up with a solution
I am using the same routine on these 5 input fields. If I type in a
character on one of these fields and press enter, it works as expected
I get an error alert and focus on the field. However if I type in a
character and tab out of the field I get an alert error but the focus
is on the next field. I guess the blur event takes it to the next
field.
Can someone tell me what I need to do to get the focus working
correctly here
Here is my event related code
Event.observe('oldidratio','change',validateNumberChange);
Event.observe('cashpershare','change',validateNumberChange);
Event.observe('proration','change',validateNumberChange);
Event.observe('newid1ratioentry','change',validateNumberChange);
Event.observe('newid1fmv','change',validateNumberChange);
Here is the function
function validateNumberChange(){
var numericField = $F(this);
It's an input field and you already have a reference to it, there is
no need to use the $ function:
var inputValue = this.value;
if(IsNumber(numericField,true)){
return true;
}
else {
If the condition is true, it has already returned so there is no need
for an else branch. The statements for the false condition just follow
the if block.
$(this).focus();
The focus method belongs to the input, there is no need to use the $
function:
this.focus();
alert(invalid number);
That is a really good way to annoy your users (see TJ's post). To get
it to work, use setTimeout to call the focus method:
var el = this;
window.setTimeout(function(){el.focus()}, 0);
But I don't recommend doing that.
return false;
Why?
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
On May 21, 11:11 pm, T.J. Crowder t...@crowdersoftware.com wrote:
Hi Joe,
T.J.'s factory suggestion...
FWIW, I think it was Doug's suggestion, I just updated it a bit.
function DateFactory(){
var fName, that = new Date();
for (fName in SpecialDateProps)
that[fName] = SpecialDateProps[fName](); // Note calling the
fName's function.
return that;
}
I'm not immediately seeing how that works. There are two problems I
see:
1. When you're calling the functions, they don't have any context to
work with. How do they know what date they're meant to be working on?
Which means creating setters and getters so that when the date is
modified, properties can be adjusted accordingly. However, that means
setters may be doing more work than they need to - why work out if a
date is easter or not if the code using it date doesn't care?
2. Date instances are mutable, but you're setting a flag on the date
just once at creation time. So even if the flag is correct at the
time the instance is created, it can be made incorrect by using any of
the mutator functions (setMonth, etc.).
Either the setter needs to update such propeties, or isEaster needs to
be a method, not a boolean. It all boils down to understanding the
requirements first, then designing the software to suit.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: How can I get a list of events fired by an object?
On May 22, 12:11 am, Walter Lee Davis wa...@wdstudio.com wrote:
I'd like to see what events are there for the observing, particularly
on an iframe.
The iframe element doesn't support any events[1]. The document that
it contains may support various events (such as load, click, etc.).
Is there a general-purpose way (or even some tab of
Firebug I haven't seen before) that I can see what events are being
fired? Some sort of Event.observe('foo','*'... kind of thing?
Try Firebug's Profile option.
1. URL: http://www.w3.org/TR/html401/present/frames.html#edef-IFRAME
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Adding properties to native objects
On May 19, 9:26 pm, ColinFine colin.f...@pace.com wrote:
This is a case when you really truly want just the facilities that
Javascript provides (prototypes rather than classes), and using
(pretend) classes makes it harder not easier.
Yes, although some may argue that it is better to create a new object
that has the required methods and leverages the methods of Date,
rather than modifying a built-in object prototype, something like:
function SpecialDate(d) {
this.date = new Date(d);
}
SpecialDate.prototype = {
getYear: function() {
return this.date.getFullYear();
},
isEaster: function() {
var easterStart = new Date('2009/04/10 00:00');
var easterEnd = new Date('2009/04/13 23:59:59')
return (this.date = easterStart this.date = easterEnd);
}
}
var d = new SpecialDate('2009/04/12');
alert(d.isEaster());
Of course, the above is only useful for easter 2009 and needs further
development, however it shows the general idea. The work of JR
Stockton might help:
URL: http://www.merlyn.demon.co.uk/js-dobj2.htm
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Changing href in onclick function
On May 15, 6:54 pm, marioosh marioosh@gmail.com wrote: I have a id=ph href=#. I want to do that (sorry for my poor english): When user click ph, i need to set href to some usable address (by sending request Ajax.Request) and fire onclick once again. That seems unnecessarily complex, why not just navigate to the correct URL in the first place? -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: DOM building methods
On May 13, 6:12 pm, keemor kee...@gmail.com wrote:
Hi,
I'd like to present 3 ways of building ul list and compare the speed
of them.
I used firebug's profiler on FF3
html:
body
a href=# id=gogo/a
ul id=list/ul
/body
$('go').observe('click',go);
[...]
Third:
Time to build (513.747ms, 30054 wywołań)
function go(e){
e.stop();
var tpl = new Template ('li class=#{class} id=#{id}#{id}/
li');
var list = new String;
$R(1, 1000).each(function(i){
list += tpl.evaluate({class: 'klasa', id: i});
That line throws a parse error in Safari 4, class is a reserved word
in ECMAScript, use className.
})
$('list').update(list);
}
As you can see third method is 4 times faster than first one.
In first two methods around 50% of time took
extractScripts() stripScripts() which are used in update and
insert
methods.
So if you have more complex RIA with many dynamic elements you can
simply improve it significantly :)
If speed matters, use plain javascript. Marginally more code, but the
result is 3 times faster in Firefox than Third: (94ms vs 34ms in
Firefox 3 on a 1GHz G4) and twice as fast in Safari 4 (39ms vs 19ms).
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Classes vs Objects - Best Practice?
On May 12, 1:20 pm, RobG rg...@iinet.net.au wrote: [...] Javascript can emulate many object models, not just classic OO or class-based iheritance. That should have been: many *inheritance* models -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Extracting methods from codebase
On May 1, 1:42 am, Bertrand bertrand.char...@gmail.com wrote: Well, actually, my managers are pushing for self-contained javascript code (trying to get rid of all the library calls, which isn't necessarily a good idea, but I have to abide). So I ended up using a DOM-compliant version using createElement, createTextNode and appendChild. The DOM Core methods are pretty well supported across browsers, the primary reason innerHTML is used is because it is faster in IE (where DOM methods can be terribly slow) and many authors come to javascript from an HTML background and are more comfortable writing HTML that script. If you are having issues with performance or cross-browser support, post your questions at comp.lang.javascript. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: convert string to a number
On Apr 25, 3:37 pm, Ananth Raghuraman araghuram...@gmail.com wrote: Thanks for pointing me to the native functions! In the meantime I also found 1.8 has the Number object/function. The Number constructor is a built-in ECMAScript function. When called as a function, it does type conversion: var num = '1'; // Convert to number num = Number(num); How it works is covered by Section 15.7.1.1 of the ECMAScript language specification. I just did Number(mynumberstring) to convert mynumberstring to a number. It is faster to use unary +: var num = '1'; // Convert to number num = +num; Also note that any arithmetic operation on a string other than + will always perform type conversion: var a = '5'; alert( a * a); // 25 I guess Number also accepts an object Yes, it's explained in section 9.3 on type conversion. The result of calling Number(object) is, more or less, Number(object.toString()), however read the ECMAScript specification for a full explanation. or another Number as argument.. Yes, but calling Number(number) simply returns the number (Sec. 9.3). -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: convert string to a number
On Apr 25, 2:06 am, Ananth Raghuraman araghuram...@gmail.com wrote: Need prototype function to convert object/string/number to number. Please help. Without a more concise specification for what the object/string/number might be, you will end up with a large function that works for a few scenarios invented by the author and fails for anything else. It doesn't make sense to have a function to convert a number to a number. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Event Observers and Question on Copying Form Values Using Prototype
On Apr 24, 4:05 am, katz bridgeuto...@gmail.com wrote:
Greetings.
I need to learn how to achieve to dynamically copy form field values
using Prototype or possibly Ruby.
I want to achieve something like
this:http://websitebuildersresource.com/2009/02/05/copy-form-input-data-to...
http://websitebuildersresource.com/demos/jquery-copy-form-data/
Sorry for posting a jQuery example.
I'm fairly new to Prototype, Scriptaculous and RJS. My goal is to
achieve similar result using the default libraries of Rails.
Although I am aware of jQuery noConflict() and and all those techniques
to make jquery work well with other libraries, I just don't want to use
it for now.
There aren't too many decent examples on how to copy form values for
prototype.
My question is:
How do you use that $F function and form.serialize to copy form field
values to other fields?
Also event observers seem to fail to work if defined on head tag. Am I
right?
http://www.prototypejs.org/api/event/observe
Examples aren't working for me.
So I already have something like this:
input id=item_weight
type=text value=0 size=10 name=item[weight]/
input id=item__copy_weight
type=text value=0 size=10 name=item[copy_weight]/
input type=button id=button3 value=Same as above /
script type=text/javascript
$('button3').observe('click', function(e) {
var form = Event.findElement(e, 'form');
All form controls have a reference to the form they are in, so:
var form = this.form;
var input = form.down('input[name=item[weight]]');
Since you now have a reference to the form, the controls are easy:
form.elements['item[copy_weight]'].value = form.elements['item
[weight]'].value;
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Observe div content change?
On Apr 22, 9:02 pm, Yozefff yoze...@gmail.com wrote: Is it possible to observe when the content of a DIV is changed? The W3C DOM 2 Events specification has an Interface MutationEvent for that purpose (and others). Support may vary across browsers: URL: http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-MutationEvent -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Namespace Function
On Apr 22, 9:57 am, disccomp discc...@gmail.com wrote:
Here's the working code:http://pastie.org/454045
OK, here it is:
| $N = function(ns){
*Always* declare variables. I can't see why you don't use:
function $N(ns) {
or, because I dislike the use of $ in variable names:
function getNamespace(ns) {
...
}
| /* First split the namespace string separating each level of the
namespace object.*/
| var splitNs = ns.split(.);
Ensure you have a string before trying to call one of its methods,
otherwise you'll get an error:
var splitNs = String(ns).split('.');
| /* Define a string, which will hold the name of the object we are
currently working with. Initialize to the first part.*/
| var builtNs = splitNs[0];
builtNS might be undefined, a moot point since it isn't used.
| var i, base = window;
Do not augment host objects, use the global object. You can get a
reference to the global object using:
var base = (function(){ return this;})();
| for (i = 0; i splitNs.length; i++){
| if (typeof(base[ splitNs[i] ]) == undefined) base[ splitNs
[i] ] = {};
| base = base[ splitNs[i] ];
| }
A couple of points:
1. Store a refernce to splitNs[i] so you don't have to keep getting
it.
2. typeof is not a function so the brackets around the argument
aren't required:
var nsPart;
for (var i=0, len=splitNs.length; ilen; i++){
nsPart = splitNs[i];
if (typeof base[nsPart] == 'undefined') {
base[nsPart] = {};
}
base = base[nsPart];
3. Browsers add host objects as properties of the global object, when
tested with typeof they can return any value they want, even
undefined when they aren't, so testing explicitly for undefined is
not particularly safe where host objects are concerned (e.g. in IE,
the typeof operator returns unknown for ActiveX objects).
4. At this point, base should be tested to see if it's an object:
if (typeof base[nsPart] == 'object') {
base = base[naPart];
} else {
... what now?
}
We now are in a dilema. Say were were given:
getNamespace('foo.bar.blat')
and we find that foo.bar is not undefined, but not an object either -
what now? What if the parts of the namespace are not valid ECMA
identifiers? Should they be checked? And so on.
| return base; // Return the namespace as an object.
| }
Whether base is an ojbect or not wasn't tested (originally).You don't
know base is an object, all you know is that you think it's not
undefined. It could be anything that reutrns false to the typeof
test, perhaps a number, string or boolean.
Using a namespace is no better than using any particular string of
characters for a variable name, e.g.
var foo = {
bar = function() {...},
...
};
is no safer from collision than:
var foo_bar = function() {...}
Further, you don't know if the object returned from $N is the one you
really want, or if it's some other object created by something you
don't know about. Providing a namespace function infers that it some
safety is provided from collision, it does nothing that:
var foo = foo || {};
doesn't do in a single line, with all the same pitfalls. At least the
above statement has no pretence otherwise and it's a lot less code.
Before creating functions, it is a good idea to specify exactly what
they should do and investigate various options and risks. You may
find from time to time that they offer nothing useful.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Recommended and Disrecommended DOM Methods
On Apr 18, 4:46 am, Doug Reeder reeder...@gmail.com wrote:
Is there a list of which DOM properties and methods are useful when using
Prototype, and which are unnecessary, given the availability of Prototype
methods?
It is not so much what is necessary or not, but what might be an
appropriate situation to use one or the other. For example, the
Prototype.js Form object has a reset method:
var Form = {
reset: function(form) {
$(form).reset();
return form;
},
...
}
Which would be called as:
Form.reset('form_Id_or_name');
It just calls the Form's reset method and returns a reference to the
form. It might be used for cases where calls are chained (which means
the code is marginally shorter but it makes debugging more difficult)
so you might use:
var stuff = Form.reset('someForm').serialize();
if you wanted to serialize a form using its default values. If you
just want to reset the form (which is likely what you want to do in
99.9% of cases), then use:
theForm.reset();
which uses the browser supplied reset method directly.
Similarly with focus(), you'd need to use:
Form.Element.focus(element)
It seems that it would be rarely used in place of just:
element(focus);
which uses the browser's focus method directly. If you pass some
element to the above that doesn't support reset or focus, you may get
an error. e.g. option elements are form controls (and therefore might
be considered safe to use the Form.Element methods) but do not have an
HTML onfocus attribute or DOM focus method, so calling:
Form.Element.focus(optionElement)
may error in conforming browsers, Prototype.js doesn't provide any
protection against that.
There may be reasons to use one or the other that are applicable to
certain situations - which one you chose depends on the circumstance.
What you may discover are the foibles that remain in Prototype.js's
handling of cross-browser issues, since that is the primary motivation
for replacing the browser version of DOM methods.
For example, the value of a select-one select element should be the
value of the selected option. The value of an option element is the
value of the value attribute or, if it is not specified, the value of
the text content. However, IE gets it wrong - if the value isn't
specified, it doesn't return the text value. So given a select
element like:
select name=sel0 id=sel0
option selectedone
optiontwo
optionthree
/select
if you use:
var theValue = $('sel0').getValue();
you will get the correct value in IE, however if you use:
var theValue = $('sel0').value;
IE will return an empty string. Not exactly what you asked (it uses a
Prototype.js method instead of accessing the property directly, rather
than a straight replacement of a DOM method) but I think it
illustrates the point.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Client-side File Processing
On Apr 14, 3:11 pm, Doug Reeder reeder...@gmail.com wrote:
I'd like to allow the user to select a file from his/her filesystem,
and process it locally. Due to heightened security (or at least the
semblance thereof) the value of a file input element is just the name
of the file, not the full path, in many modern browsers, so the file
path can't be turned into a file: URL that can be loaded via AJAX.
Is there a way to access the contents of the file using Prototype?
Nothing to do with AJAX (where AJAX is a pseudonym for
xmlHttpRequest). If it's an XML document, it can be loaded using a
fairly simple script:
function loadXMLFile(fileName) {
var xmlDoc;
// W3C compliant
if (document document.implementation
document.implementation.createDocument ) {
xmlDoc = document.implementation.createDocument(,,null);
} else {
// IE model
try {
xmlDoc = new ActiveXObject('Msxml2.DOMDocument');
} catch( e){}
}
if (xmlDoc) {
xmlDoc.async = false;
try {
var loadOK = xmlDoc.load(fileName);
} catch(e) {}
}
return loadOK? xmlDoc : null;
}
Call using the value of the file input, it returns an XML document or
null if the load failed.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: show hidden div if js is disabled
On Apr 10, 11:09 am, swdean magic...@gmail.com wrote: I am quite new to coding and I am trying to show div in case js is disabled the reason is because I set it to display: none Don't do that, consider the noscript element. URL http://www.w3.org/TR/html4/interact/scripts.html#edef-NOSCRIPT You can also use document.write to add a stylesheet that hides or shows the div if javascript is available. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: examine whether methode is already used
On Apr 2, 5:57 pm, basti bastian.friedr...@am-soft.de wrote:
Good morning,
I wanted to use the method getElementsByClassName by prototype to
retrieve an array of objects. Using my Firefox 3.0.7 on Windows XP
alert told me that the returned value by this method is a Nodelist,
which I couldn't iterate using prototypes each-method for arrays.
You can convert the retuned NodeList to an array using $A(), or if you
want to be a little clever you can test the returned object's
constructor and only convert non-Arrays:
var nodes = document.getElementsByClassName('foo');
if (nodes.constructor != Array) {
nodes = $A(nodes);
}
The host getElementsByClassName is likely much faster in general than
a native javascript replacement.
HTML 5 includes a selector API that will provide host methods for a
much greater range of selectors, they should offer significant speed
enhancements over current native selector APIs.
URL: http://www.w3.org/TR/selectors-api/
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Select form elements by name
On Apr 2, 4:43 am, Diodeus diod...@gmail.com wrote:
What's the Prototype equivalent of this jQuery code?
I would like to select all of the radio button with a certain name.
$('#billship input:radio[name=shipType]');
All of the following will return a live NodeList:
$('billship').shipType;
or
$('billship').Elements['shipType'];
or
$('billship').Elements.shipType;
If you want a static array:
$A($('billship').shipType);
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: observe any change in the window
On Mar 30, 9:36 pm, Walter Lee Davis wa...@wdstudio.com wrote: Take a look at Form.Observer I think you meant to reply to the OP. -- it's ideal for this sort of thing. I don't think it is. It watches the form in a tight loop (at your specified interval) and if there are any changes to the form from the last time, it fires a function. That is an inelligant and inefficient way to check if the form has changed, particularly for large forms. The check only needs to be made once, immediately before the iframe is unloaded. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: event.element vs. $('element_id')
On Mar 27, 9:35 am, Hector Virgen djvir...@gmail.com wrote:
[...]
As for speed, I would imagine that event.element() is faster than
$('object_id') because even.element() is just accessing a property, instead
of searching the dom for a node. But I could be wrong on this :)
Logic would say that you are. $() essentially a wrapper for
getElementById, and since that function is fundamental to the DOM
Core, it is likely highly optimised in browsers. Rather than having
to search the DOM I expect the browser creates an indexed list of
all elements with an ID and that getElementById will perform an
indexed lookup. The $ function may be slower in browsers like IE
where all of Prototpye.js's element methods must be added to the
element.
event.element is not just accessing a property. It is a function
call, and as a consequence of adding a bunch of methods to the event
object and also attempting to accommodate the differences in the event
models of a few browsers, it does more work that the $ function.
Therefore there is no reason to believe it will be faster than
getElementById.
In any case, it doesn't take much to test:
script type=text/javascript
window.onload = function() {
$('button0').observe('click', function(e){
var el, i, num = 1;
var msg = [];
var start;
start = new Date(), i = num;
while (i--) {el = e.element()}
msg.push('e.element: ' + (new Date() - start));
start = new Date(), i = num;
while (i--) {el = $('button0');}
end = new Date();
msg.push('$(id): ' + (new Date() - start));
start = new Date(), i = num;
while (i--) {el = e.target || e.srcElement;}
end = new Date();
msg.push('e.target or srcElement: ' + (new Date() - start));
alert(msg.join('\n'));
});
}
/script
input type=button id=button0 value=Run test 0
The above indicates that $(id) is twice as fast as event.element() in
IE, and 6 times faster in Firefox. If speed *really* matters, and you
know what you are doing, access the property directly (the third test
above).
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: event.element vs. $('element_id')
On Mar 27, 10:02 pm, Lapis petter.env...@gmail.com wrote:
I do like this sometimes, when the scoping is ok:
var submitter = $('submitter');
if (submitter) {
submitter.observe('click', function (event) {
// use submitter here
});
};
It is great, time-wise.
And exploits IE's memory leak due to the closure with circular
reference. Don't do it.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: HTML Entity Handling with setValue
On Mar 18, 12:00 pm, Tobie Langel tobie.lan...@gmail.com wrote: OK, so to summarize: 1) TextArea have a value property (as per DOM 2 specs), 2) Prototype Element#setValue uses the value property (not the HTML value attribute), 3) Proper, standard compliant way of doing what OP wants: textArea.value = content.unescapeHTML(); unescapeHTML is a Prototype.js function that uses innerHTML, so not strictly standards compliant. If that was the goal, the OP would not be expecting HTML character entities to be parsed when using them as the content of a textarea element whose content is tyep DOMstring. For strict standards compliance, plain text should be used and appended as a DOM text node (e.g. amp; should be in the text as plain ). If the string contains markup and the OP expects it to be parsed, then either a textarea element is the wrong element to use, or the text should be parsed first (as occurs with unescapeHTML and innerHTML) before being used as the content of the textarea. [...] 5) Possible non-standard shortcut suggest by Rob (Note that setting innerHTML on textarea elements is NOT trustable across browsers[1]. I do NOT recommend it): Nor do I in general, but it does the job here. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: HTML Entity Handling with setValue
On Mar 18, 11:26 pm, Walter Lee Davis wa...@wdstudio.com wrote: I'm so confused... About what? -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: HTML Entity Handling with setValue
On Mar 17, 11:02 am, ViniH vinihol...@googlemail.com wrote:
I have a textarea on a page which contains notes as text. Html encoded
entities are encoded correctly for display in order to pass XHTML 1.0
strict validation (which is a company requirement).
I would like to see the reasons why, it doesn't make sense to me:
Sending XHTML as text/html Considered Harmful
URL: http://www.hixie.ch/advocacy/xhtml
\
E.G.
textarea name=listing_summary_header-old_notes
id=listing_summary_header-old_notes readonly=readonly cols=50
rows=5 style=width:320px; background: #EAF5F8; height: 80px; font-
size: 0.7em;
16/3/2009 - Vini Holden - 570 enqs - test
16/3/2009 - Vini Holden - 570 enqs - amp;amp;amp;
/textarea
Every 30 seconds a PeriodicalExecuter fires an Ajax call which checks
for new notes and updates the textarea using setValue if new notes are
found.
As previously discussed here, setAttribute sets the HTML attribute,
which does not update the displayed value in some browsers. For DOM
properties that map to HTML attributes, use the dot property.
Note that for an HTML textarea element, the value is the content of
the element, *it doesn't have a value attribute*.
URL: http://www.w3.org/TR/html4/interact/forms.html#edef-TEXTAREA
Either append the new value as a text node and use ISO 10646 character
numbers, or use innerHTML with character entity names, e.g. to change
the value to Jack Jill use:
var t = $(textarea);
t.innerHTML = 'Jack amp; Jill';
or
t.appendChild(document.createTextNode('Jack \u0026 Jill'));
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: HTML Entity Handling with setValue
On Mar 18, 1:41 am, Walter Lee Davis wa...@wdstudio.com wrote:
Would $('myTextArea').update('new string') be of any use, then? If the
underlying mechanism of update() is to set the innerHTML property,
wouldn't this be a nice shortcut?
It isn't much of a shortcut to call a function that will then call
half a dozen other functions to set the value of a property that you
can set directly. :-)
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: HTML Entity Handling with setValue
On Mar 18, 2:24 am, Tobie Langel tobie.lan...@gmail.com wrote: As previously discussed here, setAttribute sets the HTML attribute, which does not update the displayed value in some browsers. ViniH is correctly using Element#setValue, Yes, I misread that as setAttribute. which abstracts those issues. Not so much abstract as avoid, it sets the DOM value property (which is a much better approach than using setAttribute). The behaviour is the expected one (displaying the exact input). Since ViniH want's to display escaped data, he simply has to unescape it like so: textarea.setValue(content.unescapeHTML()); Hard to see how that is better than: textarea.value = content.unescapeHTML(); and given the machinations of unescapeHTML, why not just: textarea.innerHTML = content; -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: HTML Entity Handling with setValue
On Mar 18, 11:02 am, Walter Lee Davis wa...@wdstudio.com wrote: Not to belabor the point, but as Tobie pointed out already, textarea elements don't **have** a value property to manipulate. You've got your wires crossed - if you'd quoted what you were replying to, you'd see that it was me who said that textarea elements don't have an HTML value attribute. That comment was prompted by the OPs requirement for strict XHTML and my (incorrect) assumption that setAttribute was being used. DOM textarea elements *do* have a value property (see below). Any browser that appears to work when you do that is being kind to you, And inadvertently complying with the W3C DOM 2 HTML specification (apparently): URL: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-70715579 and misleading you in the bargain. Nope. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: help with basic regular expression
On Mar 17, 4:10 am, kangax kan...@gmail.com wrote:
On Mar 16, 1:13 pm, arkady arkad...@gmail.com wrote:
if trying to strip off the everything before the body and everything
after /body
response.replace(/.*(?=body)/, '').replace(/(\/body).*/, '$1');
That seems a bit risky, the string may not always have lower case tag
names and the body opening tag may include attributes. New lines in
the string might trip it up too. In any case, it doesn't work for me
at all in Firefox 3 or IE 6.
An alternative, provided all new lines are removed, is:
response.match(/body.*body/i)[0];
or
response.replace(/\s/g,' ').match(/\body.+body\/i)[0];
A sub-string version is:
var start = response.toLowerCase().indexOf('body');
var end = response.toLowerCase().indexOf('/body') + 7;
var theBody = response.substring(start, end)
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: writeAttribute problem
On Mar 7, 4:29 am, Tobie Langel tobie.lan...@gmail.com wrote:
Hi again, Rob.
I don't really want to argue over the benefits of attributes versus
expandos, just wanted to outline that they weren't the same thing
although the specs mandate a mapping of specified expandos to their
attribute counterpart for backwards compatibility with DOM 0.
It is also the case that IE never really figured out the difference
between attributes and expandos which has added to the confusion.
In short, attributes are attributes of the HTML element itself, thus
can only be used to store and retrieve strings (HTML cannot
distinguish types of attributes).
Strictly, the markup is interpreted by the browser and it does treat
different attribute values differently. But I get what you are
saying.
Expandos are properties of the DOM node (that is of the JS object
itself).
The expando to attribute mapping only works for attributes specified
in HTML 4.01 spec (also note that expando can be of all the primitive
JS types, not only string, and that those are also specified) so it
won't work for custom attributes.
Hence why only DOM properties that map to valid HTML attributes should
be used. Once that is realised, it follows that they can all be
reliably set using the DOM element property and that get/setAttribute
is only needed for non-valid attributes and for those, only strings
should be used.
To illustrate this, consider the following in Firefox:
var div = $$('div')[0];
div.setAttribute('value', 'foo');
div.getAttribute('value');
foo
div.value;
typeof div.value;
undefined
var clone = div.cloneNode(true);
clone.getAttribute('value');
foo
div = $$('div')[1];
div.value = 'foo';
div.getAttribute('value');
null
div.value;
foo
clone = div.cloneNode(true);
clone.value;
typeof clone.value
undefined
Of course, the behaviour is different in IE which shares the same
attribute object between cloned nodes(!).
I think you agree with me. The catch-all here is that DOM elements
are host objects and can't be trusted outside their specified
boundaries (and even then there are issues) unless you are dealing
with a specific sub-set of hosts. Just don't to it.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: writeAttribute problem
On Mar 7, 12:53 pm, kangax kan...@gmail.com wrote:
On Mar 6, 7:07 am, RobG rg...@iinet.net.au wrote:
[...]
The differences are in the browsers' implementation of setAttribute,
For example, using setAttribute with any of the intrinsic event
handlers.
Setting intrinsic event handlers was never supported, as far as I
remember, although some users did indeed try to set them and wondered
why it wouldn't work. As much as I'd hate to have another exception,
this deficiency should simply be stated in a documentation.
Yes, it was just an example of different behaviour, I wasn't
suggesting parsing attribute values.
[...]
I personally almost always use simple property assignment, because I
know what works and what doesn't; the speed benefits of `element.title
= 'foo'` vs. $(element).writeAttribute('title', 'foo') are quite
noticeable - no need to extend an element (that's O(N) in MSHTML), no
need to call a method, no need to perform testing/translation/mapping
inside that method, and so on and so forth.
Yes, agree fully.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: writeAttribute problem
On Mar 6, 8:16 pm, Tobie Langel tobie.lan...@gmail.com wrote:
writeAttribute does not fix cross browser differences in the
implementation of setAttribute.
How so? What's missing? File bugs! :)
The differences are in the browsers' implementation of setAttribute,
For example, using setAttribute with any of the intrinsic event
handlers.
Feel free to recommend otherwise but I'd like to see some reasons why.
There's one simple reason: forward compatibility.
Prototype 2.0 will stop extending prototype's of HTMLElement,
therefore, using the dot property to set or retrieve attributes will
no longer work (that is, until getters and setters are supported in
all browsers).
You'll have to fill me in on that, I have no idea what is in version
2.0. There is no mention of it on the Prototype.js web site (a search
on Prototype 2.0 returns no results)
Are you saying Prototype.js will go the way of jQuery and return an
object that has a reference to an element or elements as one of its
properties? That means jQuery shaddows all the DOM methods (which I
guess Prototype.js already does quite a bit of).
On top of that, using a unified API is always a good thing.
You said in a previous post:
The only area where you should not be using writeAttribute is:
- When you want to store anything but a string (use the new storage
API or expandos directly).
- For setting or getting the value attribute of Form elements (use
FormElement#(get|set)Value instead).
So there are now 3 APIs - these two plus writeAttribute - when no API
is necessary at all. I could count the use of observe too to replace
the buggy setAttribute('onclick', fn) in IE but that's probably going
too far. :-)
Premature
optimization isn't.
The fact that it is faster is a pleasant side effect of using the most
reliable, well supported method. It is not the sole criterion.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: writeAttribute problem
On Mar 5, 6:53 pm, Tobie Langel tobie.lan...@gmail.com wrote: Rob, Please have a look at the DOM specs. I have, the issue is how it's implemented. When the specs are written without ambiguity and all browsers follow them, it might be reasonable to use them as the sole criterion for doing something. But life’s not like that. :-( The only area where you should not be using writeAttribute is: - When you want to store anything but a string (use the new storage API or expandos directly). - For setting or getting the value attribute of Form elements (use FormElement#(get|set)Value instead). writeAttribute does not fix cross browser differences in the implementation of setAttribute. My reason for recommending using the dot property is that it works reliably, is precise, does not have the idiosyncrasies of setAttribute and, most of all, directly sets the property versus making at least 3 function calls to do (more or less) the same thing. Feel free to recommend otherwise but I'd like to see some reasons why. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Decimal places
On Mar 5, 7:50 am, Bob bro...@packagingcorp.com wrote: I'm relativley new to PrototypeJS. I am doing some calculation in a back end program and returning a JSON string to my web page. One of the values is a price. If I return 14.20, it gets converted in evalJSON to 14.2. I want to keep both digits. I can find how to pad the left of a nmber to a certain number of places, but can't seem to find anythig about keeping decimals out to a set number of places. Others have answered your question (pass the value as a string), here's a bit more information on the topic if you are doing in-page calculations and wondering why they don't quite add up: How do I format a Number as a String with exactly 2 decimal places? URL: http://www.jibbering.com/faq/#formatNumber -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: writeAttribute problem
On Mar 5, 7:32 am, Lee Jenkins l...@datatrakpos.com wrote:
Are there any known problems with writeAttribtue and FF3? I have a small
function:
function(obj){
Element.writeAttribute(obj.elname, obj.attr, obj.newValue);
}
It doesn't update the attribute.
How did you determine that? Do you have a test case?
I also tried with literal values instead of
using the object's properties as params. Setting the value using dot notation
works however and both the dot notation and writeAttribute works on IE7.
Don't use writeAttribute for attributes defined in HTML 4 for DOM
elements where setting the dot property does the job. writeAttribute
uses setAttribute which has known differences between browsers (e.g.
when working with form controls, using setAttribute to set the value
attribute will only change the value in IE, Firefox changes both the
value and the defaultValue).
setAttribute is intended to be a general way to set the value of
attributes, not properties. While it works more or less
interchangeably with the dot property 99% of the time, the few foibles
mean that it's safter to only use it for setting attributes that
aren't standard HTML 4 attributes (and use the dot property for
everything else).
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Creating Checked Radio buttons, not working in IE
On Mar 4, 7:13 pm, Alex Mcauley webmas...@thecarmarketplace.com wrote: Yes walter is correct... As far as i know you cannot insert an element into another element if it does not exist in the DOM I guess that by insert you mean append (and that isn't what Walter said). (as the element is still an object that resides in memory at the time) .. though i could be wrong Yes, you are wrong. :-( -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: When?
On Feb 26, 7:28 am, Lox gecka.comp...@gmail.com wrote: [...] then prototype is becoming the mature and stable platform for standardised/cross platform javascript development. I understand that, and quite second that, but Peppy or Sizzle are much more faster at selecting elements by css selector witch, these days where javascript apps a getting bigger, is a must have. Don't get to wrapped-up in javascript CSS selectors. Most browsers have a host getElementsByClassName that has the benefit of being a live collection (get it once, update the DOM all you like, the collection is automatically updated for you). When combined with getElementById, getElementsByTagName and standard DOM collections, you can do an awful lot easily and quickly. Further, complex CSS selectors tie your code to the page layout - isn't the idea to separate the two? Lastly, they encourage rubbish like: tagName#someID, which is used in style rules because it helps the developer, but using it in a script selector is just plain dumb. I can understand the use of selectors for prototyping or small things where speed is irrelevant, but using them as a fundamental strategy to get large sets of elements doesn't make sense. Write a function to do it using standard host methods, it will perform much faster and be easier to work with. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Updating value of hidden form control
On Feb 24, 3:50 am, Hector Virgen djvir...@gmail.com wrote: Thanks for the clarification. I assumed that the attribute would be the same as the element property, but I see now how they can be different. To change the default value, use the defaultValue property: URL: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-26091157 -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Updating value of hidden form control
On Feb 24, 2:15 am, SWilk wilkola...@gmail.com wrote:
Hector Virgen wrote:
Hello,
I am writing a plugin that takes a text input (input type=text/) and
hides it using $(input).hide(). The plugin then uses other controls to
update the value of the text input.
I am using Element.writeAttribute() to update the value, but it does not
seem to work when the input is hidden. However, using the old-fashioned
value property to update it seems to work. Is there a reason why
writeAttribute does not work with hidden elements, or should I be using
a different method?
I haven't checked any reference for this, but my from my experience,
the method Element#setAttribute('value','someValue'), used internally
by Element#writeAttribute method DOES NOT UPDATE the value at all.
writeAttribute does use setAttribute which updates both the value
attribute and value property in Firefox and IE. The issue is that in
IE 6 (and perhaps later), it doesn't change the defaultValue property
whereas it does in Firefox.
Instead it sets the ATTRIBUTE to the value provided.
The attribute and the property are set to the same value.
When user clicks
Reset button, then the attribute value is re-read and put into
Element.value property.
No, it isn't, the defaultValue property is used.
When the input is first added to the DOM, it's value and defaultValue
are set to the value of the HTML value attribute. When changing the
value using setAttribute, Firefox changes both the value and
defaultValue, however IE doesn't change the defaultValue.
Consequently, in IE, when reset it used, the value is set to the
original value (both the attribute and the property).
I use this to check if the form was modified since last save. Each
time I save the form with Ajax.Request, I also copy all
Element.value's to proper attributes. And before next save request, I
check if the values had changed, only then I submit the form.
There is no need to do that, simply compare each control's value to
its defaultValue. You'll save a bunch of CPU cycles too (not that
your users will notice).
Anyway, what I want to tell, is that the element property, and element
attribute are not always the same.
In the vast majority of cases they are identical, however there are
some HTML attribute names that match reserved words in ECMAScript
(class, for) and DOM properties that do not have an HTML attribute
equivalent (such as defaultValue).
My rule is to always use the DOM property when dealing with standard
HTML attributes and only use get/setAttribute (or read/writeAttribute)
for non-standard attributes (which I never use but sometimes I have to
deal with such use by others).
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Updating value of hidden form control
On Feb 23, 1:00 pm, Hector Virgen djvir...@gmail.com wrote: Hello, I am writing a plugin that takes a text input (input type=text/) and hides it using $(input).hide(). The plugin then uses other controls to update the value of the text input. I am using Element.writeAttribute() to update the value, but it does not seem to work when the input is hidden. However, using the old-fashioned value property to update it seems to work. Is there a reason why writeAttribute does not work with hidden elements, or should I be using a different method? If you know the old fashioned way works, and it is extremely likely that it always will as it is based on a fundamental javascript language feature, why would you use writeAttribute at all? -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Remove an element from the DOM and add it later exactly to the same point
On Feb 19, 3:55 pm, RobG rg...@iinet.net.au wrote: [...] *Do not* use Prototype.js's sibling array as it will remove text nodes, you certainly don't want to do that. Not worded quite right: Prototype.js doesn't include text nodes in its sibling arrays, but they should be used in this case so use the DOM native methods. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Firefox document.getElementById
On Feb 12, 1:03 am, T.J. Crowder t...@crowdersoftware.com wrote: Hi, Details here:http://prototypejs.org/learn/extensions The following statement in that article is wrong: ...native objects such as HTMLElement... HTMLElement is a *host* object, not a native object. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Taboo Subject
On Feb 10, 8:29 pm, Lars Schwarz lars.schw...@gmail.com wrote: well, it's like fixing IE6 bugs. i mostly double-code functions like form-checks that are done pre-posting in javascript, to be checked again on server side again for the case javascript is turned off. The reason to check on the server isn't because scripting might be disabled, but because your server can't possibly know how the response was generated. if you can't double-code some functions make sure the most important work without javascript, too. seperate necessary functions and effects you've done. in most cases it's no problem if some effects don't work, but make sure basic functions like form-validations or whatever you call basic-functionality on your project works with javascript disabled. Yes, absolutely. I find it contradictory that some pursue a strategy of separating HTML and script, make their site utterly dependent on scripting. One result is that they have no recourse to simple HTML when all else fails. on the other hand (really depends on your project) it's ok inform the user that he has to turn on javascript to make the site work. That is usually only appropriate on an intranet or special purpose site (e.g. banking or share trading). i guess it's a matter of taste. i remember sites warning the user if he used an old browser, or sites that alert users that this site is optimized for insert browser name here. i prefer sites that make use of standards and work on (nearly) all browsers. Yes. Forcing the use of scripting on the general web is akin to both those outdated strategies. turn off javascript, visit some sites you think are state-of-art and see how they handle it :) I use NoScript always and only allow the scripts that are absolutely necessary to use a site to run (mostly none at all). I have yet to find a reason to allow adsense or google-analytics to run. imho: have some kind of fallback and make sure basic functionality/validations/checks work, but don't care about visual effects working without javascript. just my 10 cents. I'd second that. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Javascript scope
On Feb 11, 11:21 am, doug douglass_da...@earthlink.net wrote: I have read about Javascript and scope and I still don't really understand it completely, particularly when it comes to Ajax.Updater. I don't really understand, for example why, if there is a variable window.myvar, some Javascript code would not be able to access it, and instead it would be undefined for that code. I was thinking window.myvar was global Without seeing the code, only guesses can be provided in response to that. It may be that myvar hasn't been assigned a value when you try to access it, or the code is trying to access a different window object, or the identifier resolves to a property on some other object, and so on. But, my question is, is there a way I can do some type of alert() and have it print out what scope it is executing in? Javascript only has 2 scopes: global and function. However, there can be more than one global object in a web page (e.g. frames). There is a long and detailed article on closures here that includes how scope works: URL: http://www.jibbering.com/faq/faq_notes/closures.html It is a bit daunting when you first start to read it, but stick at it, you may take a week or so of solid work to get all the way through and fully understand it. But if you take the time, by the end you will have a very good idea of how identifier (hence scope) and property name resolution works in javascript. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Prototype bug?
On Feb 10, 9:35 pm, Jim Higson j...@333.org wrote:
On Feb 8, 1:19 pm, RobG rg...@iinet.net.au wrote:
[...]
It's a bit unfair to blame the language for what you consider an
inappropriate use of one of its features. Perhaps the name of the
function should be isStringPrimitive.
I guess I *am* blaming Javascript for having (in effect) two string
types. No other languages do this and (as far as I know) having two
kinds of strings doesn't let you do any cool stuff that you couldn't
do with one.
I'm not arguing that javascript (or more correctly here ECMA-262, but
javascript will do) is perfect, I'm just accepting it at face value.
It was designed to be a simple, easy to use language so a primitive
string will act as a string object when it needs to in most cases.
I see having two string types as one of those strange quirks of
Javascript that libraries like Prototype should smooth over so the
programmer can just think ...Ok I've got a string... without
worrying which of the types of strings s/he has.
What is needed is an appropriate test in the right place, what you
really want to test is is this thing suitable for what I am about to
do with it.
There are many cases where you can pass a string or number primitve
and not care which one you have, but if your parameter accepts either
object or primitive and you discriminate using typeof (masked by a
wrapper function), anything that passes a String or Number may cause
it to do inappropriate things.
[...]
It is extremely rare to come across a String object in javascript, so
there seems very little point in an isString function when the vast
majority of the time a typeof test is sufficient (and less
problematic).
Personally, I think the rareness of String objects is part of the
reason why it *is* desirable to take them into the account. As a
programmer you make assumptions that you're dealing with normal
strings, then suddenly an object String turns up everything breaks.
But you come to debug and the object string looks a lot like a normal
string and the bug takes ages to track down.
Your interface should be documented and say what type arguments must
be. You can't test every input always to see what you have (Number,
Math, RegExp and a variety of host objects will 'object') you have to
make some assumptions about the competence of whoever is using your
API. At least if it is failing on typeof it should not get to
production (unless testing is deficient too, or the behaviour is seen
as a feature...).
I started this thread when some library code I use started acting
oddly.
It turns out this was because some other code (which I didn't write)
was passing new String('foo') into it.
Off the top of my head, my code was something like:
if( Object.isString( foo ) ){
do something( foo );}else if( Object.isObject( foo ) ){
foo.each( function( i ){ /* ... */ } )
}
So given a String object was iterating through each char in the
String.
Cool! See, extra features the client didn't expect! :-)
In the unlikely event that you want to know if the thing you have is a
String object, use instanceof. What is the use of an isString
function that can't tell the difference between an object and a
primitive?
I think treating them as both just Strings makes for easier to read
code.
The language is designed so you shouldn't need to care. I think this
helps the argument of why functions like isString are not a good
idea. If you want to test for specific properties or features of an
object, test for them. Don't test some other property and make
assumptions based on it, which is what isString encourages.
Much better to learn the ins and outs of typeof and other operators so
you know to use them appropriately. It doesn't make sense to me to
paper over such things as they will come back to haunt you in
unexpected ways.
At the moment I test like this:
if( Object.isString( foo ) ||
( Object.isObject( foo ) foo.constructor == String ) ) {
//...
}
I can't think of any reason why I'd want to react to primitive Strings
differently from string objects, so I think just writing this makes
clearer code:
if( Object.isString( foo ) ) {
//...
But that is your concept of a string, others may differ. I'm not
going to defend functions like isString etc. since I disagree with the
concept behind them for a language like javascript where the concept
of isSomething is not well defined on purpose (again, I'm not saying
that is good or bad, it's just the way it is).
}
I can't conceive of a scenario where a String object would be used and
I'd get into a situation where I needed to test for something that was
either an object or a string. If it doesn't matter, why use an
object?
Because I can't always control the values that are passed to functions
that I write. I don't know of any good reason why one would create a
String object, but if some client code does I should at least handle
[Proto-Scripty] Re: Prototype bug?
On Feb 8, 12:55 am, Jim Higson j...@333.org wrote: alert( Object.isString( foo )); // alerts string It alerts true. alert( Object.isString( new String( foo ) )); // alerts object It alerts false. I know why this happens - because Prototype uses the underlying typeof's understanding of type. That typeof returns the type is pretty reasonable given that it is called typeof. Personally I think this is a bug though - Javascript is just being difficult here It's a bit unfair to blame the language for what you consider an inappropriate use of one of its features. Perhaps the name of the function should be isStringPrimitive. and Prototype should make stuff like this easier. It should return string regardless of how the string was created. It is extremely rare to come across a String object in javascript, so there seems very little point in an isString function when the vast majority of the time a typeof test is sufficient (and less problematic). In the unlikely event that you want to know if the thing you have is a String object, use instanceof. What is the use of an isString function that can't tell the difference between an object and a primitive? I can't conceive of a scenario where a String object would be used and I'd get into a situation where I needed to test for something that was either an object or a string. If it doesn't matter, why use an object? And if it did matter, I'd want to test for one or the other in which case neither the current isString or your suggested modification would do the job. Perhaps is should return one of three values: primitive, object or boolean false. Then if you don't care, you can use use: if (isString(...)) ... as either 'object' or 'primitive' will resolve to true, but boolean false will be false. If you do care, you can use: if (isString(...) == 'primitive') ... The bottom line is to look at why you would use such a function, and whether there are already suitable language features that do the job. Anyone agree I should file this as a bug, or is there a good reason the current behaviour is desirable? It can hardly be called a bug when it does what the documentation says it does (I think works as designed is the polite response). The function itself is a bit pointless though, as are similar functions like isNumber, e.g. Object.isNumber(NaN); // true Consider: var x = 'a' * 2; Object.isNumber(x) ); // true -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Prototype bug?
On Feb 8, 11:53 pm, kangax kan...@gmail.com wrote:
On Feb 8, 8:19 am, RobG rg...@iinet.net.au wrote:
[...]
It can hardly be called a bug when it does what the documentation says
it does (I think works as designed is the polite response). The
function itself is a bit pointless though, as are similar functions
like isNumber, e.g.
It's not pointless, but the scope of its use is indeed pretty narrow.
Can you provide a scenario where isNumber is more suitable than
typeof? If not the scope of its usefulness is zero.
Since neither `instanceof` operator nor `constructor` value check can
not be relied upon when working with multiple contexts (frames),
`Object.isString` is here to take care of it.
They test for completely different things. I would guess that if
instanceof or constructor tests are necessary, typeof is unlikely to
be a useful replacement regardless of the context. If typeof is a
suitable replacement, then there was no point in using instanceof et
al in the first place.
Can you write an isNumber function that uses instanceof across frames
successfully? And if so, can you define the time when such
functionality would be useful?
AFAIK, ES committee is
planning to finally document ECMA behavior in context of multiple
global objects.
Great, but irrelevant to the current discussion. Or are you inferring
that isNumber is simply a placeholder for possibly useful (but as yet
undefined) future functionality?
Object.isNumber(NaN); // true
Should it return `false`?
According to the documentation, no - but the function name suggests
otherwise. Perhaps ‘isNumberType’ more accurately reflects what the
function does.
Anyway, it doesn't matter what I think it should return - ask those
who are its intended user base. Should isNumber('5') return true?
The documentation says isNumber is a wrapper for typeof, so why not
just use typeof and save the confusion?
4.3.23 (NaN) says that ... This value is a member of the Number
type.. Also, `typeof NaN == number`, NaN's `constructor` is
`Number`, its [[Class]] is Number and it's [[Prototype]] references
`Number.prototype`? Should we return `false` for practical reasons?
You're making my argument for me. :-)
All those points are valid and highlight that if one or more of those
properties are of interest, they should be tested for explicitly.
There are values that aren't numbers (either Objects or primitives)
that can be used safely in arithmetic operations and some that are
numbers that can't.
A function like isNumber can't cover all possibilities unless it
returns a variety of values depending on the type, constructor, etc.
and if it was one of those properties that are really of interest, why
not test for it directly?
And what should `Object.isNumber` return for +/-Inifinity? Adding
`isFinite` to `isNumber` would be able to take care of both - `NaN`
and `Infinity` cases.
If the current behaviour is not suitable (it seems to do exactly what
it is documented to do, so I’m not complaining about that), then the
first step in writing a new isNumber function is to define its purpose
- what is it for? Next would be to define what a number is (which may
seem trivial at first glance but the points discussed above show it
isn't) and the context in which isNumber is or isn’t suitable. Is it
to test that the value is type number? An instance of Number? A value
that can safely be used in an arithmetic operation? One that can be
converted to a useful number? And so on.
Without knowing what the purpose of the function is, it’s impossible
to say how it should handle edge cases. And if a purpose can’t be
stated concisely, then perhaps it doesn’t have one that is useful.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Prototype bug?
On Feb 9, 11:37 am, kangax kan...@gmail.com wrote:
On Feb 8, 7:32 pm, RobG rg...@iinet.net.au wrote:
On Feb 8, 11:53 pm, kangax kan...@gmail.com wrote:
[...]
It's not pointless, but the scope of its use is indeed pretty narrow.
Can you provide a scenario where isNumber is more suitable than
typeof? If not the scope of its usefulness is zero.
Of course. `isNumber` (as it is in a trunk) will return `true` for
Number *object*, while `typeof` will obviously return object.
Whether Number objects are something that should be present in a
script (rather than simple number primitives) is a different topic.
Not at all, it's what I was asking for. I can't conceive of a
situation where I would use isNumber (either in its current state or
the proposed modification). I'm asking for a scenario where I would
*use* it.
[...]
AFAIK, ES committee is
planning to finally document ECMA behavior in context of multiple
global objects.
Great, but irrelevant to the current discussion. Or are you inferring
that isNumber is simply a placeholder for possibly useful (but as yet
undefined) future functionality?
`isNumber` is an abstraction level. A noble (but ill-conceived) goal
to unify type checking in diverse Javascript land : ) IIRC, the first
version of `isNumber` looked like - `return typeof object ==
number`, and was added for *consistency* with other `Object.is*`
methods - an infamous `isArray` was one of the first ones (following
by others). Right now, I don't believe in generic solutions. The best
way to go is to get familiar with language and use whatever fits the
best. Nevertheless, checking for [[Class]] == Number seems to cover
most of what masses desire (I'm also inclined to making `isNumber`
filter out `NaN` and `Infinity`)
Now you are back on topic. But [[Class]] can only be indirectly read
via toString, so it isn't that reliable but might be good enough for
most. Anything that has a [[Class]] of Number should probably emulate
the properties of a native Number. The argument now goes to the same
place as isArray - no need to repeat that here. :-)
Object.isNumber(NaN); // true
Should it return `false`?
According to the documentation, no - but the function name suggests
I'm not talking about documentation at this point. I'm interested in
your opinion (but you already said it best few paragraphs down)
otherwise. Perhaps ‘isNumberType’ more accurately reflects what the
function does.
Well, the way it's implemented at the moment is by checking object's
[[Class]]. If anything, it should be called isNumberClass but then
there's possibility of a confusion with Class in its common OOP
sense.
And Prototype.js's implementation of Class also. What a tangled web
we weave. :-)
Anyway, it doesn't matter what I think it should return - ask those
who are its intended user base. Should isNumber('5') return true?
The documentation says isNumber is a wrapper for typeof, so why not
just use typeof and save the confusion?
I'd rather change documentation, since as we know by now, `typeof` is
not always sufficient (and whenever it is - it can just be used
explicitly, without resorting to any higher order helpers).
Given that in version 1.6.0.3 (the current version as far as I know)
it is:
isNumber: function(object) {
return typeof object == number;
},
the documentation is correct. Perhaps you meant change the
documentation when the new version is published.
4.3.23 (NaN) says that ... This value is a member of the Number
type.. Also, `typeof NaN == number`, NaN's `constructor` is
`Number`, its [[Class]] is Number and it's [[Prototype]] references
`Number.prototype`? Should we return `false` for practical reasons?
You're making my argument for me. :-)
All those points are valid and highlight that if one or more of those
properties are of interest, they should be tested for explicitly.
There are values that aren't numbers (either Objects or primitives)
that can be used safely in arithmetic operations and some that are
numbers that can't.
A function like isNumber can't cover all possibilities unless it
returns a variety of values depending on the type, constructor, etc.
and if it was one of those properties that are really of interest, why
not test for it directly?
Yes. Using the right tool for the job was the morale of my first post
in this thread - Javascript is actually quite flexible... : )
And what should `Object.isNumber` return for +/-Inifinity? Adding
`isFinite` to `isNumber` would be able to take care of both - `NaN`
and `Infinity` cases.
If the current behaviour is not suitable (it seems to do exactly what
it is documented to do, so I’m not complaining about that), then the
first step in writing a new isNumber function is to define its purpose
- what is it for? Next would be to define what a number is (which may
seem trivial at first glance but the points
[Proto-Scripty] Re: validation for alphanumeric field/sequence
On Feb 7, 12:21 am, kangax kan...@gmail.com wrote:
On Feb 6, 7:36 am, ColinFine colin.f...@pace.com wrote:
On Feb 5, 9:29 pm, Michael mich...@vermontsnows.com wrote: Thank you all
- Kangax's low profile technique works like a champ.
Walter Lee: Regular expressions hurt my head. I will get there one
day.
The actual thing I am working on take about 100 alpha/numeric
sequences of no real logical order... so making it in regular
expression would take far longer (for me) then juts stubbing the 100
sequences in there.
In Perl, I would not use regular expressions for this at all, but a
hash:
(equivalent of)
var hash = {V3: true, B47242:true, V54000:true};
function checkValid(value)
{
return hash[value];}
(or 'return hash[value] == true' if you're picky).
This is a good idea in Perl because the language is optimised for
accessing hash values: I don't know how true that is in javascript.
I'm pretty sure property lookup is faster than regexp in Javascript
too.
It doesn't take much to test. Using a set of 1,000 values and looping
through 10,000 lookups took about 45ms in Firefox on a laptop with a
1GHz processor regardless of which method was used. The regular
expression version was generally faster in Safari, however both were
still generally less than 45ms.
The biggest hit to performance is forming the object, either a
delimited string or JSON that can be converted to an object.
The bottom line is that performance is an insignificant criterion in
this case.
The only downside to this approach is that there's no reliable
(native) hash structure in Javascript.
Some would argue that there is no Hash at all, but there are objects
that can be made to behave a bit like Hashes in other languages. :-)
There also needs to be a
boolean type conversion in your example, so that the function
consistently returns either `true` or `false` (and not, say,
`undefined` - for missing members).
A falsey or not true value may be sufficient, but since the value of
the object property is only used for comparison, it may as well be
boolean true. It could just as easily be 1 or 'hey' or any non-falsey
value if it served some other purpose.
Overloading of the property value might be seen as a good thing - or
not. It isn't possible with the regular expression method (well, it
is possible but requires more logic such as a comparison function but
that is getting well away from the intention of the OP). That might
be seen as a better thing.
Regular property lookup is
unreliable in such way that it takes object's prototype chain into
account; That means there could be a conflict with
`Object.prototype.*` properties - e.g.: `isValid('toString')` would
return `Object.prototype.toString` which is a Function object and just
like any object - type converts to `true` : )
The general issue is discovery of property names on the inheritance
chain that match tested values. Adding a hasOwnProperty doesn't
slow performance much (not noticeable in either browser I tested) and
logically may speed it up - it's an extra function call but doesn't
search the [[prototype]] chain.
In more generic method,
it would probably be a good idea to use
`Object.prototype.hasOwnProperty`, but in this case, strict equality
operator would do:
var isValid = (function(){
var hTable = { V3000: true, B47242: true, V54000: true }
return function(value) {
return hTable[value] === true;
// return Object.prototype.hasOwnProperty.call(hTable, value);
}
})();
Given that the difference in performance is negligible[1], a more
important criterion is the difference between generating a delimited
string (something most databases are very good at) compared to a JSON
object (which only some are good at and is more complex in general).
Compare generating the JSON string:
'{ V3000: true, B47242: true, V54000: true }'
to the delimited string:
V3000 B47242 V54000
I know which one is simpler to generate and debug - of course the OP
is free to choose.
1. It might be in IE, I didn't test it. My impression is that JScript
is pretty quick with native code.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: div inside select/select tags?
On Feb 4, 10:41 am, Richie M i...@linuxbox.co.uk wrote:
Hi,
I have a form with three drop down select boxes in it. I'd like the
second box to populate when an option is selected in the first, and
for the third to populate when an option is selected from the second.
In the first select box, I use onchange to call a php script:
select id='box1' onchange=ajaxUpdater('ajax_regions', '/ajax/
populate.php?show=monthid=' + getsel('box1')
Apart from the invalid HTML (pointed out by TJ), it is very unwise to
use an onchange handler with a select element if there is any chance
the form will be used in IE. If a user tries to navigate the options
using the cursor keys in IE, a change event will fire each time the
key is pressed and changes the selected option - I don't think that is
what you want.
I don't know what the getsel function does, however I suspect you are
using the ID attribute inappropriately. Option elements have a value
attribute[1] that is supposed to be used to send data to the server,
select elements have a DOM value property that is determined from the
selected option, so why not use:
select onblur=ajaxUpdater(... + this.value);
option value=value 0value 0
option value=value 1value 1
option value=value 2value 2
/select
Or use an explicit update the form button.
1. The text attribute can be used to, however due to IE's non-
compliance with the W3C standard relating to use of text as the option
value, it is easier to explicitly use the value attribute.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Cloning an HTML Element
On Jan 24, 6:57 am, da644 andrewjdi...@gmail.com wrote:
Hi,
I have an HTML object that has been creating using some scripting and
I wish to insert this into to different locations on the page, e.g.
var newObj = createMyObject();
$('location1').insert(newObj);
$('location2').insert(newObj);
However doing this the object get inserted into location1 and then
removed from location1 when it is inserted into location2.
Which is exactly how it is supposed to work. :-)
I have
tried using the clone method:
var newObj = createMyObject();
var newObj2 = Object.clone(newObj);
That is for cloning (more like copying) a native javascript object.
What you are trying to do is clone a host object.
$('location1').insert(newObj);
$('location2').insert(newObj2);
However this doesn't work. It doesn't error, but it simply stops
anymore Javascript from executing.
Is there a way to do what I want using Prototype?
If your object is an HTML element that implements the DOM Core
interface Node (and most of them do), use its cloneNode method:
$('location1').insert(newObj.cloneNode(true));
It is called cloneNode to ensure it is obvious that its purpose is
to clone Nodes, not other types of objects. Be aware however that it
will clone all of the element's properties, including ones like ID
that should be unique in the document.
Also, listeners may or may not be cloned depending on how they were
added and which browser the code is run in.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: reserved words for prototype and/or scriptaculous?
On Jan 17, 12:30 am, ColinFine colin.f...@pace.com wrote:
[...]
but if you want it to be more general, you can say
getData(evt.element().up('form'))
All form controls have a form property that is a reference to the form
they are in, so why not:
getData(evt.element().form))
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: error in IE7 while trying to readAttribute from option
On Jan 6, 6:01 am, kidbrax braxton.be...@gmail.com wrote:
when I try the following code I get an error in IE7:
someVar = mySelect.options[mySelect.slectedIndex].readAttribute('rel')
The rel attribute is not valid for option elements, it is valid for A
and LINK elements.
It causes the 'Object doesn't support this property or method' error.
It only seems to happen when I run it on an option tag. Is there
another way to get the 'rel' attribute from an option tag that is
cross-browser?
Try:
var someVar =
$(mySelect.options[mySelect.slectedIndex]).readAttribute('rel')
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Custom attributes or not custom attributes ?
On Dec 31 2008, 12:05 am, buda www...@pochta.ru wrote: But to store metadata in objects - is doing overjob - elements might be added or deleted or changed their style or state - and syncronyze elmenets state with their object mappers - is very hard and useless It's not hard at all, and definitely not useless (after all, you want to do it). Consider that DOM elements are simply one way of displaying the data in business objects. Do all of your work with the objects, then send the data to the screen to be viewed. That model separates the business logic from the display logic. Of course there are some functions that are pure UI (e.g. sorting a table or list) but others, like updating the table rows from a server, should be done with an object, then written to the UI. If you only have one table representing a single data object, it probably doesn't matter if you just update the table directly using AJAX or similar, but once you have a number of data objects and maybe a number of different ways of displaying their content, you will want to separate display from business logic. -- Rob. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Custom attributes or not custom attributes ?
On Dec 29, 8:38 pm, buda www...@pochta.ru wrote: It is useful, but I don't think it's worth the trouble and I personally don't use it. IE's DOM is one example of what makes custom attributes troublesome - you never know which issues you will run into due to every custom attribute ending up as a property of an element. What if attribute name (which becomes a property name) is a reserved word (according to ECMAScript/JScript)? What if it corresponds to some IE's proprietary element property? Which of them takes precedence and which issues it might cause? etc. I completle confused at finally - where to store elements metadata? DOM elements are designed to provide a user interface, they shouldn't be used as business objects or to implement business logic. What is the best way? Use javascript objects, use DOM elements and events to interact with the user. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Improving FPS Speeds
On Dec 17, 8:52 pm, Craig cr...@europe.com wrote:
site im developing is not live but similar tohttp://www.aspecto.co.uk/
Is there much use in creating a slider function to run all the sliders
from would this make much of a difference?
It might make the code tidier and get rid of some global variables,
but I doubt that it will have any effect on speed.
There seems to be an over reliance on try..catch, which should be used
about as often as eval (i.e. rarely and usually when there is no other
option). It seems to be used whenever the code author was too lazy to
test if an object exists before trying to do something with it, e.g.
try
{
width_r = ($('side_right').scrollHeight - $
('side_right').offsetHeight);
}
catch(error)
{
width_r = 100
}
Presumably that was done because an element with id side_right may not
exist. Consider:
var el = $('side_right');
// If that didn't return something, deal with it
if (!el) return;
// Otherwise, use el
width_r = el.scrollHeight - el.offsetHeight;
Then there is:
if(width_r 1)
{
width_r = 1
}
If width_r must have a value within a specified range (in this case it
seems to be that it must be 0), it should be dealt with when it is
set and the reason should be documented:
// width_r must have a positive integer value
width_r = (el.scrollHeight - el.offsetHeight) || 1;
and so on. If you want analysis of your slow code, you'll need to
post, or link to, an example that is slow.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@googlegroups.com
To unsubscribe from this group, send email to
prototype-scriptaculous+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Improving FPS Speeds
On Dec 17, 3:13 am, Craig cr...@europe.com wrote: I have a very graphics intense website with 4 sliders on each coded in a serperate JS file. Recently i have developed a full screen image viewer that behaves much like lightbox. I am using the effects library to BlindDown the image and alternates in their containers as well as Appear/Fading a background that covers the whole page. Problem is that this makes the browser lag and the animation does not look smooth at all. Does anyone have any tips that could be helpful for me to improve the FPS as i am not the most experienced js programmer? Optimisation for speed usually starts by finding the code that is most sluggish. You can spend a very long time optimising by doint things like replacing for loops with do loops or whatever for marginal improvement when some other simple change, like replacing extensive use of += to concatenate strings with Array.join or just plain + (specific to IE), can have a dramatic effect. Post a link. You might also consider whehter your effects add to the functionality of the page or are just a nusance. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@googlegroups.com To unsubscribe from this group, send email to prototype-scriptaculous+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: select only text (i.e. textnodes, probably) using $$
On Dec 11, 3:25 am, lskatz [EMAIL PROTECTED] wrote: I finally got around to this, and it turns out that even though the approach is good, I cannot insert HTML tags. I chose to not use recursion to make it simple. The problem is that it uses each character literally and displays the htmlentities instead of actually making html tags. Because you are modifying the text node's nodeValue attribute, not its innerHTML property so the replacement text isn't parsed as HTML. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: IE eval() question...
On Dec 4, 11:17 am, yoshi [EMAIL PROTECTED] wrote:
heres my js:
var stuff7=eval('function() {alert(stuff..);}')
when i alert stuff7 it is undefined.
The code passed to eval is treated at a function declaration. Without
a name, it is a syntax error.
now if i do this:
eval('var stuff7=function() {alert(stuff..);}')
and alert stuff7, it is defined
Because now it is a valid function expression. You could also use a
valid function declaration:
eval('function stuff7() {alert(stuff..);}')
does anybody know y, the jscript eval doc doesnt really help,
No surprises there, it is a user guide, not a specification. Use
ECMA-262, section 10.2.2.
i suspect it is a scope issue?
It's a syntax error.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Simple question
On Nov 27, 11:32 pm, spradeepkumar [EMAIL PROTECTED] wrote: [...] If you are particular in using this...prototype has got bind methods with which you can control your scope The value of a function's this keyword has nothing to do with scope, it is set by the call. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Browser Support List?
On Nov 15, 6:18 am, Hector Virgen [EMAIL PROTECTED] wrote: Thanks, TJ. That's a really good point, but unfortunately many of our clients use old Macs with IE 5.5. I would still like to provide them with some basic Javascript UI enhancements. Does that mean I would have to write native Javascript for them? Yes. Just including Prototype.js in the page will throw errors so don't even do that. Have your pages function correctly without any scripting, then add only the features needed to improve the UI. Use feature detection not browser sniffing. Depending on the functionality you want, you might be surprised at how little script you need if your pages are well designed in the first place. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Browser Support List?
On Nov 14, 9:54 am, Hector Virgen [EMAIL PROTECTED] wrote: Sorry if this has been asked before, but is there an updated list of browsers and versions supported by Prototype? URL: http://groups.google.com/group/rubyonrails-spinoffs/browse_thread/thread/37d5a3b8da4fb1c7/7f92194bee9e51bd?hl=enlnk=stq=Prototype+supported+browsers#7f92194bee9e51bd I'm particularly interested in slightly-older Mac-based browsers like IE5.5 and Safari 2. Thanks! I doubt very much that IE 5.5 on Mac OS is supported, Safari 2 should be OK. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: evalScripts problem
On Nov 14, 7:39 am, Ehsun [EMAIL PROTECTED] wrote:
I've create an Object in my pages script tags, something like this:
a = new A();
and when I want to call a method of a in the script which is actually
the ajax content (evaluated with .evalScripts) everything is fine. but
when the creation and the calling code, both are in the ajax contents
(seperate requests) which are evaluated! the second script (calling
script) has no access to the object!!!
What should I do?
Using eval changes the execution context, the following might help
explain:
var a = 1, b = 2;
function evalString(s) { eval(s); }
alert(a == b); // false
evalString('var b = 1;');
alert(a == b); // false
evalString('b = 1;');
alert(a == b); // true
evalString('function foo(){alert(foo);}');
try {
foo();
} catch (e) {
alert(e); // ReferenceError: foo is not defined
}
evalString('foo = function (){alert(foo);}');
foo(); // foo
There are work arounds, but best to avoid eval'ing scripts altogether.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Action on innerHTML and bindAsEventListener doesn't work anymore
On Nov 7, 12:24 am, T.J. Crowder [EMAIL PROTECTED] wrote:
Hi,
Yes I know this possibility. I though about it, but I can not use
it... and I don't think the bind problem will be fix in that way ;)
I'm pretty sure it will. Did you try it? I did a trivial test, and
it worked fine. Here's my version of moveDown, which differs slightly
from Rob's as it uses Prototype-isms:
It's a little bit different, it expects elm to be the element to be
moved, whereas what I posted expects the event to come from an element
inside the element to be moved, e.g.:
div onclick=moveDown(this);
button ... ... /button
/div
div onclick=moveDown(this);
button ... ... /button
/div
function moveDown(elm)
{
var next;
elm = $(elm);
next = elm.next();
if (next)
{
elm.remove();
next.insert({after: elm});
I don't think there's any need to remove then insert, you can just
insert the node in the new location. Coupled with a bit of standard
DOM, there's no need for the if statement - the entire block can be
replaced with:
elm.parentNode.insertBefore(elm, next.nextSibling);
and the function becomes:
function moveDown(el) {
var next = $(el).next();
el.parentNode.insertBefore(el, next.nextSibling);
}
Each to their own. :-)
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Building a lazy Loader
On Nov 7, 12:52 am, Alex Mcauley [EMAIL PROTECTED] wrote: i want it to be transparent hence the syncronous request Blocking the UI is hardly transparent. The lazy loading of scripts is a flawed strategy - it seems a good idea but if you think about the issues, you should realise that you'll get far more benefit from ensuring your code is concise, then budling it into as few source files as reasonable (say one or two) and using the same script files throughout your site so the browser can use cached stuff where possible. Use server-side technologies to bundle required scripts together, that's an order of magnitude more efficient than client-side with AJAX. Loading files as required means waiting for the request, downloading the file, waiting for it to initialise, then calling stuff in it. Way too complex and very prone to errors - zip your source files and let the browser deal with downloading them efficiently. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Building a lazy Loader
On Nov 7, 5:45 am, Matt Foster [EMAIL PROTECTED] wrote: What are the drawbacks of requestings the JS file via Ajax.Request and stuffing the responseText inside the innerHTML property of a generated script element? It is not reliable across browsers, nor is assigning the source as a string to the text attribute, nor adding a text node with a value of the source. Using a script element with a src attribute is the most reliable. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Action on innerHTML and bindAsEventListener doesn't work anymore
On Nov 5, 2:58 am, jak0lantash [EMAIL PROTECTED] wrote:
Hi everybody.
I have some difficulties with bindAsEventListener. I'm working on a
little module system (like in netvibes, but simpler).
In the page, there are two div, kind of module, one on top, one on
bottom. With a button, I switch the both div.
1) To switch, I use - and I think the problem is here - the property
innerHTML
2) To listen the click event of the both buttons, I create two Object
of a Class Module (created with the prototype lib Class.create), and I
link the button to a function by bindAsEventListener.
3) My problem is : the switching works well, but after this action,
the both buttons seem to not be linked anymore to the function.
Nothing happen, the function is not called...
I think that your solution is way to complex for what you are doing.
If all you want to do is swap the position of the divs, insert the one
that you want to move down as the next sibling of the one below it (if
there is one) - i.e. the nextSibilng of its nextSibling.
e.g.
script type=text/javascript
function moveDown(el) {
var div = el.parentNode;
var nextSib = div.nextSibling;
while (nextSib nextSib.nodeType != 1) {
nextSib = nextSib.nextSibling;
}
if (nextSib) {
div.parentNode.insertBefore(div, nextSib.nextSibling);
}
}
/script
div id=container
div id=module-0
button onclick=moveDown(this);Move Down A/button
/div
div id=module-1
button onclick=moveDown(this);Move Down B/button
/div
div id=module-2
button onclick=moveDown(this);Move Down C/button
/div
/div
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Zebra Stripes
On Oct 30, 9:46 am, solidhex [EMAIL PROTECTED] wrote:
I am trying to figure out a way to zebra stripe list items in an
unordered list. The only tricky part is that I don't want to zebra
stripe the nested lists, but I want to maintain the same every other
stripping pattern on the nested list's parent. Here is an example of
the structure that I want to get at (I've added in the class here
manually to make it more clear what I am trying to do):
[...]
My attempt to pull this off is something like:
document.observe(dom:loaded, function() {
$$(ul.foo li).each(function(el, i) {
if (!el.up(1).match('li') i % 2 == 0) {
Change the selector:
$$(ul.fooli).each(function(el, i) {
A shorter test, returns true for even numbers, remove ! to get true
for odd numbers (noting that the first element is index 0 so is even,
although its position is 1, which is odd - but not *that* odd):
if ( !(i%2) ) {
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: how to load scripts dinamically
On Oct 17, 3:22 am, SWilk [EMAIL PROTECTED] wrote:
Hey,
T.J. wrote a How-To on the wiki based on todays thread:
http://proto-scripty.wikidot.com/prototype:how-to-load-scripts-dynami...
I just have one question regarding the how-to:
quote
Here's the dynamic.js file:
scriptLoaded('dynamic');
function coolFeature()
{
alert('Coolness!');}
/quote
Is it possible that the execution of this included script was paused
after scriptLoaded() call, but before coolFeauture() is created?
The ECMAScript Spec, section 14 Program says:
| The production Program : SourceElements is evaluated as follows:
| 1. Process SourceElements for function declarations.
| 2. Evaluate SourceElements.
| 3. Return Result(2).
In other words, all the script is read, then execution begins. You
may have issues if the function is defined in a script that is loaded
after a script that calls it.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: writing unintrusive javascript with prototype
On Oct 14, 5:07 pm, T.J. Crowder [EMAIL PROTECTED] wrote: [...] One way to do this is to have the relevant fields tagged with a specific CSS class. An excellent response overall, but just for the record: the HTML class attribute is not targeted at CSS, it is for any purpose you wish to put it to (even none at all). The W3C HTML 4.01 spec[1] doesn't single out any particular use. CSS can use the class attribute, just as it can use other element attributes such as tagname, id and name. 1. URL: http://www.w3.org/TR/html401/struct/global.html#adef-class -- Rob. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: textarea and linebreaks
On Oct 16, 4:42 am, buda [EMAIL PROTECTED] wrote: I'm sorry - maybe its not sutable forum but I dont take part in anyone except this one I have a textarea with wrap=hard Wrap is not a standard attribute (i.e. it isn't part of the HTML 4.01 standard), it can't be expected to be consistent across browsers (and it isn't). The best place to discuss that is: news: comp.infosystems.www.authoring.html URL: http://groups.google.com/group/comp.infosystems.www.authoring.html it works as I expected I guess you mean according to the MSDN article: URL: http://msdn.microsoft.com/en-us/library/ms535152(VS.85).aspx It would be good if you provided an explanation or link so that others know what you expected. but when i tryed to set textarea.innerHTML = textFromServer it doesnt wraps text onto lines The content of a textarea element is plain text, setting its innerHTML property to change its value is not appropriate, use the value property directly: textarea.value = textFromServer; therefor linebreaks are present in textFromServer That doesn't make sense - you say it doesn't wrap, therefore there are linebreaks? How are the line breaks included in the textFromServer? As \r or \n or similar? what should I do? Take the line breaks out at the server before sending the text, or strip them before assigning to textarea.value. Do not set the wrap attribute to anything (don't use it at all), use CSS to define the width of the textarea and also set the cols attribute so the text will wrap using the browser's rules (in standards compliant browsers). But discuss it in comp.infosystems.www.authoring.html - some there are a bit surly but it's where you'll find the experts and you will get good advice. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Getting Text Nodes of Elements
On Oct 12, 3:29 am, Justin Perkins [EMAIL PROTECTED] wrote:
On Sat, Oct 11, 2008 at 10:31 AM, RobG [EMAIL PROTECTED] wrote:
Performance is not the issue - fewer lines of code doesn't necessarily
mean faster performance.
Do you differentiate between browser sniffing and object/method sniffing?
As far as I am aware, there is no such thing as object/method
sniffing, it's called object/feature detection. Browser sniffing is
using the user agent string or similar to distinguish a particular
browser. Object or feature detection is using a test to see if a
particular object or feature is supported. It is much more robust and
requires far less maintenance.
Do you like that Prototype's Selector#findElements method uses XPATH
(Firefox) and querySelector/querySelectorAll (WebKit) when available?
Yes, I just don't like the way it goes about deciding which method to
used.
Or do you think this muddles up the codebase with unnecessary
branching?
Not necessarily. Branching can be avoided where it matters (usually
for performance reasons) - the feature test need only be carried out
once and an appropriate method assigned to the identifier that will be
used to call it. e.g.
var someMethod = (function () {
if ( featureTest ) {
return function() { /* function using feature */ };
} else {
return function() { /* alternative function */ };
}
})();
Sometimes you have to wait until the DOM is ready before you can do
the test, or a body element exists, etc. In those cases, bottom-
loading the script helps. Some functions are not called often enough
to make it worthwhile.
(not trying to get into a huge discussion, just curious where you draw the
line)
Browser sniffing can nearly always be avoided, sometimes it takes a
bit of time and effort to work out an appropriate test. I find that
once programmers start sniffing, it's very easy to become lazy and
depend on it when fairly simple alternatives exist.
For example, a little while ago (12 months?) jQuery had 17 browser
sniffs, it now has 30. I haven't counted how many there are in
Prototype.js.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: Getting Text Nodes of Elements
On Oct 12, 10:05 am, kangax [EMAIL PROTECTED] wrote:
On Oct 11, 2:40 pm, RobG [EMAIL PROTECTED] wrote:
On Oct 12, 3:29 am, Justin Perkins [EMAIL PROTECTED] wrote:
On Sat, Oct 11, 2008 at 10:31 AM, RobG [EMAIL PROTECTED] wrote:
Performance is not the issue - fewer lines of code doesn't necessarily
mean faster performance.
Do you differentiate between browser sniffing and object/method sniffing?
As far as I am aware, there is no such thing as object/method
sniffing, it's called object/feature detection. Browser sniffing is
using the user agent string or similar to distinguish a particular
browser. Object or feature detection is using a test to see if a
particular object or feature is supported. It is much more robust and
requires far less maintenance.
Do you like that Prototype's Selector#findElements method uses XPATH
(Firefox) and querySelector/querySelectorAll (WebKit) when available?
Yes, I just don't like the way it goes about deciding which method to
used.
What exactly could be done better? Are you referring to getting rid of
`switch` in favor of forking the returning function?
To be honest, I haven't looked at that particular bit of code in
detail, I was making a general comment. I don't have time to do so
at the moment either, my spare time is taken up with other
interests. :-)
Or do you think this muddles up the codebase with unnecessary
branching?
Not necessarily. Branching can be avoided where it matters (usually
for performance reasons) - the feature test need only be carried out
once and an appropriate method assigned to the identifier that will be
used to call it. e.g.
var someMethod = (function () {
if ( featureTest ) {
return function() { /* function using feature */ };
} else {
return function() { /* alternative function */ };
}
})();
Sometimes you have to wait until the DOM is ready before you can do
the test, or a body element exists, etc. In those cases, bottom-
loading the script helps. Some functions are not called often enough
to make it worthwhile.
Redefining function on first invocation works quite nicely in those
cases.
Yes, that's a good alternative.
(not trying to get into a huge discussion, just curious where you draw
the line)
Browser sniffing can nearly always be avoided, sometimes it takes a
bit of time and effort to work out an appropriate test. I find that
once programmers start sniffing, it's very easy to become lazy and
depend on it when fairly simple alternatives exist.
For example, a little while ago (12 months?) jQuery had 17 browser
sniffs, it now has 30. I haven't counted how many there are in
Prototype.js.
We are slowly getting rid of them where possible.
Good. I can grudgingly accept its use as a temporary crutch, but it
really grates to see it used as a fundamental strategy.
--
Rob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype script.aculo.us group.
To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en
-~--~~~~--~~--~--~---
[Proto-Scripty] Re: How can I get input elements of a div in order of their position?
On Oct 7, 12:22 pm, buda [EMAIL PROTECTED] wrote: Thanks for idea, there is no any way by doing it with prototype.js nativly? Sure, use $A to convert the returned NodeList to an array and use each to iterate over it. As far as I know, Prototype.js doesn't wrap getElementsByTagName - what would be the point? An alternative is to get all the form's controls (form.elements) and iterate over those to find which have the div as a ancestor. Depending on the distribution of other elements in the div, that may be faster but perhaps not noticeably so. You can optimise performance by stopping the filter as soon as you stop getting form controls that have div as an ancestor. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en -~--~~~~--~~--~--~---
[Proto-Scripty] Re: Get value from table cell when table row have checkbox checked
On Sep 12, 12:53 pm, Daniel Lopes [EMAIL PROTECTED] wrote: This not solution when you want use grids... table are not for layout, right use is to display data, layout must be maded in divs. That makes no sense at all. I wasn't suggesting your use of a table is wrong, but that you use the form controls the way they were meant to be used, i.e. in a form. -- Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype script.aculo.us group. To post to this group, send email to prototype-scriptaculous@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-scriptaculous?hl=en -~--~~~~--~~--~--~---
