Slow answer here, but the suggested compromise function would handle
any random attribute if they are just in the right position in the
argument list:
> compromiseCHECKBOX(null, {"name":"myName"}); // works
Cheers,
/Per
On Tue, Jun 17, 2008 at 7:04 AM, machineghost <[EMAIL PROTECTED]> wrote:
>
>> 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
-~----------~----~----~----~------~----~------~--~---
