views:

382

answers:

5

I am using jQuery Form Plugin to submit (POST) a WebForm.

Everything works great if I put my controls on that form.

When I add (append) dynamic fields using jQuery (text or hidden) it seems that my fields cannot be sent.

Is there anyone who experienced the same problem?

A: 

You might try attaching the plugin on form submit:

<script type="text/javascript"> 
    $("#submit").click(function() { 
        // bind 'myForm' and provide a simple callback function 
        $('#myForm').ajaxForm(function() { 
            alert("Thank you for your comment!"); 
        }); 
        return false;
    }); 
</script> 
Mike Henderson
@Mike, are you sure you write your code like that? Have you see this page (http://malsup.com/jquery/form/#api) that explain difference between `ajaxForm()` and `ajaxSubmit()` method?
Donny Kurnia
@Donny Thanks for the link. I wasn't familiar with the plug-in and was just offering a quick solution.
Mike Henderson
Well, if you want to get more reputation, answer the question that you familiar with. You will get more rep in no time.
Donny Kurnia
A: 

How are you adding your dynamic fields? I do the same thing, appending hidden input elements, and it uploads them just fine.

To be more specific, I am using jQuery as well, so I am curious what functionality in jQuery you are using which you are having a problem with.

That being said, you are going to have to give more information on your problem, as there are many proven ways to succesfully do exactly what it is you are trying to do.

casperOne
A: 

I wouldn't do it this way simply because I can see various browsers disabling this ability in the future and then you're up the creek.

Why not just have a single hidden field from the beginning and put all your variables and values in there in some kind of querystring form format like "<variable>=<value>&<variable>=<value>&..."?

It's quick, it's easy and it doesn't rely on rendering HTML form controls after a page has loaded.

EDIT: Per the numerous comments below. This may not be considered "natural" by some but it's reliable. Being that we're dealing with client side scripting which is notorious for behaving inconsistently across browsers, personally, I would go for what I know will work. I don't expect everyone to prefer my way but I stand by it as a decent option with advantages that at least should be considered.

Spencer Ruport
@Spencer Ruport: I disagree. If this scenario were to happen, you would, you would have to disable programattic access to INPUT elements through javascript. Because of this, it would disable your approach as well.
casperOne
@casper - This is a good approach that doesn't rely on dynamic control generation which is problematic no matter what language or technology you happen to be using. Don't downvote me just because you prefer your answer.
Spencer Ruport
@Spencer Ruport: I downvoted your answer because I believe it to be *wrong*, even explaining *why*, which is a lot more than most will give you on Stack Overflow. You shouldn't assume (you know what they say about that). The secure solution to what you *believe* will happen to browsers in the future (and isn't the case **now**, so that gives your answer even *less* credibility) makes your reply ineffective even if that future comes to pass. Next time, take a look at your answer to understand *why* a downvote was applied, especially if someone gives an objective view as to why.
casperOne
@Spencer Ruport: Additionally, your reptuation activity as of this moment indicates that you are the one who downvoted my answer as a **form of retaliation**. Given my statement above, and your incorrect assumption, I say "shame on you" and suggest you think long and hard before taking such a flagrant action in the future.
casperOne
@Spencer Ruport: Additionally, it isn't a good approach because the person asking the question has an *obvious* need to add values dynamically on the *client-side*. Your approach doesn't prevent the need for Javascript access on the client side, which would be negated if security measures that you predict come to pass.
casperOne
@casper - Where did I say anything about avoiding javascript? I was referring specifically to using javascript to create form controls on the fly.
Spencer Ruport
@casper - In the end you're recommending an approach that's not well defined while I'm recommending an approach that uses forms the way they've worked for well over a decade. Trying unusual approaches with a technology that's known historically for being interpreted inconsistently by various browsers is asking for trouble. You may not prefer my answer but it's not a bad answer and it's certainly more reliable than yours.
Spencer Ruport
@Spencer Ruport: You didn't, but at the risk of repeating myself a third time, your answer suggests a mechanism because of a prediction about security concerns in browsers in the future regarding input form behavior and Javascript. In order to fix that concern, browsers would have to disable the manipulation of *any* operations on input elements, which would render your solution invalid. In light of that, if you are going to use JavaScript anyway, it might as well be in the way that is natural to process (at least more natural than you suggest).
casperOne
@Spenser Ruport: The answer is not well-defined because the person who asked didn't say specifically how they were adding the data to the forms. Your recommendation is only using forms in the way they have been used for a decade, *to a point*. You are injecting schema into indivdual form fields that require additional interpretation on the server, and that is **non-standard**. To respond to the "non-specific" nature of my solution that "must be interpreted by each individual browser" is a non-issue, given the ubiqity of proven frameworks like jQuery which abstract these issues away for you.
casperOne
@Spenser Ruport: Also, while jQuery is not standard, to completely ignore the fact that it acts as an abstraction layer in order to eliminate browser-incompatability issues is short-sighted, to say the least.
casperOne
@casper - If a browser doesn't support dynamic form control creation it doesn't support it. jQuery can't fix that. Remember "All abstractions are leaky abstractions". Do you think if your approach broke your client would accept "Well I did it the natural way." as an excuse? No. They want their apps to be reliable. That's what I'm recommending. The reliable, no grey area, it will not break way.
Spencer Ruport
@Spenser Ruport: You are trying to change the argument (this is the second time you've done that). `appendChild` and `createElement` have been around since the *first* DOM specification (http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-core.html). Even if you *aren't* using some abstraction, the fact is that there isn't *any* browser that doesn't support those methods, which are all the person who asked the question needs. If the browser isn't **standards-compliant** at least at that primary level, then it's not a browser that can be expected to be supported or used by anyone.
casperOne
@casper - But there are, obviously, browsers that don't submit these created elements' values.
Spencer Ruport
@Spencer Ruport: If that is the case, then those browsers are in violaton of a core aspect of the DOM specification, as appended elements are no different than ones that are in the HTML itself, and should be submit. Also, the fact that *this* user is having particular problems with this scenario *doesn't* mean that he is using a non-compliant browser. It is *more* than likely that he is making an incorrect call, resulting in the error.
casperOne
Come on guys. Malsup's form plugins is a great plugins that submit the form field's just like standard HTML form did (http://malsup.com/jquery/form/#faq). This plugins working well even the fields is dynamically added into the page after the `ajaxForm()` method is executed. Just make sure the new added field is still inside `form` open and close. My code run in all modern browser that me and my client use, everyone happy.
Donny Kurnia
A: 

I have no problems with dynamically added field in my application.

Make sure that the new field is still inside <form> and </form>. Make sure your tag structure is valid and balanced. Put the form open and close outside the block element, such as div and table to make sure that the new added field not fall outside the form tag.

Firebug will be your best friend, use it to inspect the added field and the AJAX request sent by form plugins.

Donny Kurnia
A: 

I would like to thank everyone for their help.

I am using jQuery 1.4.1 to append elements to a UL:

var file = "";
FilesToUpload++;
$("#UploadedFilesList")
    .show()
    .append("<li class='element001'><p>" + file + "</p><span class='element002'>x</span><input type='hidden' value='1' id='Attachment_" + FilesToUpload + "' /></li>");

I am adding and hidden element but I've tried using a text as well.

I've checked with FireBug and the elements are inside the .... I've checked and all the TAGS are closed properly. This is the script I am using to post the form:

$('#aspnetForm').submit(function()      {
     $(this).ajaxSubmit(options);
     return (false);
});

All the asp.net web controls are posted correctly; the problem is just with the dynamic fields.
I'll try to build a sample project to see if I've got the same problems. I've tried with different browsers and the results are the same.

Thanks

Alberto

vandalo
I've found the problem in my App.I forgot to put the attribute "name" for the hidden field (I just used the Id).I thought it wasn't necessary but it doesn't seem to be like that.Alberto
vandalo