+1
On 5/16/07, Michael Stillwell <[EMAIL PROTECTED]> wrote:
>
> I think it would be helpful if the documentation for
> Form.Element.getValue() made it clear that the argument refers to an
> id, not a form value's name. (Actually, come to think of it, would
> there be any issue with changing the
There are rumors of a probable deprecation of $F... So use $
(element).getValue() instead.
-- tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prot
On 5/16/07, Tobie Langel <[EMAIL PROTECTED]> wrote:
>
>
> There are rumors of a probable deprecation of $F... So use $
> (element).getValue() instead.
Those who like $F (like me) will continue to use it even when it's removed -
especially the new $F with setter capabilities in the form branch [*]
> Those who like $F (like me) will continue to use it even when it's removed -
;)
--~--~-~--~~~---~--~~
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@google
On 5/16/07, Jacob Rockowitz <[EMAIL PROTECTED]> wrote:
>
>
> Is Form.Element.setValue going to added to next version of Prototype?
Yes. The implementation and unit tests are in place in the form branch. But,
we only announce things when they land in the trunk.
--~--~-~--~~---
Is Form.Element.setValue going to added to next version of Prototype?
$F('name', value) would be very slick.
It would make sense for a 'getter' to have a corresponding 'setter'.
On May 16, 9:47 am, Tobie Langel <[EMAIL PROTECTED]> wrote:
> > Those who like $F (like me) will continue to use it e
Hey,
Ben Nolan a écrit :
>> I think it would be helpful if the documentation for
>> Form.Element.getValue() made it clear that the argument refers to an
>> id, not a form value's name. (Actually, come to think of it, would
>> there be any issue with changing the behaviour of $F() to more closely