Is it possible to include elements in the DOM after it is loaded and ready?

Asked

Viewed 1,446 times

7

I have a table that, depending on the amount of an X value, inserts a set of attributes at the bottom of the page (fields). These elements have events assigned to them. But that’s not the point.

Problem is: how do I add the elements after the DOM is loaded (the moment I fill the value of X), when I close the "Back" button, after any operation, and return to the same screen, the values included in these added fields later do not have their values reloaded and not even the fields themselves.

EDIT
Setting:
I have a form that generates additional fields, based on other fields already present. These fields vary in size, so I can’t include them with "display:None" and simply show them later.

Then my user fills in the form, generates the additional fields and presses the "Save" button, but the form does not pass validation.

In this case I could (should) redirect the user to the previous screen.
Then the problem arises: As the additional fields were generated after the DOM was loaded and rendered, they do not appear when the user returns to the screen, because the browser takes this information from the DOM*.

I imagine there must be another way to do that I said, but that was just to give you an example. I really need to include in the DOM elements added later.

Does anyone know if it is possible to add these elements to the DOM even after it is loaded?

*This information that he carries from DOM I got from sources "unreliable", by comments on a blog.

  • Just to better understand your problem. You need the values to persist in the table?

  • That’s it! When I leave the page and come back, would you like them to still be (return to) there.

  • Your question was not very clear. I had the same doubt as @Luizpicolo, you could edit it at this point.

  • I also couldn’t figure out exactly what your problem is.

  • I edited the question, it may help to better understand the problem.

5 answers

6

I think the point is not to add values in the DOM, because you said yourself that you are doing this, is to manipulate them so that they recover their state when browsing the page.

One way is to save the states of the elements you added to your browser, either via Cookie (is not a good solution) or via Web Storage (cooler this one).

Then when loading the DOM, you can check that the data is saved to re-add the elements into the DOM as needed and change its attributes.

But to answer the question, yes it is possible, example:

$('body').append(document.createElement('div'));// vai adicionar uma div no body

// nativo:

document.body.appendChild(document.createElement('div')); // mesma coisa só que sem jquery

EDIT, because of the author’s comment:

If you have a table and want to store it completely, not to request again to the server, a solution not very elegant is to turn the content into string, store in a Storage (preferably because of the size) and then do the evaluation at the time of putting back, example:

Saving content from the table:

localStorage.setItem('minhaTabela', $('#minhaTabela').html());

Retrieving contents from table:

$('#minhaTabela').html(localStorage.getItem('minhaTabela'));

Check if the user has support for localStorage and if there is value saved in the item you will store the table data.

  • In this case, you are adding a DIV. Can I do a whole HTML table? Why, in my implementation, a php function mounts the entire table, and then only includes within a DIV with id. It would be possible, in this case?

  • Yes it would be possible. I will edit the answer to talk about that case then.

5

  • "persist in table" != "Save to bank", right?

  • 1

    Yes, persistence in this case to keep, but if kept in the table.

  • I edited with an example

  • ... is that I spent a lot of time in the C#’s of life. They usually call say that persistence == record.

  • Webforms becomes a bag of so much unnecessary persistence sometimes.

5


I really don’t like the idea of going back in history and keeping the new form settings as generated. This eliminates the user’s option to go back and fix a wrong input that may have generated their own current form configuration.

I see two solutions:

(1) My favorite one - always work forward, without worrying about browser history Handling: Use a form validator like Webforms2 (https://github.com/westonruter/webforms2). I have used in the past and is very versatile. Follow tutorial: http://goo.gl/gmo2H . Easy to use in combination with modernizr.

(2) The one I don’t like - using Web Storage with fallback in Cookies. This solution is worse because you need to check if Web Storage is supported. For previous browsers implement a fallback saving the form configuration in memory through the use of Cookies. Who does not have updated browser generally does not like so much internet and like less when the websites do not work properly with their outdated browsers. Still, not everyone has Cookies enabled. Due to their excessive use, they have already been considered the villains of the internet and many old people still have the habit of disabling Cookies.

However, my advice is: Keep good practice. Form must be validated at the time of sending, not later. If the submission fails, the user should not be redirected to any page, should remain where he is and correctly fill in the highlighted fields. A correct approach would validate the information before browser/bancodedata communication.

I don’t know any AAA site that would redirect a user to another page while the form has not been completed correctly and in full.

Good Luck!

4

In that case I could (should) redirect the user to the screen previous.

I strongly disagree that I should redirect the user to the previous screen if it means what I understand - go back in the browser history - type history.go(-1) (which is equivalent to the browser "Back" button).

That, in my opinion, would be a ghastly gambiarra.

I think you could do one of those two things:

1st option - after processing the form on the server, and the same not validate, is redirecting ahead or not (via header Location to the same URL if you want to avoid re-sending the data from form if the browser reloads the page), you will need mount the modified DOM from the data of request on the server side, that is, instead of making the DOM change on the client side, using Javascript / jQuery, you will have to send the form back with the already changed HTML, from the server.

second option - validate the form via Ajax, that is, you avoid the Submit standard, and makes a $.post (or equivalent) to send the form data by Ajax. If not validate, beauty, the DOM remains there, mounted. If you validated and did what you had to do, then you change the page via Javascript with window.location or updates it in some other way. The important thing here is to process the return of the Ajax call and take appropriate action in case of error (user message) or success.


That said, I remembered the Mantisbt, one software which I like, but which in certain conditions tells the user to return to the previous page when sending a form error. In case, it works smoothly because there is no manipulation of the form by Javascript. In fact, it is an application that has existed since "rotate with Javascript disabled" was a requirement... :-)

In your case, if you need even rewind in browser history, the way is to use web Storage as the staff spoke. However, be aware: Internet Explorer 7 and earlier do not support web Storage. The alternative would really be cookies.

But why take steps back when you can walk forward? Using post via Ajax you are taking a little step forward towards the world of SPA (Single Page Application)!

1

Is it possible to validate the data without sending the form? Through the evt.preventDefault()?

Another way would be to take all the information and do the treatment of it in the page Load. Send the already filled data, validate and recreate the elements, you can create a javascript that reads a JSON with this information, which can be placed through GET and go recreating elements. Or a page load routine to validate data when reloading.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.