I'm currently working on a concept for a heavy AJAX based web application.
The communication between client and server should be based on JSON, not plain HTML. So I was wondering how to store the templates for the seperate sections and how to get them by the javascript.
For example I have an multiple image uploading form. The user submits and with JSON response I get back title of the album and the src paths of the images. I want to show the complete photo stream from that JSON.
I never built something like I want know, so I'm trying to be prepared before actual programming comes in.
Are there good JS templating libraries? Can I load the templates after the AJAX call or do I need to load every template on the first page load?
Load the templates on demand. This saves you bandwidth, memory space as well as HTTP requests.
You can load them as plain HTML or as a bunch of templates, wrapped in JSON.
Cache them. You should have some sort of caching logic to check first your local cache (localStorage, a JS object on the page etc.) if the template exists. Otherwise, request it from the server.
I suggest using Mustache for templating. As for storage, I suggest using PersistJS. For caching logic, build one yourself.
Related
I have a book in docx format (about 25,000 words) and I want to display about 400 words at a time on my webpage. In Python, I have an algorithm that separates the text into pages and stores that in a dictionary; however, the frontend uses JavaScript.
I have tried to export the Python output as a txt/json file, but it seems that JavaScript doesn't allow automatic file uploading and instead requires the user to upload the documents which won't work for my situation. So, do I have to store all of the text (25,000 words) in an html document and then run a JavaScript version of the Python algorithm on that and then save it into local storage or some JavaScript container?
I want to avoid using a web host for this since I don't think it is necessary.
You would typically build a web API for retrieving data, you would use a database/flat file store for storing the data and the frontend would form the presentation part. Depending on your usecase and if you are not familiar with databases, I'd suggest as a first step you could just store the pages as simple files on the backend.
So, your data i.e. the pages of the book would be stored in text or JSON. Your backend service(which can be in Python or JS or pretty much any other popular language) would have APIs that facilitate retrieving these webpages and your frontend(HTML + CSS + JS) would be responsible for capturing user input and requesting data from the backend service.
So, the flow for reading a page becomes -
The user opens the frontend, which would comprise of HTML + CSS + JS
The frontend retrieves a page from the backend API
The backend API reads the page on your machine and returns it
If the only reason you don't want to use a backend or host is because it is not required, in my opinion what you are trying to build would typically require a backend service since you'd generally want to have control of data so that you can have other mechanisms for auth, updates to the pages, etc.
I am building a site in node.js that allows users to have a custom page that can be edited in a dashboard. I would like this dashboard to have a live preview (similar to the way Shopify does it) in an iframe, where every time the user makes changes, the preview updates with their changes (i.e. background image or header text). The options are saved in the users document in my mongodb database, and rendered via Liquid. What is the best approach to achieve this? Should I store their options in a temporary json file? Thanks!
I wouldn't build it entirely on Node.js
I would rather use the power of the modern client-side Javascript and move some logic there with persisting some of the data coming from the server. This way I can lower the number of requests and make my script more flexible.
Two libraries can help in these tasks:
Socket.io for fast communication between Node.js and the browser.
PouchDB for client-side data storage and CRUD operations.
When NOT using AngularJS, I create a web site that responds to /mysite/users . It returns an HTML page with user records filled within a table-like display.
I wish to try an AngularJS approach. I somehow load the web page, and that page's onload() calls /mysite/users, which returns merely a JSON list of users.
The "somehow" part is what bothers me. So far I'm reduced to first calling /mysite/showUsers. This downloads the HTML page which then itself calls /mysite/users.
Likewise, when editing with AngularJS I think I'll have to call /mysite/userEdit/1 which on load calls /mysite/user/1.
I think I'm missing something. Can I get a clue?
Thanks,
Jerome.
As you've noted, the AngularJS approach is not to load pre-rendered HTML from the server, but instead load a list of JSON data and rely on AngularJS directives to populate the DOM client-side.
A concrete example in your case would be a page which loads an Angular module that fetches a JSON list of users from /api/users, and leverages the ng-repeat directive to populate the data into the page right in the visitor's browser. Here's a JSFiddle I found that illustrates how you'd accomplish this.
It's all a matter of where the data gets inserted into the HTML; It can happen on the server-side or the client-side, and Angular favors the latter. (This is not to say you can't load pre-rendered HTML from the server, but you would be working against the way AngularJS is designed to be used.)
I've had trouble describing what I want to have happen. Perhaps it is because it goes against the grain of Angular.
My server responds to /user/1 with the JSON for user #1. For the browser to deal with it, I must have a web page already there that can display this JSON. Chicken and egg style, how do I get this edit web page into the browser? My classic example is using /user to list the users and having a link on each user to edit it, such as "/SOMETHING/1".
In the meantime, I've decided to go with /user/edit/1. That will cause the server to render an HTML file, using server-side scripting to insert a phrase that on window.onload() fills the skeleton HTML with the result of /user/1.
Thanks, Collin, for replying.
I'm starting to build a UserControl that will live on some SharePoint 2007 PageLayouts. The UserControl's purpose is to display a map of several locations based on the name of the page. So what it needs to do is take the page name, go query a SharePoint list for the relevant collection of geo coordinates, then load them on the map. I've never really done much client side scripting beyond simple modification of elements and academic jquery AJAX calls. So I'm trying to understand what the common practices are for passing data around.
I've seen a lot of stuff online talking about AJAX calls to page methods, which is out because this is a user control. The alternative looks to be ajax calls to a web service. I've built web services before but for consumption by .NET clients. Is this still the way you set up a .net web service to be called by scripts? What about security? What if I only want my page or my site calling the web service and not the general public?
In this case, I'm not sure a service would even be necessary. Can I just retrieve the data and put it on the page during the initial request? Something like json serializing the coordinate collection in the code behind and writing it to a hidden field for javascript to pick up?
There are several ways of passing values from an usercontrol to javascript.
ScriptControl:
Allows you to include a client behavior for your web control. See some Links below:
Creating Script Controls
ASP.NET: Create AJAX Server Controls using the ScriptControl base class
Asp.Net Ajax ScriptControl Tutorial
RegisterStartupScript and RegisterClientScriptBlock:
Allows you to include client side script blocks on the page. See some Links below:
Working with Client-Side Script
Injecting Client-Side Script from an ASP.NET Server Control
HtmlGenericControl:
Nothing stops you from creating a script tag dinamically and inserting all your javascript logic into the InnerHtml property. It could be done during the initial request.
Example:
HtmlGenericControl script = new HtmlGenericControl("script");
script.ID = "script";
script.Attributes.Add("type", "text/javascript");
script.InnerHtml = "alert('Hey');";
//Insert the script into some asp:Panel
panel.Controls.Add(script);
Reading this 4 years later, I can tell my past self this:
Yes, just include the json on the page, hidden for JS to pick up. But be aware that this increases the size of your response that must be downloaded by the client browser. Not only does this take more time, but it uses up more of a mobile user's expensive data. If there is a lot of data and some may not be used, retrieving the data, as needed, from a web service may be a better option.
REST services are a common solution for responding to AJAX requests. There's not much you can do to secure your data from anonymous users if you want to allow client side scripts from anonymous users to get at it.
I'm working on a new web app where a large amount of content (text, images, meta-data) is requested via an Ajax request.
No auth or login required for a user to access this.
My concern is that you could easily lookup the data source URL and hit it directly outside the app to get large data. In some ways, if you can do this you could probably scrape the static HTML pages elsewhere that also have this content.
Are there any suggestions on methods to obfuscate, hide, or otherwise make it very difficult to access the data directly?
Example: web app HTML page contains a key that is republished every 30 min. On the server side the data is obfuscated based on this key. In order to get the data outside the app you'd need to figure out the data source but also the extra step of scraping the page for a key every 30 min.
I realize there is no 100% way to stop someone, but I'm talking more about deterrence.
Use sessions in your webapp. Make a note (e.g. database entry or some other mechanism which your server-side code can access) when a valid request for the first page is received and include code in the second page to exclude the data when processing a request without a corresponding session entry.
Obviously the specifics on how to do this will vary between languages, but most robust web platforms will support sessions, largely for this type of reason.
If you are wanting to display real-time data and are concerned about scrapers...if this is a big enough concern, then I suggest doing it with flash instead of JS (AJAX). Have the data display withing a flash object. Flash can make real-time send/receive requests to the server just like AJAX. But the benefit of Flash is that the whole stage, data, code, etc.. are within a flash object, which cannot be scraped. Flash object makes the request, you output the stuff as a crypted string of code. Decrypt it within flash and display from there.
"Are there any suggestions on methods to obfuscate, hide, or otherwise make it very difficult to access the data directly?"
Answers your own question because if the data is worth getting it will be obtained because you are obfuscating is merely making it harder to find.
You could in the server side script processing the ajax and returning the data check where the request came from.