From: Alex B. <en...@tu...> - 2001-09-10 17:48:58
|
hi all, I just did a proper cvs sync, (by that, I mean doing a complete set comparison of the files and pruning the junk from sf)... please do an update :) _alex |
From: Jason H. <jc...@ey...> - 2001-09-10 17:58:11
|
Just an off the wall question regarding the FormBuilder and validation classes. Since there are many ways of validating user input and displaying any errors, I was curious how FormBuilder will handle this. I've always preferred the client side javascript checks. IE: if First Name is blank, an alert explaining the error is sent onSubmit, then focus on invalid field. The more popular way is too simply process the form, collecting any errors and display them on a page, with a link back to the form. Alot of times the link back to the form is a mere javascript:history.back() which tends to lead to a "Data Missing from POST operation error" requiring a reload. I guess my question is.. how will this work? Thanks. jason |
From: Alex B. <en...@tu...> - 2001-09-10 18:20:54
|
> Just an off the wall question regarding the FormBuilder and validation > classes. heh, cool. > Since there are many ways of validating user input and displaying any > errors, I was curious how FormBuilder will handle this. I've always > preferred the client side javascript checks. IE: if First Name is > blank, an alert explaining the error is sent onSubmit, then focus on > invalid field. The more popular way is too simply process the form, > collecting any errors and display them on a page, with a link back to > the form. Alot of times the link back to the form is a mere > javascript:history.back() which tends to lead to a "Data Missing from > POST operation error" requiring a reload. I guess my question is.. how > will this work? _binarycloud_ will provide 'server-side' means of processing and validating incoming data. So, for example: user had a form with: Name, Email, Address, City, State, Zip They enter some stuff: Mr. Foo, moo@foo (note the incorrect email), 123 Moo Lane, Berkeley, CA 94710 I don't have any plans for building JS (i.e. client-side) input vaildation, but I imagine that would actually be fairly easy to build if you already have the JS, and I'm happy to give you a flag in formbuilder that says "generate JS validation.. So assume server-side only: FormBuilder gets the data back (which is knows _nothing_ about) and passes it directly to EntityManager. EntityManager uses any Processors and Validators on the dataset to determine if it is O.K. or bad. If it's ok, EntityManager::Add() returns true, and FormBuilder presents the 'success' page (or however you have configured it) is presented. If EntityManager::Add() returns false, FormBuilder checks the Error stack (I'm undecided about this one: whether to register global errors in a stack which FormBuilder checks, or whether to "localize" the errors and keep them in context) anyway.. FormBuilder takes those errors and sends back the same form, but with all kinds of stuff in it, maybe: "Sorry, you are stupid, please have a look at the errors below" -> Your email address is not valid, please re-enter it. Name: Mr. Foo Red-> Email: moo@foo Address: 123 Moo Lane City: Berkeley State: CA Zip: 94710 ... The idea being that FormBuilder will _only_ be in the business of _building forms_ - Validation, etc will _always_ happen with EntityManager. --------- That's how I see it working. Re: JS: I think you'd probably just want to have a flag in the form Definition that says "Do JS validation on this one with some stock function" I'm sure that would be pretty easy to do. _a |
From: Jason H. <jc...@ey...> - 2001-09-10 18:39:18
|
Alex Black wrote: > EntityManager uses any Processors and Validators on the dataset to determine > if it is O.K. or bad. If it's ok, EntityManager::Add() returns true, and > FormBuilder presents the 'success' page (or however you have configured it) > is presented. . . . > The idea being that FormBuilder will _only_ be in the business of _building > forms_ - Validation, etc will _always_ happen with EntityManager. Drool.. > I think you'd probably just want to have a flag in the form Definition that > says "Do JS validation on this one with some stock function" > > I'm sure that would be pretty easy to do. I noticed the event flags in the entityDefs (onChange, onBlur, etc). It looks like the facility to add client-side validation (minimal) is pretty much in place. Perhaps this is something that can be messed with in the future. On another note, I think it's a great idea to expand the TODO/TASKS list. I'm _very_ eager to help with this project, but so much is going on all over the place, I haven't found myself comfortable enough anywhere to begin. An isolated task list with any/all pertinent information would be most helpful. I'm sure I'm not the only developer reading this list that feels this way. SO EVERYONE WAKE UP AND START ASKING QUESTIONS. =] jason |
From: Alex B. <en...@tu...> - 2001-09-10 18:56:40
|
>> I think you'd probably just want to have a flag in the form Definition that >> says "Do JS validation on this one with some stock function" >> >> I'm sure that would be pretty easy to do. > > > I noticed the event flags in the entityDefs (onChange, onBlur, etc). It uh... where? There aren't any Onchange/onblur/ etc flags in entity defs. There may be in UI control definitions. I wanted to associate default UI Controls with each entity field for convenience, but that's the only place On(x) would ever go. > looks like the facility to add client-side validation (minimal) is > pretty much in place. Perhaps this is something that can be messed with > in the future. Yes, pretty much. We can probably do UI Controls for the JS validation pieces or something, such that formBuilder just assembles the outpt from UIControlBuilder. > On another note, I think it's a great idea to expand the TODO/TASKS > list. I'm _very_ eager to help with this project, but so much is going > on all over the place, I haven't found myself comfortable enough > anywhere to begin. An isolated task list with any/all pertinent > information would be most helpful. I'm sure I'm not the only developer > reading this list that feels this way. Yeah, I had that feeling. I've done a portion of the task defs, and will continue to work through them. I'll let everyone know when I'm done. At this point, the tasks can be divided up into two camps: make and EntityManager. I'm much more concerned with EntityManager at the moment, because we can always return to Make and construct new and cool things: but the system isn't complete until that stuff is up and working. After the Make and EM tasks are done, we can get into builders, and the system will be pretty near done. Most of the Builder code already exists, also. :) > SO EVERYONE WAKE UP AND START ASKING QUESTIONS. =] heh _a |
From: Albert L. <a.l...@ve...> - 2001-09-10 19:18:18
|
> On another note, I think it's a great idea to expand the TODO/TASKS > list. I'm _very_ eager to help with this project, but so much is going > on all over the place, I haven't found myself comfortable enough > anywhere to begin. An isolated task list with any/all pertinent > information would be most helpful. I'm sure I'm not the only developer > reading this list that feels this way. You're exactly right Jason, I want to help too but don't really know where to pick up. I don't know what different levels of complexity some of the items involve, and don't know where a beginner php programmer like myself would be most effective. Any idea on how to fix this? Alby |
From: Alex B. <en...@tu...> - 2001-09-10 19:55:15
|
>> On another note, I think it's a great idea to expand the TODO/TASKS >> list. I'm _very_ eager to help with this project, but so much is going >> on all over the place, I haven't found myself comfortable enough >> anywhere to begin. An isolated task list with any/all pertinent >> information would be most helpful. I'm sure I'm not the only developer >> reading this list that feels this way. > > You're exactly right Jason, I want to help too but don't really know where > to pick up. I don't know what different levels of complexity some of the > items involve, and don't know where a beginner php programmer like myself > would be most effective. Any idea on how to fix this? I think you would be most effective building some of the peripheral tools, for example I have spec'd a 'complete' html character entity translation library.. which is a standalone class. Also, there are a number of tasks that need doing like (heh) unit tests, hooking PHPDoc up to make, etc. It depends on what you are interested in doing. -a > Alby |
From: Andreas A. (Thyrell) <a.a...@th...> - 2001-09-10 18:31:49
|
Hi Jason, >errors, I was curious how FormBuilder will handle this. I've always >preferred the client side javascript checks. IE: if First Name is >blank, an alert explaining the error is sent onSubmit, then focus on >invalid field. I think this will be a additional feauture of FormBuilder (generating the js to validate). But you can not trust on that validation. > The more popular way is too simply process the form, >collecting any errors and display them on a page, with a link back to >the form. Alot of times the link back to the form is a mere >javascript:history.back() which tends to lead to a "Data Missing from >POST operation error" requiring a reload. I guess my question is.. >howwill this work? Actually the from will be redisplayed with the missing/faulty fields cleared and a collection of error noctices somwere on the form page. So you don't have to go back (thats a mess and users hate that ;)) You just correct the errors and press submit again. Andi |