>   compromiseCHECKBOX({"name":"myName"}); // does not work (as intended)
I'm a little confused by this, since that's the base syntax.  Without
it, how do you make:
<checkbox name="myName" value="myValue")>
(or an INPUT with any other attribute besides name)?

> I haven't seen a single signature like that in MochiKit so far
The whole reason I was proposing this syntax was because createDOM
already had it;  I wasn't trying to do anything non-MochiKit-ish.
This syntax is fully documented:
"For convenience, if attrs is a string, null is used and the string
will be considered the first node."

But since INPUTs can never have child nodes, my suggestion was to make
it so that if attrs was a string (or number) it would be used as the
INPUT's name (since I figure that name is the single attribute most
likely to be set without any others on INPUTs).

In any case, I'd really think a createINPUT with just the core attrs
syntax would be better than one that can only set the name attribute.

Jeremy

On Jun 16, 12:20 am, "Per Cederberg" <[EMAIL PROTECTED]> wrote:
> Ok, so perhaps we should modify createDOMFuncExt to treat the argument
> array as a list of optional arguments? With scalar I suppose you mean
> typeof(o) == "string", "number" or "boolean"?
>
> I'm not a big fan of overloaded function signatures, though. They tend
> to be difficult to document in an understandable way and have weird
> corner-case behavior. In particular if the optional arguments are at
> the beginning. I haven't seen a single signature like that in MochiKit
> so far, so perhaps Bob avoided them on purpose (i.e. always putting
> optionals at the end).
>
> So, a compromise suggestion:
>
>   compromiseCHECKBOX();                                   // works
>   compromiseCHECKBOX("myName");                  // works
>   compromiseCHECKBOX({"name":"myName"}); // does not work (as intended)
>   compromiseCHECKBOX(null, {"name":"myName"}); // works
>
> Such a change wouldn't break any of my code and, since noone else uses
> createDOMFuncExt right now, should be safe. Feel free to modify the
> code on the wiki page if you like.
>
> Cheers,
>
> /Per
>
> On Thu, Jun 12, 2008 at 11:15 PM, machineghost <[EMAIL PROTECTED]> wrote:
>
> > When I first looked at your function I completely missed the
> > significance of this line:
> >    myAttrs[args[pos]] = arguments[pos];
> > and thought that argument was only for specifying which attributes are
> > required.  Having looked at it again, I now understand how it allows
> > for CHECKBOX("myName") syntax.
>
> > Even so however, your function will not result in the same
> > createINPUTs as mine.  Consider this:
> >    myCHECKBOX();                                      // works
> >    myCHECKBOX("myName");                    // works
> >    myCHECKBOX({"name":"myName"});   // works
>
> >    yourCHECKBOX();                                    // does not
> > work
> >    yourCHECKBOX("myName");                  // works
> >    yourCHECKBOX({"name":"myName"}); // does not work
>
> > There are two key differences:
> > 1) nothing is "required" in my version, whereas every scalar argument
> > is required in your version
> > 2) my version only goes in to the "scalar argument logic branch" if
> > the arguments are scalar; your version assumes they are and breaks (or
> > does something weird, I haven't tested) if they aren't.
>
> > However, I still agree that it's silly to have a separate
> > createINPUTFunc function when you already have this other one.  I just
> > think it's worth adding an extra argument to your function to allow
> > specifying of scalar arguments without requiring them or invalidating
> > the standard syntax.
>
> > Jeremy
>
> > On Jun 12, 12:21 pm, "Per Cederberg" <[EMAIL PROTECTED]> wrote:
> >> If I understand you correctly, I think createDOMFuncExt already
> >> accomodates this:
>
> >> CHECKBOX = createDOMFuncExt(null, "input", ["name"], { type: "checkbox" });
> >> HIDDEN = createDOMFuncExt(null, "input", ["name", "value"], { type: 
> >> "hidden" });
>
> >> I'm using this to create SVG functions with required parameters (such
> >> as 'x' and 'y' coordinates and similar).
>
> >> Cheers,
>
> >> /Per
>
> >> On Thu, Jun 12, 2008 at 6:13 PM, machineghost <[EMAIL PROTECTED]> wrote:
>
> >> > I really like your idea of making the creation of the input functions
> >> > more generalized.  However, if we wanted to preserve the:
> >> > CHECKBOX("myNameIsBox1") ==
> >> > <input type="checkbox" name="myNameIsBox1"/>
> >> > functionality we'd need a slight modification to createDOMFuncExt.
> >> > Specifically, we'd need one more argument that let's you specify a
> >> > "default attribute"; if a default attribute was specified and a
> >> > createDOMFuncExt function was only passed a single scalar (string or
> >> > number) argument, it would treat it as if it had been passed
> >> > {*defaultAttribute*:arguments[0]}; here's a quick (untested) draft of
> >> > what I mean ...
>
> >> > MochiKit.DOM.createDOMFuncExt = function(ns, tag, args, attrs,
> >> > defaultAttr/*, ...*/) {
> >> >    args = args || [];
> >> >    attrs = attrs || {};
> >> >    var children = MochiKit.Base.extend([], arguments, 4);
> >> >    return function(/*arg1, ..., argN, attrs, ...*/) {
> >> >        var myAttrs = MochiKit.Base.update({}, attrs);
> >> >        for (var pos = 0; pos < args.length; pos++) {
> >> >            if (arguments[pos] == null) {
> >> >                throw new Error("Argument '" + args[pos] + "' cannot
> >> > be null");
> >> >            }
> >> >            myAttrs[args[pos]] = arguments[pos];
> >> >        }
> >> >        if(arguments.length == 1 && typeof(defaultArgument) !=
> >> > undefined &&
> >> >            (typeof(arguments[0]) == "string" || typeof(arguments[0])
> >> > == "number")) {
> >> >            myAttrs[defaultArgument] = arguments[0];
> >> >            return MochiKit.DOM.createDOMExt(ns, tag, myAttrs);
> >> >       } else {
> >> >            MochiKit.Base.update(myAttrs, arguments[args.length]);
> >> >            var myChildren = MochiKit.Base.extend([], children);
> >> >            MochiKit.Base.extend(myChildren, arguments, args.length +
> >> > 1);
> >> >            return MochiKit.DOM.createDOMExt(ns, tag, myAttrs,
> >> > myChildren);
> >> >    }
> >> > }
>
> >> > If we had that, then we could do:
> >> >    HIDDEN = createDOMFuncExt(null, "input", null, { type: "hidden" },
> >> > "name");
> >> >    CHECKBOX = createDOMFuncExt(null, "input", null, { type:
> >> > "checkbox" }, "name");
> >> > and even:
> >> >    FORMBUTTON = createDOMFuncExt(null, "input", null, { type:
> >> > "button" }, "value");
> >> >    SUBMIT = createDOMFuncExt(null, "input", null, { type: "button" },
> >> > "value");
> >> > since buttons and submits generally don't have names as often as the
> >> > INPUTs that actually receive input.
>
> >> > We could even go further down this path, and make defaultArgument in
> >> > to defaultArguments, an array of default arguments that would get set
> >> > if the arguments length was the number of default arguments or less
> >> > and all arguments were scalar.  If we did that we, could even do:
> >> >    HIDDEN = createDOMFuncExt(null, "input", null, { type: "hidden" },
> >> > ["name", "value"]);
> >> > and then do:
> >> > HIDDEN("myName", "myValue");
>
> >> > On the flip side, I don't know that we really *need* any shorthand
> >> > syntax at all.  I just think the syntax is cool in the createDOM
> >> > functions, and could be similarly cool for the createINPUTs.  I mean,
> >> > which looks better:
>
> >> > 1) var a = INPUT({"type":"hidden", "name":"myName",
> >> > "value":"myValue"});
>
> >> > 2) var a = HIDDEN({"name":"myName", "value":"myValue"});
>
> >> > 3) var a = HIDDEN("myName", "myValue");
>
> >> > Personally, I'd much rather have #3 in my code, especially if I'm
> >> > making a lot of INPUTs at the same time.
>
> >> > Jeremy
>
> >> > On Jun 11, 12:05 am, "Per Cederberg" <[EMAIL PROTECTED]> wrote:
> >> >> The tab indentation is now fixed in svn trunk [1384].
>
> >> >> Regarding the createINPUT and createINPUTFunc functions, I think it
> >> >> would be better with a more generic solution. When creating SVG DOM
> >> >> nodes I wrote a createDOMFuncExt function that should work here also.
> >> >> Seehttp://trac.mochikit.com/wiki/MochiKitDOMExtensionsforthesource
> >> >> code.
>
> >> >> Using that function, the partial versions would instead look like:
>
> >> >>   FORMBUTTON = createDOMFuncExt(null, "input", null, { type: "button" 
> >> >> });
> >> >>   CHECKBOX = createDOMFuncExt(null, "input", null, { type: "checkbox" 
> >> >> });
>
> >> >> Or if you think form elements should always be provided with a name 
> >> >> attribute:
>
> >> >>   FORMBUTTON = createDOMFuncExt(null, "input", ["name"], { type: 
> >> >> "button" });
> >> >>   CHECKBOX = createDOMFuncExt(null, "input", ["name"], { type: 
> >> >> "checkbox" });
>
> >> >> Either way, I'd like to push this to MochiKit 1.5. I'm currently
> >> >> mostly doing bug fixes in svn trunk so that we can get to a release of
> >> >> 1.4 as soon as possible.
>
> >> >> Cheers,
>
> >> >> /Per
>
> >> >> On Tue, Jun 10, 2008 at 10:37 PM, machineghost <[EMAIL PROTECTED]> 
> >> >> wrote:
>
> >> >> > I mentioned the idea of a createINPUT function awhile ago, but no one
> >> >> > seemed terribly interested so I've been slacking on submitting it.
> >> >> > However, I think a lot of createDOM fans could find createINPUT
> >> >> > similarly useful, and with the recent flurry of submissions I figured
> >> >> > now was as good of a time as any to submit it.
>
> >> >> > For those of you who missed my previous posts, the idea behind
> >> >> > createINPUT (and all of its partial versions) is to do the same thing
> >> >> > for the different sub-types of INPUT that createDOM did for every
> >> >> > other element, as these sub-types are practically different elements.
>
> >> >> > So, with (the various partial forms of) createINPUT, you can do stuff
> >> >> > like:
>
> >> >> > var oldWay = INPUT({"type":"hidden"});
> >> >> > var newWay = HIDDEN();
> >> >> > // oldWay.outerHTML == newWay.outerHTML
>
> >> >> > var oldWay2 = INPUT({"type":"text", "name":"someName"});
> >> >> > var newWay2 = TEXT("someName");
> >> >> > // oldWay2.outerHTML == newWay2.outerHTML
>
> >> >> > var oldWay2 = INPUT({"type":"checkbox", "name":"someName",
> >> >> > "class":"someClass"});
> >> >> > var newWay2 = CHECKBOX({"name":"someName", "class":"someClass"});
> >> >> > // oldWay2.outerHTML == newWay2.outerHTML
>
> >> >> > Since there is already an HTML element called button, I named the
> >> >> > <INPUT type="button"> function "FORMBUTTON"; the rest of the aliases
> >> >> > are just their type .toUpperCase().
>
> >> >> > Here's the diff:
> >> >> > 32a33,34
> >> >> >>     "createINPUT",
> >> >> >>     "createINPUTFunc",
> >> >> > 83a86,95
> >> >> >>     "FORMBUTTON",
> >> >> >>     "CHECKBOX",
> >> >> >>     "FILE",
> >> >> >>     "HIDDEN",
> >> >> >>     "IMAGE",
> >> >> >>     "PASSWORD",
> >> >> >>     "RADIO",
> >> >> >>     "RESET",
> >> >> >>     "TEXT",
> >> >> >>     "SUBMIT",
> >> >> > 627a640,658
>
> >> >> >>     /** @id MochiKit.DOM.createINPUTFunc */
> >> >> >>     createINPUT: function (type, otherattrs) {
> >> >> >>         var m = MochiKit.Base;
> >> >> >>         if (typeof(otherattrs) == "string" || typeof(otherattrs) == 
> >> >> >> "number")
> >> >> >>             return MochiKit.DOM.createDOM("input", 
> >> >> >> {"name":otherattrs,
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"MochiKit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to