[Prototype-core] Re: browser and platform info?
Prototype.Browser.IE and the others are booleans, not functions that return booleans. Cheers, Matt On Aug 7, 3:06 am, "Lino Jan Telera" <[EMAIL PROTECTED]> wrote: > For browser u can write (only if you are using prototype 1.5.1) > Prototype.Browser.IE (return true if you are using IE) > Prototype.Browser.Opera(return true if you are using Opera) > Prototype.Browser.WebKit(return true if you are using WebKit) > Prototype.Browser.Gecko(return true if you are using Gecko: Mozilla, > Firefox) > > For OS I don't know, but i think u can't do anything... > > Hope this help you... > Hi > Jan > > On 8/6/07, patrick.face <[EMAIL PROTECTED]> wrote: > > > > > hello > > Does Prototype provide the browser and platform information? I didn't > > see it in the API. I'd like to determine if my users are on the mac > > and if so what browser. > > -- > Lino "Jan" Telera > > Obey your master! > La verità nuoce solo agli incompetenti! > > My home page:http://www.linoproject.net > My Google Group:http://groups.google.com/group/ajax-e-dom-italia/ > My Blog:http://frontiereweb.blogspot.com/ > My ICQ UIN : 81834420 > Jabber : janosh(at)jabber.org > SKYPE : linotelera > --~--~-~--~~~---~--~~ 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] Date prototype functions
What is the feeling on adding functions to Date.prototype? As mentioned
in March (see message at bottom), adding Date.prototype.succ() would
allow some helpful iterating. I would suggest an optional argument to
succ for time period and I also would like to throw out several more
possible methods (below).
- Ken Snyder
// format
var d = new Date().format('%Y-%m-%d'); // 2007-08-17
// create(static)
Date.create('8-17-07').format('%Y-%m-%d'); // 2007-08-17
// add
var d = new Date().add(2, 'month').format('%Y-%m-%d'); // 2007-10-17
// diff
new Date().diff(d, 'month'); // 2
// succ
new Date().succ('year').format('%Y'); // 2008
// isEqual
new Date().isEqual('2007-08-17', 'day'); // true
// isBefore
new Date().isBefore('08-18-2007 7:00pm'); // true
// isAfter
new Date().isAfter('8/16/2007'); // true
// withinRange
new Date().withinRange('8/1/2007', '8-31-07'); // true
// daysInMonth (static)
Date.daysInMonth(2007, 2); // 28
// ISO (static property)
Date.create('8-17-2007').format(Date.ISO); // 2007-08-17 00:00:00
If the team is interested, I could refactor my current implementation
for these functions and submit it as a patch for close review. I
understand users would probably want it lean and light if included at all.
2007-03-10 agrath wrote:
> ...
>
> This is a succ function for the date prototype and could be a worthy
> addition.
>
> Date.prototype.succ = function(){
> return new Date(this.getFullYear(), this.getMonth(), this.getDate()
> +1);
> }
>
> ...
--~--~-~--~~~---~--~~
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: Predefined custom events handled as 'dataavailable' (1.6.0_rc0)
Also is there any validity in the concern that without proper checks the window.onload trigger could happen in the middle of executing the "contentloaded" observers (esp. in IE when you are emulating a "contentloaded" event)? Do you have a way to ensure proper "first in first out order" or event observers executing? (I believe YUI does my having one true observer of an event acting as a proxy for all other observers, storing them in an array and iterating over the array when its triggered) --~--~-~--~~~---~--~~ 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: Predefined custom events handled as 'dataavailable' (1.6.0_rc0)
This is probably the most glaring flaw in RC0: any event types that are not part of the DOM L2 Events spec, but are nonetheless honored by one or more browsers, are handled incorrectly by Prototype as custom events. We've got to figure out a way around this, even if it means we create a whitelist of all known event types to work in modern browsers. The convenience of handling both custom and standard events with the same API shouldn't make it harder to (for instance) skate on the bleeding edge of Web Forms 2. I'll make sure we figure this out before RC1. Cheers, Andrew On Aug 17, 8:12 am, Wiktor Ihárosi <[EMAIL PROTECTED]> wrote: > The new prototype is under heavy test and I find another intresting > bug... > > The modified observe method try to get the name of the passed > eventName by getDOMEventName but this is limited to the well-known > events. Any unknown event will handled as 'dataavailable'. > > This cause problems if you use predefined events, for example using > fantastic repetitionmodel (webforms2 now) implementation by Weston > Ruter which implements new Web Forms 2 events. But the problem is same > if you use Opera9, it has native support for these events. > > Here is an example > page:http://devidens.hu/spacergif/2007/08/17/predefined-custom-events-hand... > > Please check in Opera, and click on the Add Row button. You should see > two alerts, but you will only one. > > Unfortunately I am not good at the event model, so I don't know what > is the reason of the 'dataavailable', but my dirty hack is to return > eventName is condition fail. It works for me. :) > > if (!Event.DOMEvents.include(eventName)) return eventName; > instead of > if (!Event.DOMEvents.include(eventName)) return "dataavailable"; --~--~-~--~~~---~--~~ 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: browser and platform info?
Both would be excellent uses for it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Prototype: Core" group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Predefined custom events handled as 'dataavailable' (1.6.0_rc0)
The new prototype is under heavy test and I find another intresting bug... The modified observe method try to get the name of the passed eventName by getDOMEventName but this is limited to the well-known events. Any unknown event will handled as 'dataavailable'. This cause problems if you use predefined events, for example using fantastic repetitionmodel (webforms2 now) implementation by Weston Ruter which implements new Web Forms 2 events. But the problem is same if you use Opera9, it has native support for these events. Here is an example page: http://devidens.hu/spacergif/2007/08/17/predefined-custom-events-handled-as-dataavailable.html Please check in Opera, and click on the Add Row button. You should see two alerts, but you will only one. Unfortunately I am not good at the event model, so I don't know what is the reason of the 'dataavailable', but my dirty hack is to return eventName is condition fail. It works for me. :) if (!Event.DOMEvents.include(eventName)) return eventName; instead of if (!Event.DOMEvents.include(eventName)) return "dataavailable"; --~--~-~--~~~---~--~~ 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: General global element events and prototype 1.6.0_rc0
On Aug 17, 1:24 pm, "Mislav Marohnić" <[EMAIL PROTECTED]> wrote: > On 8/17/07, Viktor Kojouharov <[EMAIL PROTECTED]> wrote: > > > > > However, there's still the issue of having > > support for global element events, like 'mousewheel', 'mouseenter', > > and 'mouseout', that would work with all elements, and reuse existing > > event names to achieve their function. > > In the old events branch there was support for mousewheel/enter/out. This > was held back until release 1.6.1 in the future. Prototype 1.6.0 has support > for domready. Does the current RC offer any way to add such events? In a similar fashion, does it offer a way for adding aliases for event names? (i.e. domready => contentloaded) --~--~-~--~~~---~--~~ 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: General global element events and prototype 1.6.0_rc0
On 8/17/07, Viktor Kojouharov <[EMAIL PROTECTED]> wrote: > > > However, there's still the issue of having > support for global element events, like 'mousewheel', 'mouseenter', > and 'mouseout', that would work with all elements, and reuse existing > event names to achieve their function. In the old events branch there was support for mousewheel/enter/out. This was held back until release 1.6.1 in the future. Prototype 1.6.0 has support for domready. --~--~-~--~~~---~--~~ 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] General global element events and prototype 1.6.0_rc0
Hello,
Before 1.6, I had a set of functions on top of the Event.observe
family of functions, which dealt with registering callbacks for
events, like this:
signalConnect: function(element, name, observer) {
if (!element || !name || !observer) return;
if (!element.signals) element.signals = {};
if (!element.signals[name])
element.signals[name] = {observers: [], callbacks: []};
if (element.signals[name].observers.indexOf(observer) > -1) return
Event;
var custom = Event.custom[name];
if (custom) {
var real = custom.real;
var callback = custom.callback ?
custom.callback.bindAsEventListener(Event, element) : null;
if (custom.connect) custom.connect.call(Event, element,
observer);
}
element.signals[name].observers.push(observer);
element.signals[name].callbacks.push(callback || observer);
if ((real || name) != 'activate')
Event.observe.call(Event, element, real || name, callback ||
observer);
return Event;
},
I needed that, since I needed to be able to disconnect all handlers
for a particular signal, and then I added generic events for elements,
like mousewheel and mouseenter, much akin to the mootools library.
With the current release candidate, most of my code has been made
obsolete, and I'm trying to reduce it to to point of my functions
calling the prototype ones. However, there's still the issue of having
support for global element events, like 'mousewheel', 'mouseenter',
and 'mouseout', that would work with all elements, and reuse existing
event names to achieve their function. Is there a structure somewhere
in the latest prototype that will let me add those, or can they be
added before the final release?
the custom events were implemented using the following fashion:
custom: {
mouseenter: {
real: 'mouseover',
callback: function(event, element) {
var target = Event.relatedElement(event);
if (target == element || Element.descendantOf(target, element))
return;
Event.emitSignal(element, 'mouseenter', event);
}
},
mouseleave: {
real: 'mouseout',
callback: function(event, element) {
var target = Event.relatedElement(event);
if (target == element || Element.descendantOf(target, element))
return;
Event.emitSignal(element, 'mouseleave', event);
}
},
mousewheel: {
real: (Prototype.Browser.Gecko) ? 'DOMMouseScroll' :
'mousewheel',
callback: function(event, element) {
if (event.detail)
event.scrollDirection = event.detail;
else if (event.wheelDelta)
event.scrollDirection = event.wheelDelta / -40;
Event.emitSignal(element, 'mousewheel', event);
}
},
domready: {
connect: function(element, observer) {
if (window.loaded) {
observer.call(element);
}
if (document.readyState && (Prototype.Browser.WebKit ||
Prototype.Browser.KHTML)) {
window.domreadytimer = setInterval(function() {
if (['loaded', 'complete'].include(document.readyState))
Event.custom.domready._callback(element);
}, 50);
} else if (document.readyState && Prototype.Browser.IE) {
if (!$('iedomready')) {
var src = (window.location.protocol == 'https:') ? '://0' :
'javascript:void(0)';
document.write('');
$('iedomready').onreadystatechange = function() {
if (this.readyState == 'complete')
Event.custom.domready._callback(element);
};
}
} else {
Event.observe(window, 'load',
Event.custom.domready._callback.bind(Event, element));
Event.observe(document, 'DOMContentLoaded',
Event.custom.domready._callback.bind(Event, element));
}
},
_callback: function(element) {
if (window.loaded) return;
window.loaded = true;
clearInterval(window.domreadytimer);
window.domreadytimer = null;
Event.emitSignal(element, 'domready');
}
}
}
they are pretty much a translation from the mootools ones, and are
made to work with prototype (the mousewheel one has a few additions).
--~--~-~--~~~---~--~~
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: Comparing inside Enumerable.include has been changed in 1.6.0_rc0
On 8/17/07, Wiktor Ihárosi <[EMAIL PROTECTED]> wrote: > > > Thank for your quick and exact answer! I will change it in my copy! :) And thank you for the detailed bug report :) --~--~-~--~~~---~--~~ 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: Comparing inside Enumerable.include has been changed in 1.6.0_rc0
Hello Mislav, > JavaScript semantics for #indexOf, this should be corrected. I have whipped > up the following patch:http://pastie.caboo.se/private/j7xeidwpb4jtfflrta Thank for your quick and exact answer! I will change it in my copy! :) Cheers, Wiktor --~--~-~--~~~---~--~~ 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] Error when using Prototype 1.6.0_rc0
Hi Guys, first of all I want to thank all of you for producing such a great framework and so many great new futures for 1.6.0. I couldn't wait to try them out and replaced my prototype 1.5.1 lib with the new 1.6.0rc0. I had to switch some things because I some of my constructs were conflicting with your implementation, but I hope this is all fixed now. But I have one error left in firefox (prototype.js, line 3868): handler.call(event.target, event); The error occures in the function "createWrapper" which is called really often. But only the first run causes this error. Any idea? Greetings Frederic -- Frederic Gaus pgp-key: 93E6903C fingerprint: 0C55 4517 CC1E 5F7F 9059 3535 AB54 D8E8 93E6 903C --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
