Dan,
Sounds like it would benefit more developers if MM buys this extension from you and
incorporate it into CFMX for I believe form input and process is a critical data
process in a lot of applications.
Thanks.
Don
>Don,
>
>> The problem, specifically, there are two types of validations:
>> 1
Don,
> The problem, specifically, there are two types of validations:
> 1) field required or not, msg responds to that;
> 2) field data_type, msg responds to that.
> But there's only one Message attribute.
qForms is a completely different beast than CFFORM. You can attach unlimited
validation rul
Dan,
The problem, specifically, there are two types of validations:
1) field required or not, msg responds to that;
2) field data_type, msg responds to that.
But there's only one Message attribute.
Also, in my utility/application, all db related metadata and data are dynamically
determined,
Neil,
> Can you defined Multi-Lingual error messages?
Version 2.0 will include support for localization. You'll be able to set a
variable to determine what language the error messages are displayed in.
As it is right now, you can supply custom error messages for all the
validation methods, so y
Can you defined Multi-Lingual error messages?
-Original Message-
From: Dan G. Switzer, II [mailto:[EMAIL PROTECTED]
Sent: 24 July 2003 13:48
To: CF-Talk
Subject: RE: qForms (was Re: CFForm madness. 0_0)
Don,
> Nice!
>
> Would it solve js problems I described in the followi
Don,
> Nice!
>
> Would it solve js problems I described in the following thread?
> http://www.houseoffusion.com/cf_lists/index.cfm?method=messages&threadid=2
> 5711&forumid=4
I'm not 100% sure I understand what your asking in that e-mail, but:
1) You can define custom/unique error messages for
Please see my comments below.
>Jon,
>
>> One guy hacking it, is probably going to be more efficient
>> with his own stuff.
>
>I immensely disagree with this statement (of course, I wrote the API. ) I
>think even individuals greatly benefit from qForms. I don't really equate
>Fusebox and qForms, be
It's like taking the red pill, isn't it? :)
- Original Message -
From: Angel Stewart <[EMAIL PROTECTED]>
Date: Wednesday, July 23, 2003 2:12 pm
Subject: RE: qForms (was Re: CFForm madness. 0_0)
> Ok!
>
> I implemented Q Forms...and I really think its GREAT!
>
Ok!
I implemented Q Forms...and I really think its GREAT!
It isn't hard to use AT All, the only thign that tripped me up was case
sensitivity for field names.
But other than that..I mean the thing rocks!
Email validation, Zip code validation...telephone number
validation..it's all here!
I can't
Jon,
> I don't mean efficient as in the amount of time it takes to code
> (obviously using a pre-built api saves coding time), I mean time to
> learn + coding time.
>
> When I weigh, the time it would take to get comfortable with an API
> versus rolling my own, the time gained by using something
Angel,
> Sooo...uhhh...which part of that code disables the submit button.
qForms automatically handles this. Just creating the qForms object takes
care of that for you.
> Is there any means of preventing form fields from being resubmitted if
> the user keeps clicking the Refresh button with the
Our take on qForms is that it helps to organize the often-chaotic world of JS. We
have worked on several large enterprise projects where the JS was all over the place,
literally. qForms helped greatly and also helps to get developers thinking in terms of
calling centralized services as and wher
> Is there any means of preventing form fields from being
> resubmitted if
> the user keeps clicking the Refresh button with the Qforms API?
> That's about the last common error I think I encounter when designing
> forms.
This would be outside the scope of capabilities for a client-side validatio
*sneaks back into the conversation*
Sooo...uhhh...which part of that code disables the submit button.
Is there any means of preventing form fields from being resubmitted if
the user keeps clicking the Refresh button with the Qforms API?
That's about the last common error I think I encounter when
I don't mean efficient as in the amount of time it takes to code
(obviously using a pre-built api saves coding time), I mean time to
learn + coding time.
When I weigh, the time it would take to get comfortable with an API
versus rolling my own, the time gained by using something other than
the rou
Dan wrote:
>For example, take the following lines of code:
OK I'm convinced.
Naturally, this thread pops up just *after* I get done building a great
big form system for a project I'm working on; with custom server-side
val all over the place.
The real crime is I forgot all about qforms, but
Jon,
> One guy hacking it, is probably going to be more efficient
> with his own stuff.
I immensely disagree with this statement (of course, I wrote the API. ) I
think even individuals greatly benefit from qForms. I don't really equate
Fusebox and qForms, because qForms isn't telling you how to d
This describes my attitude as well, and to segue a bit, how do you
feel about Flash/Actionscript?
On the surface...I keep thinking to myself that I should love
Actionscript, it's really all that Javascript wants to be, but I keep
getting frustrated with it.
I think it comes down to two problems as
Charlie,
> I think my 'reluctance' to look at qForms is because...well, frankly I
> enjoy
> writing js. I'm hesitant to give up that 'control' as it were.
I don't look at it is giving up control--I think that's the cool part about
it. The way I view it, is it gives a solid footprint in which to
Hi Dan:
I think my 'reluctance' to look at qForms is because...well, frankly I enjoy
writing js. I'm hesitant to give up that 'control' as it were.
I will look at it tho...if for no other reason that simple curiosity. I
think it's pretty amazing that, as I said below, I've never heard anything
20 matches
Mail list logo
