Really annoying problem

Submitted by Lovecannon on Thu, 02/14/2008 - 00:47.

I really like the design of Dojo, and I really like most of its simplicity...but one key feature I really need, is a bit lacking. I am talking about easy form submission. Its not hard to manually send a xhrPost, but I send it like this:

dojo.connect(dojo.byId("formtest"), "onsubmit", function() {
dojo.xhrPost({url: 'url',
handleAs: 'json',
load: function(data) { alert("Success"); },
error: function(data) { alert("Error - "+data); },
form: 'formtest' });
});

And it keeps coming up with a 'bad http response' error, when I can easily send AJAX requests via jQuery to that same url. Also, whenever I use that connect to send the AJAX request, the form still does a normal form submit. Is there any way I can disable normal form submission without an inline onsubmit="return false"...that is the only thing really keeping me from using dojo, does anyone have solutions for my problem?

Login or register to post comments
Subscribe post

the default behavior of a

Submitted by dante on Thu, 02/14/2008 - 01:05.

the default behavior of a form is to submit, so you have to stop that by calling evt.preventDefault() if that is what you want to happen:

dojo.connect(dojo.byId("formTest"),"onsubmit",function(e){
    e.preventDefault();
    dojo.xhrPost({
        url:"url.json",
        form:"formTest",
        handleAs:"json",
        load:function(data){
            alert(data);
        }
    });  
});

says [object Object] for me. you can use console.dir(data) and firebug lite / firebug will show you without the modal alert.

what does your form look like? how about the actual data coming from the server? perhaps it's expecting extra headers?

dojo.connect normalized the event, so you always have preventDefault and stopPropogation, both of which can be called by calling dojo.stopEvent(e) .

thanks

Submitted by Lovecannon on Thu, 02/14/2008 - 01:46.

Thanks man, the e.preventDefault fixed all the probs, it works fine now, thanks ^_^

Another issue....

Submitted by Lovecannon on Thu, 02/14/2008 - 01:55.

Is there any way to not use the extra html attributes like djConfig, dojoType, etc...it kills my XHTML validation..and I really need XHTML validation....

There are a couple of

Submitted by frankf on Thu, 02/14/2008 - 02:07.

There are a couple of techniques I found via Search (these forums) that solve the validation problem for 1) djConfig and 2) programmatic dojo (vs. markup). I believe the conclusion was that markup dojo could not pass validation without a custom DTD.

Just to follow up on

Submitted by jburke on Thu, 02/14/2008 - 03:45.

Just to follow up on frankf's answer: you can define djConfig in a script block before the script tag for dojo.js, so that should avoid the validation issue on that tag. For widgets, as frankf suggests, do not put dojoType in your HTML, but instead use dojo.addOnLoad() to programmatically create the widgets and put them in the page.

Example:

Submitted by frankf on Thu, 02/14/2008 - 14:05.

djConfig = {parseOnLoad:false};  //do this way to pass validation.

  //our custom build
  //our custom build


  //	//end hide javascript-placed html from validator.

Well...

Submitted by Lovecannon on Thu, 02/14/2008 - 20:57.

Well, the only really easy solution to the whole validation problem, is a server side user agent detection if/else...such as ONLY if the user agent is a browser, will it use dojo, otherwise, itll display clean content :D
Very easy to implement, becaues I tried using a custom inline !ATTLIST for XHTML, and that only works if your serving the content as application/xhtml+xml, but then my form widgets wont work...so...I guess user agent detection seems to be the best way :\

There are other advantages

Submitted by frankf on Thu, 02/14/2008 - 21:02.

There are other advantages to using programmatic vs. markup widget creation (perceived performance, control, etc.).

So...if you decide to go to programmatic dojo, the above two techniques (the second only needed if you include html markup within script tags) works very well. No validation errors (XHTML).