[Prototype-core] Re: Border Radius
This is nice as a basic-level script to apply border-radius on
browsers that support it. That said, it's missing a couple things:
Webkit (and/or Opera?) supports two radius arguments for each corner,
which allows the corner to be morphed into a more oval shape. To my
knowledge, Firefox doesn't support that yet.
http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radius
Since the function doesn't provide a cross-browser solution for IE,
and doesn't fully support what each of the other browsers can do, my
guess is this will have a hard time getting into the Core. But that
doesn't detract from its usefulness as a quick utility function.
Maybe the devs have some ideas for broadening the capabilities for it,
though.
-joe t.
On Aug 12, 8:51 pm, Rafael Raposo orapo...@gmail.com wrote:
Hello,
I don't know what you think about border radius right now, but as it is not
totally cross plataform yet, I managed to create a function to set it almost
cross plataform, BUT, not in IE htc file hell stuff.
(function() {
var borderRadius = {
_all: $w(borderRadius MozBorderRadius webkitBorderRadius),
topLeft: $w(borderTopLeftRadius MozBorderRadiusTopleft
webkitBorderTopLeftRadius),
bottomLeft: $w(borderBottomLeftRadius MozBorderRadiusBottomleft
webkitBorderBottomLeftRadius),
topRight: $w(borderTopRightRadius MozBorderRadiusTopright
webkitBorderTopRightRadius),
bottomRight: $w(borderBottomRightRadius MozBorderRadiusBottomright
webkitBorderBottomRightRadius)
};
function setBorderRadius(element, borders) {
var realBorders = {};
if(Object.isString(borders)) {
borders = {_all:borders};
}
for(var border in borders) {
borderRadius[border].each(function(borderTranslate){
realBorders[borderTranslate] = borders[border];
});
}
element.setStyle(realBorders);
return element;
}
Element.addMethods({
setBorderRadius: setBorderRadius
});
})();
It accepts arguments like:
$(id_element).setBorderRadius(30px);
$(id_element).setBorderRadius({topLeft:30px, bottomRight:30px});
In fact I may not be aware of how to deal with rounded borders for the
present state, but this function just helped me a little so it may help some
of you.
Cheers
Rafael
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Border Radius
http://ie.microsoft.com/testdrive/HTML5/01BorderRadius/Default.html
Looks like IE9 will at least partially support border-radius. But by
that demo (designed for the IE9 preview), it looks like it'll only
support the single radius dimension per corner. i guess that's
something to look forward to. /shrug
-joe t.
On Aug 13, 1:09 pm, Rafael Raposo orapo...@gmail.com wrote:
Yes, unfortunately I know it can't go into the core as it does not support
IE.
But, the two value radius is accepted by this function of mine. I just
didn't know it existed =).
If you call $(id_elemente).setBorderRadius(20px 40px) on Chrome, it will
display its oval shape.
Thanks for the info though. At least I know it also works for borders like
that.
It would be great if this could be applied to IE, but don't think it will
ever happen until they accept the border-radius css attribute. At least, for
what I'm doing I can forget about IE users, as the rounded borders are just
a fancy-non-functional looking thing, as almost every rounded border is, I
think, hehe. That's why I posted it here.
On Fri, Aug 13, 2010 at 09:55, joe t. thooke...@gmail.com wrote:
This is nice as a basic-level script to apply border-radius on
browsers that support it. That said, it's missing a couple things:
Webkit (and/or Opera?) supports two radius arguments for each corner,
which allows the corner to be morphed into a more oval shape. To my
knowledge, Firefox doesn't support that yet.
http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radius
Since the function doesn't provide a cross-browser solution for IE,
and doesn't fully support what each of the other browsers can do, my
guess is this will have a hard time getting into the Core. But that
doesn't detract from its usefulness as a quick utility function.
Maybe the devs have some ideas for broadening the capabilities for it,
though.
-joe t.
On Aug 12, 8:51 pm, Rafael Raposo orapo...@gmail.com wrote:
Hello,
I don't know what you think about border radius right now, but as it is
not
totally cross plataform yet, I managed to create a function to set it
almost
cross plataform, BUT, not in IE htc file hell stuff.
(function() {
var borderRadius = {
_all: $w(borderRadius MozBorderRadius
webkitBorderRadius),
topLeft: $w(borderTopLeftRadius MozBorderRadiusTopleft
webkitBorderTopLeftRadius),
bottomLeft: $w(borderBottomLeftRadius MozBorderRadiusBottomleft
webkitBorderBottomLeftRadius),
topRight: $w(borderTopRightRadius MozBorderRadiusTopright
webkitBorderTopRightRadius),
bottomRight: $w(borderBottomRightRadius
MozBorderRadiusBottomright
webkitBorderBottomRightRadius)
};
function setBorderRadius(element, borders) {
var realBorders = {};
if(Object.isString(borders)) {
borders = {_all:borders};
}
for(var border in borders) {
borderRadius[border].each(function(borderTranslate){
realBorders[borderTranslate] = borders[border];
});
}
element.setStyle(realBorders);
return element;
}
Element.addMethods({
setBorderRadius: setBorderRadius
});
})();
It accepts arguments like:
$(id_element).setBorderRadius(30px);
$(id_element).setBorderRadius({topLeft:30px, bottomRight:30px});
In fact I may not be aware of how to deal with rounded borders for the
present state, but this function just helped me a little so it may help
some
of you.
Cheers
Rafael
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
--
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Why are all children of an 'update'd element being purged?
Thanks for the clarification. Most methods that change content destroy the old content in favor of the new. The same is true for #replace suggested above. If you need to retain content while putting new content in its place, you may need a deep-clone method (which i've requested in the past and someone provided a possibility as an extension, but i couldn't get it to work). A search on this group for deep clone brings up a thread with a similar method and suggestions of additional arguments to control the amount of storage that gets copied. Another alternative could be to move the containers you need to preserve to some other, hidden, parent container before placing the new content. Sorry i wasn't more helpful. i'm a little rusty of late, being pressed for more C# development than web work lately. i hope one of the big- brains here can take a look and offer something for you. -joe t. On Jul 3, 6:00 am, Viktor Kojouharov vkojouha...@gmail.com wrote: I understand that. And I was using update to clear the container and add a new element. My problem was, I have a reference to the previous element of the container that was just cleared, and I am saving that reference of the element with the intention of replacing the new container content with that element at some future time. Right now I'm using innerHTML = '', since using Element#update would wipe out the storage of the element I have a reference to, and that is highly undesirable. On Jul 2, 3:16 pm, joe t. thooke...@gmail.com wrote: Most people interpret it to mean update with new content. Think along the lines of a page refresh for just that element: wipe out the existing content, update with new. Some others like yourself expect it to mean append with new content. That approach is handled by Element#insert: preserve existing content, place new content at the desired Position (usually appended, but insertion options are available). http://api.prototypejs.org/dom/element/insert/ This same question came up some months ago. Hopefully that clarification helps. -joe t. On Jul 2, 5:24 am, Viktor Kojouharov vkojouha...@gmail.com wrote: This behaviour is a bit unexpected, and caused some debugging time to figure out why some elements were losing their storage. Why isn't this only done during page unload? -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Why are all children of an 'update'd element being purged?
Most people interpret it to mean update with new content. Think along the lines of a page refresh for just that element: wipe out the existing content, update with new. Some others like yourself expect it to mean append with new content. That approach is handled by Element#insert: preserve existing content, place new content at the desired Position (usually appended, but insertion options are available). http://api.prototypejs.org/dom/element/insert/ This same question came up some months ago. Hopefully that clarification helps. -joe t. On Jul 2, 5:24 am, Viktor Kojouharov vkojouha...@gmail.com wrote: This behaviour is a bit unexpected, and caused some debugging time to figure out why some elements were losing their storage. Why isn't this only done during page unload? -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en
[Prototype-core] Re: Kudos to the documentation team
Agreed, and it appears to be specific to Firefox. However, i can't recall any other circumstances (iframe, CSS overflow, etc) where the scroll bar behaves differently. The new API page is the only time i've seen this behavior. Peculiar. Oh well, it's hardly the end of the world. :) -joe t. On Apr 6, 8:31 am, Mislav Marohnić mislav.maroh...@gmail.com wrote: The scroll bar is native to the browser, meaning it's the same as in a regular window, iframe or frameset. The navigation panel should scroll with same methods and speed as every window in your browser.On Tue, Apr 6, 2010 at 14:15, joe t. thooke...@gmail.com wrote: +1 for the scrolling. The navigation between documentation links has much improved, but the navigation panel still has issues. The wheel- scroll is painfully slow. Even clicking in the scroll bar doesn't work as expected. When you click a position in the scroll bar, usually it jumps to where you clicked. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] Re: Kudos to the documentation team
+1 for the scrolling. The navigation between documentation links has much improved, but the navigation panel still has issues. The wheel- scroll is painfully slow. Even clicking in the scroll bar doesn't work as expected. When you click a position in the scroll bar, usually it jumps to where you clicked. Otherwise, the documentation itself is phenomenal, and thanks to all! -joe t. On Apr 5, 5:19 pm, Joost joost.van.do...@gmail.com wrote: I have the same problem, because I like to use google to search for stuff in the documentation but I end up on the old one. Also I think the mouse wheel scrolling in the menu onhttp://api.prototypejs.orgis way too slow and should be fixed (it takes 10 seconds for me to scroll down with the mouse wheel..). Good work on the improved docs though. -- You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en To unsubscribe, reply using remove me as the subject.
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...])
Tobie,
Function.prototype.repeat = function(interval) {
var fn = this;
if (arguments.length 1) {
// not testsed but you get the idea
fn = fn.curry.apply(fn, Array.prototype.slice.call(arguments, 1));
}
return new PeriodicalExecuter(fn, interval);
}
If sticking to the PE approach there's no internal self-stop mechanism
(is there?), which i see as a nice touch in the above proposal (for
what my opinion is worth).
What about (from 1.6.1_rc2):
onTimerEvent: function() {
if (!this.currentlyExecuting) {
try {
this.currentlyExecuting = true;
if (this.execute()===false) // MOD
this.stop(); // NEW
} catch(e) {
/* empty catch for clients that don't support try/finally */
}
finally {
this.currentlyExecuting = false;
}
}
}
Just tossing in my 2 cents because i'm intrigued by that feature.
-joe t.
On Jun 26, 6:02 am, Tobie Langel tobie.lan...@gmail.com wrote:
How to stop it? arguments?
Stopping it is as easy as:
pe = foo.repeat();
pe.stop();
Passing arguments would require some simple currying:
Function.prototype.repeat = function(interval) {
var fn = this;
if (arguments.length 1) {
// not testsed but you get the idea
fn = fn.curry.apply(fn, Array.prototype.slice.call(arguments, 1));
}
return new PeriodicalExecuter(fn, interval);
}
This may come to you twice, but this is slightly updated:
http://jsbin.com/opimu
This repeat() method def is 775Bytes, accepts arguments like delay/defer,
uses setTimeout (returns initial setTimeout index) and has a stopping
mechanism.
What's the point in returning setTimeout index? That will set
expectations which can't be met: developers will expect to be able to
stop the functions calls by clearing it.
Are you sure your proposal fixes all of the small issues PE fixes? For
example, does it guarantee that the function will continue being
called if it happens to once throw an error. Does it avoid calling the
function again if a previous function is still executing, etc.?
I understand your eagerness to move away from a model you dislike, but
that shouldn't make you throw away all of the work that's been put
into previous solutions.
FWIW, I just noticed a patch wasn't applied to PE in current trunk
(it's missing a throw statement).
Best,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Suggested addition to Function Methods: .repeat(seconds[, arg...]) -- Revised from Robert's version
Rick,
Maybe i'm missing how that revision works, but it appears to me that
your stop property doesn't actually stop the repeater. Your stop
returns before further execution happens, but the timeout ID for the
window still exists.
What am i missing?
-joe t.
On Jun 24, 12:20 pm, Rick Waldron waldron.r...@gmail.com wrote:
I made a few modifications to your version, allowing repeat() to behave like
delay() with regard to arguments
I've posted a demo here:
http://jsbin.com/ekone
All the output is to the firebug console... i've included fbug lite just in
case
Rick
On Wed, Jun 24, 2009 at 10:50 AM, Rick Waldron waldron.r...@gmail.comwrote:
I've subbed my implementation with your to do some use-case testing. I'll
report back anything of interest as I go along.
Rick
On Wed, Jun 24, 2009 at 10:49 AM, Rick Waldron
waldron.r...@gmail.comwrote:
This is fantastic feedback - thanks!
On Wed, Jun 24, 2009 at 9:55 AM, Robert Kieffer bro...@gmail.com wrote:
I can't say I'm a big fan of this. For several reasons.
First, it's just a cosmetic replacement for setInterval(myfunction
(...).bind(), ...) which simply isn't all that bad.
Second, I'm not a fan of setInterval in general. I've seen some
rather nasty behavior with calls queuing up if the invoked function
takes longer than the delay to execute. In particular, this seems to
be an issue if you do something like put a laptop to sleep. (But
maybe others haven't seen this problem???) Thus, I prefer to use a
self-invoking timeout like so:
function myFunction() {
// do stuff ...
// call ourselves again
if (/*we want to continue?*/) setTimeout(myFunction, 1000)
}
This doesn't call the function at exactly one second intervals, but
that type of accuracy is rarely important. Instead, it guarantees you
have at least one second of delay between invocations, which for
distributing cpu load or polling (the more common cases where
setInterval might be used), is more desireable.
Finally, as Joe T. points out, there should be a way of cancelling the
interval that doesn't require the user to store the returned value
(*that* is what I find most annoying, not the syntax of
setInterval).
Thus, I'd suggest this instead:
Object.extend(Function.prototype, {
repeat: function(delay) {
// Reset state
if (this._repeater) delete this._repeater;
this._repeatTimeout = clearTimeout(this._repeatTimeout);
if (!delay) return; // (stop repeating if no args or delay==0)
// Create setTimeout-based invoker
var _method = this;
if (!this._repeater) this._repeater = function() {
// Let _method cancel repeat by doing return false;
if (_method() !== false) setTimeout(_method._repeater, delay);
}
// Start repeating
this._repeatTimeout = setTimeout(this._repeater, delay);
},
stopRepeating: function() {
this.repeat();
}
});
For example:
var count = 0;
function foo() {
console.log(count++);
return count 10; // Return false when count = 10 to cancel
the repeat
}
// Start repeating 1/sec
foo.repeat(1000);
//... some time later change interval to 2/sec
foo.repeat(500);
// ... later still stop repeating.
foo.stopRepeating();
As you can see, this implementation of repeat() does a lot more for
you than simply alias'ing setInterval:
- It guarantees your function is only invoked by one interval
- It makes changing the interval or cancelling it altogether
trivial.
- It allows you to conditionally cancel the repeat from w/in the
function itself.
The only thing missing is the bind() behavior but, well, that's what
bind is for. If you need to bind arguments, just bind() your
arguments first.
On Jun 23, 8:25 am, Rick Waldron waldron.r...@gmail.com wrote:
I detest the way setInterval() looks, so I came up with this... have
been
using it my personal JS for some time.
Object.extend(Function.prototype, {
repeat: function() {
var __method = this, args = $A(arguments), interval = args.shift()
*
1000;
return window.setInterval(function() {
return __method.apply(__method, args);
}, interval );
}
});
// usage:
var _pollInt = 0;
function repetiousPollFn() {
console.log(_pollInt++);
}
repetiousPollFn.repeat(.5);
Will, of course, repeat repetiousPollFn() every half second.
Almost identical to .delay(), except that it returns setInterval
instead of
setTimeout. One thing I intend to add is support for clearInterval,
however
I figured I'd at least bring it up here first. I've never
proposed/contributed here before (i'm a lurker of the list :D ) - any
guidance is appreciated.
Rick
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group
[Prototype-core] Re: Form#request ...request
On Feb 13, 8:08 am, Tobie Langel tobie.lan...@gmail.com wrote: i know that #writeAttribute isn't 100% reliable, which was part of the reason why i was looking for an alternative to it. How so? Ahhh, you got me there. i guess that wasn't a good phrasing. It should read more like i've seen vague anecdotal reports that #writeAttribute isn't 100% reliable because of variations in browser attribute writing, but have not personally seen evidence of it in my own experience or others'. Such is how religions begin, eh? That said, i still wanted an alternative to having to make two function calls to serve the purpose of one. Even in the proposed solution above, #writeAttribute is still used each time, i just don't have to manually make that call to it. And i see Mislav's point in not butchering #request by naming it something else. However, since original idea (modifying the original #request to accept a url option) is still the only one that allows me to dynamically point #request at whatever server-script i want without an additional method call, i still wonder IF it's problematic to do so. Even if i used Ajax.Request and #serialize, it's still one task for the price of two calls. It was just a hypothetical, i'm not trying to twist anyone's arms off over it. :) -joe t. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Form#request ...request
On Feb 12, 9:25 am, Mislav Marohnić mislav.maroh...@gmail.com wrote: On Wed, Feb 4, 2009 at 23:08, joe t. thooke...@gmail.com wrote: i've had an ongoing need to make Form#request less dependent on the FORM's action attribute. The sole purpose of Form#request is to wrap an Ajax.Request call to make it use the form's action and method attributes. In short, it completely simulates (with the exception of file uploads) the way a web browser would serialize and submit a form. If you find yourself wanting another action URL or HTTP method, you definitely *don't want* to use Form#request. A much better solution is manually using Ajax.Request + Form#serialize (as you already mentioned). I strongly advise against the writeAttribute hack. Form#request was designed to support unobtrusive scripting by hijacking form submits; and by using this hack you're defying the purpose of Form#request as well as making your scripts obtrusive (by changing the action attribute unnecessarily). You are encouraged to use Element.addMethods to add a new method like Form#requestWithAction(url, options). Thank you for the perspective Mislav. i know that #writeAttribute isn't 100% reliable, which was part of the reason why i was looking for an alternative to it. i'll do some more thinking about my approach. Thanks again for the insight. -joe --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Had a lightbulb moment.
Oh good god, how did i miss that???
Thanks for that!
-joe t.
On Jan 14, 10:50 am, Richard Quadling rquadl...@googlemail.com
wrote:
Hi.
I've just reduced a fairly long winded each() loop to ...
var i_LargestLabel = $$(s_CSS).invoke('getWidth').max();
So, this is just a thank you to all you developers.
You all make me look really good!
Thank you.
Richard.
--
-
Richard Quadling
Zend Certified Engineer :http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Safe Object.extend?
Yeah, good point. i thought specifying the boolean might be more
reliable, but it doesn't hurt to leave it out.
-joe t.
On Jan 9, 8:05 am, evolutional t.ziegelbec...@gmail.com wrote:
another thing...
I recently used the Object.extend for the default options of a
class.
So I just thought would it not be simpler to use an attributes' order
like this: Object.extend(from, to ) or Object.extend(source,
destination)
instead of Object.extend(destination, source). I mean it is just a
matter of conversion but I would rather prefer the logically order
from - to.
regards Tom
On 8 Jan., 22:22, kangax kan...@gmail.com wrote:
On Jan 7, 9:45 am, joe t. thooke...@gmail.com wrote:
How would the core feel about a safe version of Object.extend?
Object.extend = function(destination, source, safe) {
safe = !!safe || false;
You don't really need this conversion - `` (the one that's in the
loop) already does it implicitly.
[...]
--
kangax
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Safe Object.extend?
How would the core feel about a safe version of Object.extend?
Object.extend = function(destination, source, safe) {
safe = !!safe || false;
for (var property in source){
destination[property] = (safe typeof destination[property] !==
'undefined') ?
destination[property] : source[property];
}
return destination;
};
Existing functionality is covered (safe defaults false, which goes to
source[property], no need to change anything.
i found a recent need to extend a class object after it had been
created, but i didn't want to overwrite properties if they'd already
been defined. i imagine there would be some minimal performance hit
testing each property if safe==true, but otherwise...? Any visible
problems?
Just a suggestion, it helped me out.
-joe t.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: working in firefox, not in IE7...big surprise
On Dec 4, 7:07 pm, jsnoob80 [EMAIL PROTECTED] wrote:
Can anyone help me debug this?
http://www.promoventures.com/clients/indexNEW.php
1: As noted in the previous reply, your {insertion: Insertion.Top} is
a deprecated notation. Unfortunately, some of the Prototype API docs
examples aren't updated, but in the description of passable options at
http://www.prototypejs.org/api/ajax/updater it does mention that as of
1.6, you can simply use {insert:'top'}
2. You're passing the insertion as a separate argument:
83 new Ajax.Updater(
84 'case_ajax',
85 'show-main.ajax.php?auto=' + auto,
86 {
87 asynchronous:true,
88 evalScripts:true,
89 // onComplete:function(request){Effect.SlideDown('case_ajax',
{ duration: 1.7 });}
90 },
91 {insertion: Insertion.Top}
92
93 )
Options argument starts at 86 and ends at 90. Line 91, the insertion,
should be passed inside the Options object. Though i'm not entirely
sure why Firefox is forgiving this and supposedly obeying the Top
insertion, it's probably why IE isn't.
On that note, what exactly is going wrong? Looking at the page in FF
and IE8b2 (normal and compatibility modes), there don't seem to be any
display issues, and no JS errors.
-joe t.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Prototype in 10 steps... what are they?
On Nov 18, 5:11 am, T.J. Crowder [EMAIL PROTECTED] wrote: ... 1. Master the $ and $$ Functions 2. Use instance methods to perform common tasks on elements 3. Master event observing (including delegation) 4. Push the envelope with Ajax 5. Use Enumerable to manage collections 6. Master binding 7. Treat functions like first-class objects 8. Really understand closures 9. Write class-based JavaScript 10. Have your mind blown by custom events ... No reason a list of ten can't be broken into two parts, as you suggest. Prototype in 10 Steps Basics: 1-5 Advanced: 1-5 (comprised of 6-10) That kind of organization would have definitely come in very handy when i first played with Prototype. Hell, i ended up rewriting hundreds of lines of code when i finally grasped Function.bind(). My next effort is understanding event delegation. i guess i like learning in reverse. -joe t. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Form.reset() (still) not returning Element
That's kinda odd. i've tried the code i suggested above with no
problems. i guess there could be potential problems with it, but i
didn't see any specific problems with particular browsers described.
For now i'll stick to what i've got and wait for the official fix in
a later version.
-joe t.
On Nov 1, 6:28 am, T.J. Crowder [EMAIL PROTECTED] wrote:
Hi,
This is on the buglist; actually there's more to it,
apparently:http://prototype.lighthouseapp.com/projects/8886-prototype/tickets/309
--
T.J. Crowder
tj / crowder software / com
On Nov 1, 2:45 am, joe t. [EMAIL PROTECTED] wrote:
i don't know if this is intentional, or if no one's noticed it, or
what, but in the last two releases, i've had to add a fix to
Form.reset():
-- 1.6.0.2/3:
var Form = {
reset: function(form) {
$(form).reset();
return form;
},
-- My fix:
var Form = {
reset: function(form) {
form = $(form)
form.reset();
return form;
},
Since reset is a native method not returning anything, you obviously
can't chain it on the return line, but it didn't make much sense to me
why the form element isn't $()'d first.
i personally have several forms where i want to highlight the first
element after resetting the form, so i use
Form.reset('formid').focusFirstElement().
-joe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Form.reset() (still) not returning Element
i don't know if this is intentional, or if no one's noticed it, or
what, but in the last two releases, i've had to add a fix to
Form.reset():
-- 1.6.0.2/3:
var Form = {
reset: function(form) {
$(form).reset();
return form;
},
-- My fix:
var Form = {
reset: function(form) {
form = $(form)
form.reset();
return form;
},
Since reset is a native method not returning anything, you obviously
can't chain it on the return line, but it didn't make much sense to me
why the form element isn't $()'d first.
i personally have several forms where i want to highlight the first
element after resetting the form, so i use
Form.reset('formid').focusFirstElement().
-joe
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
