I agree with Ryan. I do all my fancy validation on the client. My server
side returns a generic error message and a numeric code, which I can cross
reference with my private error documentation.
For what it's worth, it's been years since I kicked it old school and did
an html form submit. Ajax is a far superior user experience. 100% of my
pages are like this: 1) put all my fields on the page, 2) assign a
javascript function to a button 3) in the submit function I create an array
of the fields I wanna post, including any validation 4) stringify the
object and 5) post it using jquery ajax.
Google is drowning in examples of this, but here are some code snips for
reference.
(these examples use jQuery)
1) html has various input elements, like <input type="text" id="username"
name="uid" /><input type="password" id="pwd" name="pwd" /> (NOTE: the
'name' attribute is critical - otherwise you'll bang your head on the desk
wondering why seralizeArray is skipping your fields.)
2) on the submit button action, either manually reconcile your values, such
as:
- myobj = {};
- myobj.user = $("#uid").val();
- myobj.pass = $("#pwd").val();
- OR- use jquery's serializeArray to just grab the whole form.
- myobj = $(":input").serializeArray()
I do it manuallly when I have fields with complex data, or I want to do
additional validation.
3) in your ajax call, stringify the data (this will go to the server as a
JSON object)
$.ajax({
async : false,
type : "POST",
url : "/myWebPyMethod",
data : '{"args":' + JSON.stringify(myobj) + '}',
contentType : "application/json; charset=utf-8",
dataType : "text",
success : function(response) {
alert("woot!");
},
error : function(response) {
alert("wah wah wah....");
}
});
4) in web.py get hold of your args
def myWebPyMethod(self):
try:
import json
data = web.data()
foo = json.loads(data)
print foo
print foo["user"]
except Exception, ex:
raise ex
Have fun!
On Thu, May 24, 2012 at 10:24 PM, Ryan Sears <fitb...@gmail.com> wrote:
> What I usually do is verify everything client-side with javascript to do
> all the fancy red letters and shaking or what have you, then make sure
> every piece of data is what I think it is, server-side, and return a
> generic error if it's not. That way clients get a full UI experience, and
> evil hackers get to spend more time figuring out how to attack my
> application :-P.
>
> Probably not the best way to do it, but it works for me!
>
> Fitblip
>
>
>
> On Thu, May 24, 2012 at 6:53 PM, Bill Seitz <flux...@gmail.com> wrote:
>
>> Under lots of conditions, you want the outcome of server-side
>> rejection of a form to be
>> (a) send the user back to the form with all the data they entered
>> (b) stick a red error/alert message near the top
>> (c) possibly stick red alerts next to specific fields
>>
>> Is there a nice example app showing the smart way to do those?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "web.py" group.
>> To post to this group, send email to webpy@googlegroups.com.
>> To unsubscribe from this group, send email to
>> webpy+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/webpy?hl=en.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "web.py" group.
> To post to this group, send email to webpy@googlegroups.com.
> To unsubscribe from this group, send email to
> webpy+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/webpy?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"web.py" group.
To post to this group, send email to webpy@googlegroups.com.
To unsubscribe from this group, send email to
webpy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/webpy?hl=en.
