I am working with force.com architecture that uses a lot of JavaScript client side. I need to cache some meta data across page requests.
As far as I'm aware it is impossible to cache JavaScript across page requests as the global name space will be reloaded. One thing I was thinking that could be done if I was in a Java EE architecture which is ugly but would word be to generate a MetaData.js file with all the meta data at runtime.
This file could be cached across requests and the only cost would be instantiated an object from a self invoking function which is cheap.
However, I can create a MetaData.js file at runtime in force.com so I was wondering is there anything else I could do?
IS there a reason why you can't store that data on the server? With PHP in a $_SESSION for example.
Related
I taught myself programming so my knowledge is very fragmented and now I have encountered a fragment I know nothing about. Sending and receiving Date. In addition I want to do it across domains. I know about the security policies that prohibit this but have read about some solutions. I still can't make sense of it in relation to my challenge.
What I want to do:
I want to build a plugin that sends data to my server when a function is called. The function is bound to an event listener.
this plugin contains of a little html-form and some js in the back. i want to send json or simular.
my questions:
I) how do I send data to an other server?
II) how do I receive this data? I know about parsing and dom but all I did so far is handle requested data. now this data is posted to my server-app without me knowing beforehand. the data is used to update a DB. the backend is coded in JS or python. I would prefer JS for compatability reasons.
III) how can I test the cross server connection on my local machine? especially without an active internet-connection?
I don't expect a complete guide or the code i need. just the resources and where to get the knowledge-chunks I need to build this.
Thanks a bunch in advance!
I) how do i send data to an other server?
You may use AJAX (or jQuery.ajax a more convenient way)
II) how do i receive this data? i know about parsing and dom but all i
did so far is handel requested data. now this data is posted to my
server-app without me knowing beforehand. the data is used to update a
DB. the backend is coded in JS or python. i would prefer JS for
compatability reasons.
As long as you send some data via AJAX, the browser makes a HTTP call and you could receive the data from server-side. Both JS or python would compatible with your client-side javascript and seldom do there have compatibility issue.
III) how can i test the cross server connection on my local maschine?
especially without an active internet-connection?
localhost and 127.0.0.1 is treated as different host and I usually use these to test cross server scenario. One issue of AJAX is that browser usually disallow Cross Domain calls unless you specify Access-Control-Allow-Origin headers.
I am currently having an idea where I want to save an image from a c++/openGL application on demand from a browser. So basically I would like to run the application itself on the server and have a simple communication layer like this:
JS -> tell application to do calculations (and maybe pass a string or some simple data)
application -> tell JS when finished and maybe send a link, text or something as simple as that.
I don't really have alot of experience with webservers and as such don't know if that is possible at all (it's just my naive thinking). And note: I am not talking about a webGL application, I just want to have simple communication between a c++ serverside application, and the user.
Any ideas how to do that?
Thanks alot!
Basically no matter what your language/framework you choose for your web server, you just need a interface that is callable from your browser JS, and you can do whatever you want in the server once it recieves the call.
Most likely any web service interface exposed from the server.
Just need to safeguard your server not to get DoS since it sounds like it's a huge process.
As far as I know, JavaScript (at least when embedded in HTML) is executed on your local machine and not on the server so that there is IMHO no way to directly start your server-application using JS.
PHP for example is executed on the server-side and so you could use e.g. the php system function to call your C++/OpenGL application on the server - initiated on demand through a web-browser.
When the call is finished you could then directly present the image.
Well you could always use the cgi interface to invoke your application
and have it save that image somewhere accessible to the webserver.
Then have your js load that via ajax.
Or make a cgi App that talks to the app and then serves a small
page with the pic in it.
[EDIT]
Answering the comments:
CGI is not complex to learn, it is mostly a simple convention
you can follow. I think it would give you the maximum of
flexibility. I don't know which php mods allow you to leave the cozy protection of the server-application and interact with other stuff on your server.
I am creating a Web Application using JSP, Struts, EJB and Servlets. The Application is a combined CRM and Accounting Package so the Database size is very huge. So, in order to make Execution faster, I want prevent round trips to the Database.
For that purpose, what I want to do is create some temporary XML files on the client Machine and use them whenever required. How can I do this, as Javascript do not permits me to do so. Is there any way of doing this? Or, is there any other solution which I can adopt in order to make my application Faster?
You do not have unfettered access to the client file system to create a temporary file on the client. The browser sandbox prevents this for very good reasons.
What you can do, perhaps, is make some creative use of caching in the browser. jQuery's data method is an example of this. TIBCO General Interface makes extensive use of a browser cache for XML data. Their code is open source and you could take a look to see how they've implemented their browser cache.
If the database is large and you are attempting to store large files, the browser is likely not going to be a great place for that data. If, however, the information you want to store is fairly small, using an in-browser cache may accomplish what you'd like.
You should be caching on the web server.
As you've no doubt realised by now, there is a very limited set of things you can do on the client machine from a web app (eg, write cookie).
You can make your application use the browser plugin Google Gears, that allows you a real clientside storage.
Apart from that, remember, there is a huge overhead for every single request, if needed you can easily stack a few 100 kB in one response, but far away users might only be able to execute a few requests per second. Try to keep the number of requests down, even if it means adding overhead in form of more data.
#justkt Actually, there is no good reason to not allow a web application to store data. Indeed HTML5 specifications include a database similar to the one offered by Google Gears, browser support is just a bit too sporadic for relying on that feature.
If you absolutely want to cache it on the client, you can create the file on your server and make your web app retrieve it. This way the browser will fetch it and keep it on the client cache.
But keep in mind that this could be a pain for the client if the file is large enough.
So, with HTML5 giving us local SQL databases on the client side, if you want to write a select or insert, you no longer have the ability to sanitize third party input by saying $buddski = mysql_real_escape_string($tuddski) because the PHP parser and MySQL bridge are far away. It's a whole new world of SQLite where you compose your queries and parse your results with JavaScript.
But while you may not have your whole site's database go down, the user who gets his/her database corrupted or wiped due to a malicious injection attack is going to be rather upset.
So, what's the best way, in pure JavaScript, to escape/sanitize your inputs so they will not wreak havoc with your user's built-in database?
Scriptlets? specifications? Anyone?
Once you entrust the computation entirely to the client, the game is over. Even if your scripts are bulletproof, the user can still load their own scripts locally (for a benign example, see GreaseMonkey) - and access the clientside db on their own, bypassing your scripts.
In my opinion, the only useful application of a client-side database with an untrusted client (which is to say, almost any client) is mirroring/caching parts of the main, serverside db - so that the client doesn't have to pull data over the network on repeated requests (If such clientside db gets corrupted, just invalidate it and load the data from the server again).
I'm not sure about HTML5 and local databases, but on server-side it's better to use prepared statements rather than escaping. I believe it's the same with databases on client-side.
Use prepared statements.
http://dev.w3.org/html5/webdatabase/#sql-injection
i think, Even if you sanitize your inputs on your javascript that will leave your system vulnerable to attacks. Also it would be redundant if you place an input sanitizer at your javascript and place another one on your php file.
Use Google's JavaScript Html Sanitizer available as part of the Caja distribution at:
http://code.google.com/p/google-caja/
This library can be used both client-side and server-side. I use it server-side in a classic ASP project running the library under the ASP JScript host.
I'm building an ASP.NET AJAX application that uses JavaScript to call web services to get its data, and also uses Silverlights Isolated Storage to cache the data on the client machine. Ultimately once the data is downloaded it is passed to JavaScript which displays in on the page using the HTML DOM.
What I'm trying to figure out is, does it make sense for me to make these Web Service calls in Silverlight then pass the data to JavaScript once it's loaded? Also, Silverlight will be saving the data to disk using Isolated Storage whether I call the Web Services with JavaScript or Silverlight. If I call the Web Services with JavaScript, the data will be passed to Silverlight to cache.
I've done some prototyping both ways, and I'm finding the performance to pretty much be the same either way. Also, one of the kickers that is pointing me towards using Silverlight for the whole client-side data access layer, is I need to have timers periodically check for updated data and download it to the cache so the JavaScript can loading when it needs to.
Has anyone done anything similar to this? If so, what are your experiences relating to performance with either the JavaScript or Silverlight method described?
Since Silverlight can handle JSON and XML based services, the format of the response is totally irrelevant. What you must consider, however, is the following:
1) Silverlight is approximately 1000 times faster than JavaScript
2) If your web service is natively SOAP based, Visual Studio can generate a proxy for you, so that you don't need to parse the SOAP message.
3) Silverlight has LINQ to XML and LINQ to JSON, which makes parsing both POX and JSON a breeze.
In a perfect world, I would go with Silverlight for the "engine", and fall back to JavaScript in case Silverlight is not available.
Greetings,
Laurent
Another thing to consider - getting your data in JSON format will be faster than XML and Web Services. JSON becomes a JavaScript object pretty quickly and doesn't have to be parsed like XML does. Personally, I'd go with JavaScript.
article: Speeding Up AJAX with JSON
Since JavaScript isn't multithreaded, I'm finding that using Silverlight to access/cache the data then pass it to JavaScript for display produces much better performance, while refraining from locking/freezing the browser so the user can keep doing stuff while the data loads.
Passing JSON-formatted data is in part faster because unlike an XML SOAP message, it doesn't require a SOAP header or any other miscellaneous info - it's just pure data. Thus, making the total size of the message smaller.