Is Defined

[tracjerian]

I need to insert a cfif that will ensure that a form field is populated and if it's not output a message.
Any help?
Here is what I tried:


<CFIF Len IsDefined("Form.Contract_Number")eq 0>
<cfoutput><p>Please enter a contract number.</p></cfoutput>
</CFIF>

[Newsgroup_User]

<cfif not len(Form.Contract_Number)>
:)
"tracjerian" <webforumsuser@macromedia.com> wrote in message
news:fdu952$d7e$1@forums.macromedia.com...
>I need to insert a cfif that will ensure that a form field is populated and
>if
> it's not output a message.
> Any help?
> Here is what I tried:
>
>
> <CFIF Len IsDefined("Form.Contract_Number")eq 0>
> <cfoutput><p>Please enter a contract number.</p></cfoutput>
> </CFIF>
>

[Newsgroup_User]

<CFIF Len IsDefined("Form.Contract_Number")eq 0>
<cfoutput><p>Please enter a contract number.</p></cfoutput>
</CFIF>

This is never going to evaluate to true!

First of all, IsDefined() is a boolean function. It is going to return
either true or false, the length of which is never going to be zero.
Secondly, by HTTP definition, <input type="text" ...> controls will
always be defined in the action request whether or not a user provides
any text in one. This is different for check box and radio controls,
but text controls are always defined.

As Lossed indicated, you need to check the length of the form field
itself, not if it exists or not.

<cfif len(form.contact_number) EQ 0>...
OR
<cfif NOT len(form.contact_number)>...

Your choice.

[tracjerian]

It still doesn't like the cfif tag.

[Newsgroup_User]

tracjerian wrote:
> It still doesn't like the cfif tag.

What does it not like about the cfif tag?

[Newsgroup_User]

It's often very helpful if you copy and past the error message that CF
provides.

I'm gonna take a wild stab in the dark and say Cf is looking for it's
friend, Form.Contract_Number but can't find them, so throws all it's toys
out of the cot and sulks in the corner.

?


"tracjerian" <webforumsuser@macromedia.com> wrote in message
news:fdubk1$fre$1@forums.macromedia.com...
> It still doesn't like the cfif tag.

[tracjerian]

You are exactly correct:

Error Occurred While Processing Request
Element CONTRACT_NUMBER is undefined in FORM.

db_update_form.cfm: line 12

10 :
11 :
12 : <cfif len(form.Contract_Number) EQ 0>
13 : <cfoutput><p>Please enter a contract number.</p>
14 : </cfoutput>

[Newsgroup_User]

So what is contact_number? A text control? Radio? Check Box?

What does the form look like?

What happens if you put <cfdump var="#form#"> at the beginning of the
action page?

Are you sure you are spelling the form field correctly?

Are you sure you are posting the form, not getting?

[Newsgroup_User]

On db_update_form.cfm, you can provide a series of default values for any
vars that CF is expecting:
<cfparam name="form.Contract_Number" default="" type="integer">



This will check if the var exists and if not, set it to whatever you decide
(here to an emtpy string), which your cfif on line 12 will go to work on.



Alternatively, if you could always check for a var named contract_number in
the form scope/struct:

<cfif not structKeyExists(form,'contract_number') or not
len(form.Contract_Number)>

<cfoutput><p>Please enter a contract number.</p></cfoutput>

</cfif>


"tracjerian" <webforumsuser@macromedia.com> wrote in message
news:fdudlv$hvq$1@forums.macromedia.com...
> You are exactly correct:
>
> Error Occurred While Processing Request
> Element CONTRACT_NUMBER is undefined in FORM.
>
> db_update_form.cfm: line 12
>
> 10 :
> 11 :
> 12 : <cfif len(form.Contract_Number) EQ 0>
> 13 : <cfoutput><p>Please enter a contract number.</p>
> 14 : </cfoutput>
>
>
>
>
>

[Newsgroup_User]

Errr...if using the cfparam, change that type attribute to "any" rather than
"integer" if using a default empty string ;)


"Lossed" <blankemail@hotmail.com> wrote in message
news:fduega$ip8$1@forums.macromedia.com...
> On db_update_form.cfm, you can provide a series of default values for any
> vars that CF is expecting:
> <cfparam name="form.Contract_Number" default="" type="integer">
>
>
>
> This will check if the var exists and if not, set it to whatever you
> decide (here to an emtpy string), which your cfif on line 12 will go to
> work on.
>
>
>
> Alternatively, if you could always check for a var named contract_number
> in the form scope/struct:
>
> <cfif not structKeyExists(form,'contract_number') or not
> len(form.Contract_Number)>
>
> <cfoutput><p>Please enter a contract number.</p></cfoutput>
>
> </cfif>
>
>
> "tracjerian" <webforumsuser@macromedia.com> wrote in message
> news:fdudlv$hvq$1@forums.macromedia.com...
>> You are exactly correct:
>>
>> Error Occurred While Processing Request
>> Element CONTRACT_NUMBER is undefined in FORM.
>>
>> db_update_form.cfm: line 12
>>
>> 10 :
>> 11 :
>> 12 : <cfif len(form.Contract_Number) EQ 0>
>> 13 : <cfoutput><p>Please enter a contract number.</p>
>> 14 : </cfoutput>
>>
>>
>>
>>
>>
>
>

[efecto747]

Hi,

If you can validate the form before its submitted you'll save yourself a lot of trouble further down the track. Attached is a very simple example of how you might do this using JavaScript (not tested):

[Kronin555]

Don't rely on Javascript as your only error-checking mechanism. It's nice to do some error-checking in the browser, but you still need to do server-side checking because your users can always disable javascript.

[Newsgroup_User]

"If you can validate the form before its submitted you'll save yourself
a lot of trouble further down the track. Attached is a very simple
example of how you might do this using JavaScript (not tested):"

Not really. JavaScript and any client side validation is good for a
nice user interface. But it does not replace server side validation.
One can not rely on it always being done.

Server side validation is about insuring one gets as clean data as
possible in the application and since users can and do turn off
JavaScript and in other ways circumvent it, if one relies on this for
protecting ones data, one is in for some trouble further down the track.

[Newsgroup_User]

I agree with Ian here.

JS is a great client-side tool to potentially reduce the load on CF and
improve the user experience, and used in conjunction with, and never instead
of, server-side validation, it's a great way to go, me thinks. But because
most sites have no control over whether JS enabled in every client that
requests the site's pages, it would be crazy to rely solely on JS
validation. It's the icing, not the cake ;)

"Ian Skinner" <iskinner@cdpr.ca.gov> wrote in message
news:fe0drm$gh7$1@forums.macromedia.com...
> "If you can validate the form before its submitted you'll save yourself a
> lot of trouble further down the track. Attached is a very simple example
> of how you might do this using JavaScript (not tested):"
>
> Not really. JavaScript and any client side validation is good for a nice
> user interface. But it does not replace server side validation. One can
> not rely on it always being done.
>
> Server side validation is about insuring one gets as clean data as
> possible in the application and since users can and do turn off JavaScript
> and in other ways circumvent it, if one relies on this for protecting ones
> data, one is in for some trouble further down the track.
>
>
>

[efecto747]

Wow guys, let's all jump on the client side validation bashing wagon shall we? Amazing how one simple post can generate such self-righteous responses.


Kronin555: Actually my users can't turn off JavaScript. You're making a bold assumption given the fact you know nothing about the environment in which I work and presumably know nothing about the environment in which the OP is working. Do you always need to do server side validation? Ever considered the fact not everyone's requirements are the same as yours?


Ian Skinner: You're also making an assumption that everyone's appps have the same requirements and priorities as yours. You're also putting words in my mouth by arguing it "does not replace" server side validation - did I say it replaced it? No. Could it replace it in this example? perhaps - but considering we don't know the context in which it will be used, who knows? I'm pretty sure what I actually said was "If you can validate the form before its submitted you'll save yourself a lot of trouble further down the track" - looking back at the thread I realise the "trouble further down the track" I referred to is that the OP wouldn't have to come back to this forum where no-one seems to give you a straight answer to a simple question.

You then talk about "protecting ones data" ...what the?? Geez, I thought the OP just wanted to ensure users filled in a field? Did I miss something in that first post?? "I need to insert a cfif that will ensure that a form field is populated and if it's not output a message. Any help?" I'm pretty sure I answered the question.


Lossed: You also appear to be blind to the fact that there may be some situations where server side validation is not required. In a similar fashion to the other two, you make the assumption that all web applications are built to run in an open, uncontrolled environment. Your closing remark, "It would be crazy to rely solely on JS validation" shows how simple your world must be. Crazy? Really? What about if I'm building a search page? Should I pass a single search field to the server to validate just so it can say "please enter a search string"??? What about if I'm building a simple email feedback form - should I pass the email address back to the server to validate? Where's the sense in that??


My point (in case you missed it in the above rant) is that every application has its own unique set of requirements and to make sweeping remarks like the ones from the three posters above is either arrogant or ignorant, I can't decide.

Yes, server-side validation is important in some circumstances but its not always necessary. I work mostly with a large financial application that utilises both server-side and client-side validation - there is no way it could do what it does without both, but to suggest that server side validation can never be replaced by client side validation is just showing your limited understanding of the many complexities of real world development.

Anyway I've wasted enough time - go ahead, have another go at me.. ;)

[Newsgroup_User]

:)


"efecto747" <webforumsuser@macromedia.com> wrote in message
news:fe1uvk$82q$1@forums.macromedia.com...
> Wow guys, let's all jump on the client side validation bashing wagon shall
> we?
> Amazing how one simple post can generate such self-righteous responses.
>
>
> Kronin555: Actually my users can't turn off JavaScript. You're making a
> bold
> assumption given the fact you know nothing about the environment in which
> I
> work and presumably know nothing about the environment in which the OP is
> working. Do you always need to do server side validation? Ever
> considered the fact not everyone's requirements are the same as yours?
>
>
> Ian Skinner: You're also making an assumption that everyone's appps have
> the
> same requirements and priorities as yours. You're also putting words in my
> mouth by arguing it "does not replace" server side validation - did I say
> it
> replaced it? No. Could it replace it in this example? perhaps - but
> considering
> we don't know the context in which it will be used, who knows? I'm pretty
> sure
> what I actually said was "If you can validate the form before its
> submitted
> you'll save yourself a lot of trouble further down the track" - looking
> back at
> the thread I realise the "trouble further down the track" I referred to is
> that
> the OP wouldn't have to come back to this forum where no-one seems to give
> you
> a straight answer to a simple question.
>
> You then talk about "protecting ones data" ...what the?? Geez, I thought
> the
> OP just wanted to ensure users filled in a field? Did I miss something in
> that
> first post?? "I need to insert a cfif that will ensure that a form field
> is
> populated and if it's not output a message. Any help?" I'm pretty sure I
> answered the question.
>
>
> Lossed: You also appear to be blind to the fact that there may be some
> situations where server side validation is not required. In a similar
> fashion
> to the other two, you make the assumption that all web applications are
> built
> to run in an open, uncontrolled environment. Your closing remark, "It
> would be
> crazy to rely solely on JS validation" shows how simple your world must
> be.
> Crazy? Really? What about if I'm building a search page? Should I pass a
> single
> search field to the server to validate just so it can say "please enter a
> search string"??? What about if I'm building a simple email feedback
> form -
> should I pass the email address back to the server to validate? Where's
> the
> sense in that??
>
>
> My point (in case you missed it in the above rant) is that every
> application
> has its own unique set of requirements and to make sweeping remarks like
> the
> ones from the three posters above is either arrogant or ignorant, I can't
> decide.
>
> Yes, server-side validation is important in some circumstances but its not
> always necessary. I work mostly with a large financial application that
> utilises both server-side and client-side validation - there is no way it
> could
> do what it does without both, but to suggest that server side validation
> can
> never be replaced by client side validation is just showing your limited
> understanding of the many complexities of real world development.
>
> Anyway I've wasted enough time - go ahead, have another go at me.. ;)
>
>