How could I save changes made to "contentEditable" sections back to original HTML file. Is this even possible?
I need to create a single html file that has sections for user changes. Using their web browser, I would like the user to be able to "save" the changes so that the original HTML file would actually be updated. This file might be stored on the user's PC, it might end up hosted on a server. Wherever it is, it needs to write the changes back to the HTML file.
EDIT:
Maybe some more details will help. I am looking to create a dynamic character sheet for all the RPGs I GM. I have used doc sharing services, but the interactive and dynamic nature of HTML+javascript offer more of what I need. Designing the file is easy enough. I just want players to open it in a web browser (even if stored on their desktop), make notes and edits, and then click a "save your character" button that will write the elements they changed back to the original HTML file. If there's no conceivable way to do this, that ok, I would just like some definitive info.
The file lives on a server somewhere, and the browser retrieves the files from that server, after which you can mess with contentEditable content, so to get the changes propagated to the original files, you'll need at least two things:
an event handler on the element(s) that have the contentEditable property, so that you can hook into their content modifications.
an API on the server that lets you tell it to update file X with content Y
The basic approach would be:
load HTML from server in browser
click on element with contentEditable property and start editing
finish editing, and have the element's javascript handler kick in (see https://stackoverflow.com/a/14043919/740553 for how to do that).
take the current URL, and the route to the element you just changed, and its new content, and then POST that to the server. This requires that:
the server is running an accepting route that listens for POST data on some route like ..../changepage (without accepting input from just anyone, of course), and that:
can take a POSTed filename, element path, and content string, opens up that file, finds the element in question, replaces its content, and packs it back up into a new file with the same filename as before.
This is, to say the least, extremely fragile and prone to bugs as well as abuse. There are better ways to do this, and pretty much all of them rely on having a content server, and a page that loads in content for very specifically editable elements from your content server, so that showing, editing, and saving content all happens to "one thing" instead of to elements that need to resolved in .html files based on their element path.
Or, making things even easier, using something like React to make most of that virtually instant. Although, of course, you'll still be left with writing your server such that it can serve up content, and accept modification requests.
Unfortunately for you, what you want to do is actually extremely hard to do well, as well as securely.
Related
I am having a template structure in which there is a single HTML file inside which related HTML & JS files are loaded (using AJAX).
Section are loaded as per User's activity(Page never reloads which kind of is good for user experience).
i.e.
User clicks a menu say "Profile",which causes:
jQuery.load method is used to load a file "/some/path/profile.html".
jQuery.getScript is used in .load() callback to include js files like "some/path/profile.js",The profile js has event handlers for the profile page along with related business logic.
This happens for each menu item/section of the application like "Profile","Files","Dashboard" etc.
It works fast but I am not sure if this is the optimal way to carry this out.
If a User consequently clicks the "Profile" button twice,would the browser
clear up the earlier loaded resources(profile.html,profile.js) first before
loading it afresh?
When user visit a new section say "Dashboard" after visiting "Profile",would
browser again clear out the resources of Profile before loading for
Dashboard?
If not than could this cause some memory related issues with the browser?I searched about this but did not see any related scenarios.
P.S: In this structure often some HTML part is stored in a JS variable to be used further. I read somewhere in SO that it is a bad practice to do so but I was not able to find details regarding it. I assume it should not be a -ve point if the developer is well versed & storing HTML in a JS variable should not be any problem.
Here's my understanding on this:
You have to make sure that you don't send request if clicking on same button at your end.
(Forgot about we are dealing with scripts/HTMl) No caching in the picture
Clearing out resources?, yes it will be removed from DOM if appened in same section. But i guess it's necessary if same placeholder is used for each section content.
If you know that everytime each section will return same template again, you can create a local cache at client side just like memoization to see if template already exists.
Hope this helps.
I am creating an extension to track changes that have been made to any JS or CSS file of a page via DevTools. At will, I want to then push those changes - as a whole file if necessary, but changed-elements only would be nice - for the purpose of sending directly to my server to be handled.
My question pertains specifically to this:
Image of DevTools Changed Tab
Can I, via an extension, hook into the Changes tab in order to take those changes and process them? (Or is there a similar process that can handle this manually?)
This ideal output I'm hoping to find or be able to get to would be something like this:
{
fileName: nameofeditedfile.css,
change: [SomeComplexObjectWithTheSpecificChanges]
}
I'm aware that I can save these files locally and then do as I please with them, but for multiple reasons that's definitely NOT the route I want to go.
Let me know if I need to include a more specific example or other details!
I have static html files automatically generated and saved in S3. Sometimes a file reaches 2mb size. Is it possible to use javascript to fetch a part of an html file, display it and when user reaches bottom of page, fetches next part and so on?
The XHR Object provides a method for setting up custom HTTP headers. So, you could try setting up the Range header in order to fetch just a part of the static file.
You will have to account for the chunk not being proper HTML, since you're cutting an arbitrary slice of the file, so you will have to implement logic to properly handle the results if you intend to display them.
I'd love to see you implement it this way, instead of leveraging the chunking to the server as is the usual case.
This is totally possible - the idea is that you can pre-render "fragments" on the server, where each fragment represents a "subpage" of N articles or what have you. You then render the page with 0 (or 1) fragments, and send it to the client. When the client scrolls to the bottom, you simply request the next fragment (with AJAX) and append it to the end of the previous fragment. Keep doing this indefinitely.
The key point to understand is that each fragment is rendered statically on the server. Though the fragment may not be a complete HTML page in and of itself, they are "infinitely appendable" into an existing page. Part of the fun of HTTP (as opposed to full HTML) is that you don't have to have a full HTML page for any fragment to be successfully served; you can think of the HTML as "boilerplate" that surrounds arbitrary chunks of additional, non-well-formed HTML (that become well-formed when placed inside your boilerplate).
Since AJAX is based around HTTP requests, you can ask for any arbitrary content. Heck, you can ask for your own custom markup as long as the Javascript that "catches" the response can format it in a way the browser can understand - namely, HTML, CSS, and JavaScript.
The question is not how can I do infinite scrolling, it's really how can I load parts of a large file at a time, loading more as the user scrolls down. I'm not sure if that's possible so here's another solution:
Store the large file in smaller chunks, lets say 1.txt, 2.txt ... Then, on your page, as you scroll down, you can load the next N.txt. (doesn't have to be txt, by the way). Just make sure your wrapper (the file that the user actually sees) has complete HTML and the chunks that it's loading is just the content. Meaning the chunks shouldn't have like a </body></html>... that should be in the wrapper file.
Here's how to fetch a file using AJAX or using jQuery. All you really have to do is keep track of what part you're on so you can load the next one. If it doesn't exist, then you've loaded the entire file.
I'm trying to create an infinite scrolling page - somewhat similar to tumblr archive pages like this. I understand the concept that I have to load the content with a server call, but I don't know how to achieve this "animated loading" design like in Tumblr.
I don't want to know the exact code, only the overall concept of the solution. So what would be the best practice to do things like this?
What should I get from the server: a bunch of JSON data or a full HTML page?
I have tried to decode the Tumblr page above, and I saw on my network traffic page that in every scroll event there is a POST request which returns a full HTML page which has its own JavaScript and CSS content!
I guess that the animation logic is inside of this JavaScript content.
But I have 2 questions about this method:
When I get the full HTML page from the server (which contains the new page as well), how can I throw the currently displayed HTML document away and I set the new one?
Isn't it too bad from a performance point of view to return a full HTML document every time? Because the full document would contain the results of the previous "pages" of the archive as well. Or do I think wrong?
Wouldn't it be better to return a JSON-only result from the server? (It have to be parsed on the client but it would be more network traffic-friendly, I guess)
If it would be better to return a JSON, why the Tumblr works on the other way?
It surely is beneficial to not send lots of data that will not be used.
However, if your server has a lot of resources, you can do some preprocessing on the server instead of client. This means, instead of JSON, you can send an HTML snippet, the block that will be added. Moreover, if your HTML structure is very complex, you don't want to implement it twice; once in HTML and once in Javascript.
The way Tumblr works might be because they don't want to add much more to the server code base, and instead offload the work to the client. Since only one page is sent at a time, the overhead is constant w.r.t. the number of pages. The client can just take the full HTML, find the corresponding element with DOM manipulation and place it somewhere.
In fact, that is what the AutoPager plugin does: It learns the "next" link and the page body from the user, then fetches additional full pages from the unsuspecting server and inserts their content into the page (and reads the next page url).
In short:
The benefit of JSON is low bandwidth usage.
The benefit of HTML snippets is low demands on client processing power, and little to no code duplication.
The benefit of full HTML is that the server needs not care if it's serving the first page or any other.
Now, this requirement may seem weird. But i would like to know how to achieve this?
I am having an HTML file, which is having few input box, check box, radio button etc. I would like to retain the changes a user [ actually i ] performs on this page. Like if the user has ticked a checkbox then next time anybody open that file should see that checkbox as ticked.
This thing can be done easily using HTTP cookies. But i don't want to use cookies.
The answer can be as simple as "No you can not do that" :)
Edit
That's the problem with not phrasing the question correctly.
I guess i can't use DB as if i will send my HTML page to someone then he/she will not be able to see my changes. I want my changes to be reflected on other systems also. [ thats the reason i was not going for cookies ]. Other solution what i was thinking was, using FileSystemObject. Any other solution ? again the answer can be "No you can not do that" :D
You could bind the change events of your form elements to an AJAX submit, log the submits to the db and then on any page load grab the latest states from the db for rendering.
Edit
If you want these changes to appear "simultaneously" for other users then you could use jQuery polling to update the page - have the page periodically poll the server for the latest state.
Having said that, if you give them a server link and not the actual file they will see your db changes.
However, it sounds like you want to actually send the file (not send someone to a web server) in which case you could do something like one of these approaches:
Your PHP/whatever file (can possibly even do this with javascript) outputs a HTML file with appropriate checked="checked", selected="selected", value="blah" etc. You send this file.
Your PHP/whatever file outputs a static reference file. Your HTML file has javascript referencing and using the values stored in this file. You send both of these files around (although value updates only require a changed static reference file).
I sounds like you want to change the actual file using Javascript - this should be rather difficult. Javascript was designed from scratch as a web scripting language and as such it doesn't have any built in file/IO functionality.
What you can do in Javascript is load ActiveX objects and plug ins. How this works depends a lot on which browser you're using. For instance in IE you could load an ActiveX object (written in VB or whatever) that could edit your file:
var fileWriter = new ActiveXObject("My.FileWriter");
fileWriter.Update("myFile.htm", "inputName", "newValue");
You'd have to write your FileWriter utility though.
Alternatively you could use HTML5's new data storage stuff - but then you're still limited on browser.
You need some method to identify the user when he or she visits again. A browser cookie is useful, because it is stored on the user's computer, which serves as identification. The other serious option is to store the user's preferences in a database. This would, at least, require a server-side language. In addition, you need some way to identify the user, such as username, or, less reliably, IP address.
I hear other options may exist in HTML5, but I don't think those can be used seriously at this time. You can read about it here in Offline Web Applications. It seems to me like something very similar in spirit, although much more powerful, than cookies.