#95 ✓not_for_core
Fabien Ménager

$V, like $F but works with control groups

Reported by Fabien Ménager | May 13th, 2008 @ 12:24 PM

Hello, I've developed a new function using Prototype for an Open Source project that I think might be useful. It consists in a function like $F but that can be used with groups of radio buttons, and all kind of form elements without the need to know if it's a list of elements or a single one.

I've attached the file containing this function. Even if I've already tested it, and that we use it, I would like to know if you encounter any issue with it.

Comments and changes to this ticket

  • John-David Dalton

    John-David Dalton May 13th, 2008 @ 04:51 PM

    • State changed from “new” to “enhancement”
  • Tobie Langel

    Tobie Langel May 13th, 2008 @ 05:16 PM

    We're typically trying to reduce the number of utility methods in use in Prototype

    I'd advocate somehow rethinking that API.

  • John-David Dalton

    John-David Dalton May 13th, 2008 @ 05:27 PM

    When Prototype serializes the form it finds the radio button/checkbox in the group that has a checked value.

    I guess one could modify the $F() to accept a nodeList or array of elements to get the checked elements value.

    or

      var group = [element1, element2, element3],
      value = group.findAll(function(element)  return $(element).name == group[0].name })
        .detect(function(element) { return element.checked }).getValue();
    
  • John-David Dalton

    John-David Dalton May 13th, 2008 @ 05:28 PM

    • Title changed from “A higher level form element get/set : $V” to “$V, like $F but works with control groups”
  • Fabien Ménager

    Fabien Ménager May 13th, 2008 @ 05:29 PM

    • Title changed from “$V, like $F but works with control groups” to “A higher level form element get/set : $V”

    In fact I named it $V to be able to continue using $F and getValue() that are used widely in our project. $F could be improved to be able to do all that my function can do (maybe by getting inspiration from $V) and to throw onchange events too (like mine)

  • Fabien Ménager

    Fabien Ménager May 13th, 2008 @ 05:30 PM

    • Title changed from “A higher level form element get/set : $V” to “$V, like $F but works with control groups”
  • Tobie Langel

    Tobie Langel November 22nd, 2008 @ 05:22 PM

    • State changed from “enhancement” to “inactive”
    • Tag set to form, forms, function, needs_tests

    Closing this ticket as inactive.

    Please reopen it with a firm API proposal (coded, documented and tested). Thank you.

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 02:01 AM

    • Tag changed from form, forms, function, needs_tests to forms, function, needs_tests, section:dom

    [not-tagged:"form" tagged:"section:dom" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 02:07 AM

    • Tag changed from forms, function, needs_tests, section:dom to forms, needs_tests, section:dom, section:lang

    [not-tagged:"function" tagged:"section:lang" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 02:13 AM

    • Tag changed from forms, needs_tests, section:dom, section:lang to needs_tests, section:dom, section:lang

    [not-tagged:"forms" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 02:26 AM

    • Tag changed from needs_tests, section:dom, section:lang to missing:tests, section:dom, section:lang

    [not-tagged:"needs_tests" tagged:"missing:tests" bulk edit command]

  • Tobie Langel

    Tobie Langel July 24th, 2009 @ 03:36 AM

    • Tag changed from missing:tests, section:dom, section:lang to needs:tests, section:dom, section:lang

    [not-tagged:"missing:tests" tagged:"needs:tests" bulk edit command]

  • apinstein

    apinstein April 2nd, 2010 @ 08:45 PM

    I ran into the need for a $F() that works on groups as well, and found this ticket when I went looking for a way to contribute it.

    I am happy to code up a patch, but before I do that, I am curious about Tobie's statement:

    We're typically trying to reduce the number of utility methods in use in Prototype

    The originally attached function does seem to have tons of functionality; however I think it's not analogous to $F due to the "utility" provided by the event handlers as well. Is that what you meant by trying to reduce that functionality?

    What about if we made an $FG() for "Field Value of Groups" that works on checkboxes and radios, and is essentially this:

    $FG = function(groupName) { return $F($$('input[name='+groupName']').select(function(el) { return el.checked; }).first()); };

    Would something like that be considered lightweight enough to include?

    I was looking through the recent note for 1.7RC1 about supporting radio/checkbox in Form.Element#setValue, so maybe 1.7 is a good time to add support for a getter as well.

    Looking forward to your response.

  • Tobie Langel

    Tobie Langel April 3rd, 2010 @ 01:04 AM

    • State changed from “inactive” to “not_for_core”

    Thanks for your comment apinstein. As I mentioned previously, we're trying to reduce the number of utility functions, not add more.

    Though I believe some parts of the way we handle forms deserves improvements, adding more utilities isn't the way we'd like to go about it.

    Thanks for your understanding.

  • apinstein

    apinstein April 3rd, 2010 @ 03:44 AM

    Thanks for the quick response.

    I respect your decision to mark it "not_for_core", after all it's your project, but I have some questions:

    1) A cursory search turned up no Prototype roadmap, so I have no idea what the "vision" is for core. Is there something I can read?
    2) If it's not reasonable for core to have $F() to work on input groups, why should it be reasonable for Form.Element#setValue to be in core, which was just added?
    3) Is there something besides "core" where it should go that's part of the Prototype project? Or is that basically a nice way of saying "we aren't going to ever do that"?

    Thanks in advance for your consideration.

  • Tobie Langel

    Tobie Langel April 3rd, 2010 @ 11:42 AM

    • Tag changed from needs:tests, section:dom, section:lang to needs:tests, section:dom

    1) We should definitely look into publishing a roadmap. Generally, we consider the actual API close to complete and are more in a process of pruning code rather than adding code.
    2) $F is about to be deprecated.
    3) The latter. :-/

  • apinstein

    apinstein April 3rd, 2010 @ 04:21 PM

    Thanks for the follow-up.

    As an end-user of Prototype (for years), I am thoroughly confused and frustrated. AFAIK, prototype doesn't have an official plugin repo, or any type of stl or other project where it would be appropriate for me to contribute this kind of code. Certainly no such thing is prominently featured on the web site.

    Basically you're telling me to go away instead of trying to constructively direct my efforts to improve the project.

    Maybe it's my fault for hoping/expecting prototype to try to compete with jQuery or YUI so I wouldn't have to switch, but after this conversation I get the message loud and clear that the prototype community leaders aren't interested in having prototype continue as a robust and dynamic infrastructure for building JS web apps.

    I know I could just fork it, but since the community doesn't seem to have or nurture any kind of effort to make centralized ways to share code, or offer a roadmap for doing so, at this point I think you've just convinced me to bail on my use of the project.

    Sorry for the rant, but it's just frustrating and sad to have to walk away from a project that's been so useful for so long.

  • Tobie Langel

    Tobie Langel April 3rd, 2010 @ 08:44 PM

    I'm afraid I don't understand what you find confusing and frustrating here.

    Keeping a platform robust and usable does imply making choices about what's added to it and what isn't. These choices will always be somewhat subjective and won't necessarily please everyone. But they still need to be made.

    That said, nothing ever prevents you from adding helpers to your code–I do that all the time–or from forking the repository.

    We'd love to have a good system for people to share plugins, and you were welcomed to volunteer your time to work on that if you want.

    Remember, this is open-source. If you want something: build it, else live with the solutions others are building and giving away for free.

  • apinstein

    apinstein April 3rd, 2010 @ 09:43 PM

    I am very familiar with open-source projects. I have well over a dozen of my own and many many more that I contribute to.

    I have no interest or time to getting involved with another one, particularly one in a topic area that is already well-done by many other groups. Prototype just doesn't seem to be nurturing the community in the way it could be. The real reason jQuery took over JS mindshare was community, not technology. I just wish it hadn't have happened, because I really like prototype. Unfortunately all of the momentum and progress has migrated away from the prototype community. For my projects to stay competitive without a lot of effort and duplication of code, it is just easier to have one core JS library.

    I will probably just build my own Prototype helper lib that has these functions in the short-term. I try to contribute to upstream to share things with everyone and to simplify dependency management, but there just doesn't seem to be a nice public place for this.

    Thanks for the conversation.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

The Prototype JavaScript library.

Shared Ticket Bins

Attachments

Pages