[Prototype-core] $$ function needs context attribute?
In the jQuery the $ function have two attributes the second is
context, and it is very useful, for example:
$(div).each(function(){
$(img,this).hide()
$(.,this).dosomething()
})
And in the Prototype there is also Selector.findChildElements and the
first attribute is the context, and this function is not recommended
for the end users to use, I think is is good to create a new function
called $$$ or something like that to make a short selector function
and supports context.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: $$ function needs context attribute?
On 10/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I think is is good to create a new function called $$$ or something like that to make a short selector function and supports context. We use Element#select to constrain the lookup to a certain element: $(foo).select(img) We discussed adding a context argument to $$ a while ago, but it just didn't turn out worthwhile, I guess. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Unexpected behavior while evaluating a template with an empty replacement
Currently, a template with an empty replacement variable gobbles up
the preceding character:
##{}.interpolate({}) // =
AB#{}.interpolate({}) // = A
Instead, I think the template should evaluate just like it does in
Ruby:
##{} #= #
AB#{} #= AB
A patch in Ticket #9692 fixes this:
http://dev.rubyonrails.org/ticket/9692
Thanks,
Ryan
--~--~-~--~~~---~--~~
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: svn:ignore
+1 for ignoring pkg and dist/*, but keep the dist directory itself. On 10/17/07, Ryan McGeary [EMAIL PROTECTED] wrote: What does the core team thinnk about svn:ignoring pkg and dist/ prototype.js? Clean svn status messages make me happy :-) Ticket #9705 elaborates: http://dev.rubyonrails.org/ticket/9705 Thanks, Ryan --~--~-~--~~~---~--~~ 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] svn:ignore
What does the core team thinnk about svn:ignoring pkg and dist/ prototype.js? Clean svn status messages make me happy :-) Ticket #9705 elaborates: http://dev.rubyonrails.org/ticket/9705 Thanks, Ryan --~--~-~--~~~---~--~~ 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] Hash no longer works with templates/interpolate()
It may never have been intended to use this way, but I've found it quite useful in the past to be able to use hashes as the source for template variables. With the new restriction on accessing properties directly this no longer works. Looking at the code for Template, it looks like it might be as simple as giving Hash a 'toTemplateElements()' method that returns 'this.toObject()' is this worth having in core? Greg --~--~-~--~~~---~--~~ 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: Hash no longer works with templates/interpolate()
On 10/17/07, G Jones [EMAIL PROTECTED] wrote: Looking at the code for Template, it looks like it might be as simple as giving Hash a 'toTemplateElements()' method that returns 'this.toObject()' http://dev.rubyonrails.org/ticket/9903 I'm torn between teaching Hash to respond to toTemplateElements or teaching Template to try toObject after toTemplateElements is unavailable. What do you guys think? --~--~-~--~~~---~--~~ 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 Pagination
On 10/15/07, Matt Foster [EMAIL PROTECTED] wrote: I have developed a pretty smooth UI Control for handling client side pagination. It is composed of 3 classes that allow for maximum decoupling. In this manner the view is decoupled from the iteration control, such that the same iteration control can be used on any data set while the view can be specialized for any format of JSON or XML. I'm not sure if such announcements are suitable for this group. (Someone correct me if I'm wrong when stating it isn't.) That said: Interesting work. I handle pagination server-side myself (using the will_paginate plugin for Rails), but I definitely see use cases when you have to move this logic client-side. --~--~-~--~~~---~--~~ 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: Hash no longer works with templates/interpolate()
Mislav Marohnić a écrit : I'm torn between teaching Hash to respond to toTemplateElements or teaching Template to try toObject after toTemplateElements is unavailable. What do you guys think? The second version seems totally overreaching. If we do that AT ALL, I'd favor: Hash.prototype.toTemplateElements = Hash.prototype.toObject; This being said, I don't think there's a massive reason to add this orthogonal feature to Hash: people who want to use an actual Hash as a source object to a template should pass myHash.toObject() instead of just myHash... -- Christophe Porteneuve aka TDD [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: Hash no longer works with templates/interpolate()
On 10/17/07, Christophe Porteneuve [EMAIL PROTECTED] wrote: This being said, I don't think there's a massive reason to add this orthogonal feature to Hash: people who want to use an actual Hash as a source object to a template should pass myHash.toObject() instead of just myHash... Surely you don't mean this. Why couldn't I be able to write: template.evaluate(myData) ... regardless of whether myData is Object, Hash or some class instance that responds to toTemplateElements? --~--~-~--~~~---~--~~ 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: Hash no longer works with templates/interpolate()
... people who want to use an actual Hash as a source object to a template should pass myHash.toObject() instead of just myHash... I tend to disagree. I think requiring myHash.toObject() violates the POLS. Otherwise, why does Template#evaluate even try calling toTemplateReplacements at all? -Ryan --~--~-~--~~~---~--~~ 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: Hash no longer works with templates/interpolate()
We can stop arguing now. Sam has already fixed it in trunk: http://dev.rubyonrails.org/changeset/7955 :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Prototype: Core group. To post to this group, send email to prototype-core@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: $$ function needs context attribute?
Oh, the select method, I haven't use it, and the context is
important for the css selector, and in the case
Selector.findChildElements supports the context, So only change the $
$ function and to check whether the last argument is HTML element or
not is enough. And context is really very important for css selector,
it make the selector much more flexible.especially in the
$$().each(function(node){
$$(,node).doSomething()
})
On Oct 17, 6:43 pm, Mislav Marohni [EMAIL PROTECTED]
wrote:
On 10/17/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I think is is good to create a new function
called $$$ or something like that to make a short selector function
and supports context.
We use Element#select to constrain the lookup to a certain element:
$(foo).select(img)
We discussed adding a context argument to $$ a while ago, but it just didn't
turn out worthwhile, I guess.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Prototype: Core group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] combinator selectors in Element#select
I recently stumbled upon a href=http://dev.rubyonrails.org/ticket/
9465this ticket/a
In a nutshell, element.select(' foo') does not return the correct
result while element.select('foo') does.
I understand that combinator selector should be defined between two
simple ones (so it's not quite a valid expression), but the question
is do we want to allow this kind of thing? Is it an edge case? Should
we make this work or just fall back to an alternative way?
i.e. element.childElements().map(function(el){ return
el.match('foo') })
Best,
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: combinator selectors in Element#select
Please make it to be simple, look at the source code:
select: function() {
var args = $A(arguments), element = $(args.shift());
return Selector.findChildElements(element, args);
},
the select method is only a wrapper of the
Selector.findChildElements, and with different selector context. For
the css selecting rule as same with the css with $$, make it to be
complex is not a good idea.
On Oct 17, 10:47 pm, kangax [EMAIL PROTECTED] wrote:
I recently stumbled upon a href=http://dev.rubyonrails.org/ticket/
9465this ticket/a
In a nutshell, element.select(' foo') does not return the correct
result while element.select('foo') does.
I understand that combinator selector should be defined between two
simple ones (so it's not quite a valid expression), but the question
is do we want to allow this kind of thing? Is it an edge case? Should
we make this work or just fall back to an alternative way?
i.e. element.childElements().map(function(el){ return
el.match('foo') })
Best,
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] setOpacity error
I just discovered that if you call setOpacity in IE on an element that
was just created (and so hasn't been added to the DOM yet), an exception
will be thrown. It looks like the currentStyle object on the element is
not set until after it has been attached to the DOM. An example script is:
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
http://www.w3.org/TR/html4/loose.dtd;
html
head
script type=text/javascript src=prototype.js/script
script type=text/javascript
function test() {
var div = new Element('div');
div.setStyle({
background: 'blue',
opacity: .5
});
div.update('This Worked');
document.body.appendChild(div);
}
/script
/head
body
input type=button onclick=test() value=Click Me! /
/body
/html
I filled a bug #9904 on it. This affects 1.6rc0 and since there was no
changes to this part of the code for 1.6rc1, I believe it affects that
as well.
Trevan
--~--~-~--~~~---~--~~
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: combinator selectors in Element#select
On 10/17/07, kangax [EMAIL PROTECTED] wrote:
In a nutshell, element.select(' foo') does not return the correct
result
+1 for fixing it, regardless of the fact it may not be a valid selector ...
it's a valid fragment of a selector.
I want to be able to select immediate descendants this way. Do others feel
the same?
--~--~-~--~~~---~--~~
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] isLeftClick Bug in Proto 1.6.0 RC1
Today I updated to Prototype 1.6.0 RC1 from RC0. I am also using Scriptaculous 1.8 preview. Beyond changing my contentloaded to dom:loaded the transition seemed to go fairly smoothly. Until I encountered the following error in IE (6 and 7): Drags created with new Draggable(...) no longer drag. I traced this back to prototype's isLeftClick always returning false. Looks like isLeftClick was significantly changed just yesterday: http://dev.rubyonrails.org/changeset/7926 -B --~--~-~--~~~---~--~~ 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: isLeftClick Bug in Proto 1.6.0 RC1
On 10/17/07, Bart Lewis [EMAIL PROTECTED] wrote: Looks like isLeftClick was significantly changed just yesterday: http://dev.rubyonrails.org/changeset/7926 ... and it was fixed today: http://dev.rubyonrails.org/changeset/7954 Thanks for reporting, though. Everyone who has troubles with this should upgrade to latest trunk. --~--~-~--~~~---~--~~ 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: combinator selectors in Element#select
I'm not crazy about it. Deviations from the CSS3 spec are troublesome
because they're not discoverable and they violate POLS. If we're going
to go down that slippery slope, selector.js will get even larger than
it already has.
The extended Enumerable#grep semantics in 1.6 make kangax's
alternative code shorter:
var matches = element.childElements().grep(new Selector('.foo'));
Anything that has a match method can now be used as a filter.
Cheers,
Andrew
On Oct 17, 10:17 am, Mislav Marohnić [EMAIL PROTECTED]
wrote:
On 10/17/07, kangax [EMAIL PROTECTED] wrote:
In a nutshell, element.select(' foo') does not return the correct
result
+1 for fixing it, regardless of the fact it may not be a valid selector ...
it's a valid fragment of a selector.
I want to be able to select immediate descendants this way. Do others feel
the same?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
