chris feldmann [EMAIL PROTECTED] pisze:
> > Here's the "problem": I need to perform a short asynchronous check for
> > a condition in a database before accepting user input from a form, and
> > succeed/fail the form depending on the result of the check. It would be
> > best to present a "please wait" div with a nice animated gif, then
> > either proceed to the next screen, or fail the form, display a div with
> > an error message, and let the user edit the entered values. What is the
> > best way to do this? I found the AJAX demo in the wiki - assuming that
> > an URL on the server is able to send jsonified objects, would it be
> > enough to call loadJSONdoc on it? What best practice or easiest way to
> > do the above would you suggest?
> >
> > Sorry if I'm asking a FAQ, and thanks for your time,
> >
>
> 1:12 pm (9 hours ago)
>
> Although I suppose you've now had an opportunity to read the docs,
Erm, not exactly. I'm trying to find time for a few projects
simultaneously _including_ a new version of the system for which
I need the semi-quick fix, and also, preferably, for washing myself,
eating and sleeping - this thing cropped up and has to be dealt
with ASAP, which unfortunately doesn't mean I have adequate time
resources for dealing with it.
> it
> doesn't sound like you're really asking about mochikit, as opposed to
> the general user experience flow.
Well, yes, I guess that's right. To tell the truth, I've never liked
JavaScript and never really trusted it, it's just that I'm planning
to convert a few internal applications at my office from PHP to
TurboGears, so naturally I ran into Mochikit, along with a number of
docs and blog entries supporting the claim that JS doesn't _have_ to
suck, and I thought about using it to elegantly solve the "problem".
Actually, the JS code is just the first line of defense, I run the test
again at server-side, but then it's too late for re-editing the form
(and saving its contents into session data, redirecting to the form
and filling them again looks now - once I decided to use JS - less
attractive and more work, too).
> You could disable the submit button
> or hide it until the check takes place, I suppose; I'd put a note
> saying why it wasn't there and try to save people from ever noticing
> the form was originally unsubmittable by checking the field in
> question on the onblur event on the field in question so by the time
> they finished the form, the button was enabled. Maybe. Here's a rough
> sketch of the way to do the "hiding the button" version
>
> <form id="form">
> <input type="text" name="textfield" id="fieldtobechecked"/>
> <input type="submit" id="submit" style="left:-999em;"/>
> </form>
>
> connect("fieldtobechecked", "onblur", checkVal);
>
> checkVal = function(){
> url="example.com";
> var req = doSimpleXMLHttpRequest(url, {"val" :
> document.form.textfield.value});
> req.addCallback(reqReturn);
> req.addErrback(reqErr);
> }
>
> reqReturn = function(){
> if(req.allgood){
> setElementPosition('submit', {x : 99, y : 99});
> } else {
> //notify user
> }
> }
>
> reqErr = function(){
> alert("fixme");
> }
>
> There are other ways to hide things:
> http://mochikit.com/doc/html/MochiKit/Style.html#element-visibility
>
> I like this idea less every time I think about it, but I'll toss it out there.
Wow, thanks, I didn't expect a kind od Spanish Inquis^W^W^W^W code
example. I'll give it a try. BTW, won't this "left:-999em" trick create
a huge horizontal scrolling bar in the document window? Perhaps something
like 'element.style.visibility = hidden' would be less visible to the user?
--
Grzegorz Staniak <gstaniak _at_ gmail [dot] com>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MochiKit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/mochikit
-~----------~----~----~----~------~----~------~--~---
