Does This ColdFusion Tag Make Sense?

I had a debate the other day over whether this tag makes sense or not. I say it doesn’t, but the ColdFusion server says otherwise. What do you think, and why?

<cfargument name="foo" required="true" default="bar"/>

8 Responses to Does This ColdFusion Tag Make Sense?

  1. Dave Carabetta says:

    What about it doesn’t make sense to you? The only issue I have (and it’s a personal preference) is the mixing of XHTML syntax with CFML. Personally, I separate the fact that CFML is server-side markup from HTML, which is client-side, even though they are both tag-based. That being said, there are numerous proponents of making everything XHTML-compliant for consistency.

  2. kai says:

    On a first look it doesn’t make sense. It might become interesting to research the behaviour of the combination if using argument types also. What about a required argument of type numeric which is populated with “fooarg”? Could the default attribute deliver a numeric default value in case of populating the argument with a wrong type? Would that make sense?

  3. Dave Carabetta says:

    Shoot. The other thing is that no type is specified I see. But I think the MX engine defaults the type to “Any”, which makes what you have valid.

  4. The problem is that it’s not clear whether the required attribute will be enforced before or after the default is applied. I guess the argument being required should and does apply to the end result so logically after the default is applied.So perhaps it’s good that it works like this in that you can control whether the field is required or not independently of (i.e. without thinking about) whether there’s a default.

  5. Dave Carabetta says:

    This syntax has been like this since MX first came out (and was a thread on multiple mailing lists way back when). Essentially, the rule has always been that if you have the default attribute present, whether it be blank or not, it overrides the required attribute. Personally, I’m OK with that, because I don’t understand why you would put the default attribute in if it’s required.

  6. paulH says:

    no, it doesn’t. though backward compatibility might suggest you will have to let this sleeping dog lie.

  7. Sam says:

    Doesn’t make much sense unless you already know from somewhere that default basically voids required. Backwards compatibility would trump any changes though.

  8. It actually matches how things work in SQL where you can specify that a column value is required but also give it a default. The default is only used at initialization tho’ and the required tag will be checked when you do an update so that you can’t later on null out a required field.Now, for cfargument, you can’t do that update so there’s nowhere for required=”true” to be checked later on. So, in this context it does look a little odd. I’m going to add wording to the CF Coding Guidelines (for the soon-to-be-published release 3.0.1) that says if you use default=, don’t use required=”true”.