I have a JavaScript document which I've created with some complex functionality which relies on a couple third party JavaScript libraries being included.
My goal is to have it so that GWT can interact with my script and vice versa. I've tried to create a GWT wrapper which uses JSNI but had problems trying to get communication back from JavaScript (Embedded in my index.html - which is blank apart from the code to inject GWT) to my GWT application.
For my second attempt I've created a servlet on the GWT server side which I can communicate with via JSON although this looks like it will work it seems quite hacky having to rebuild many of the framework technologies which GWT has already fixed.
So my question is what's the easiest way to get two way communication from my JavaScript to GWT without the initial call coming from GWT (If possible)?
Related
Use case
I've got an existing project developed in C# using WinForms with custom controls for the GUI. We are amazed by the approach to write GUIs using HTML/CSS/JS and we are looking for the best way to write a GUI for our desktop application using the above mentioned languages. We only need to support Windows devices.
My worries:
It doesn't take long to come across recommendations using electron-edge. While I am not so worried to get everything working, I am worried about:
Debugging my C# code (I still want to be able to start my whole application right from VS and debug it look I am used to it). I read that I would need to attach to the node.js application in order to debug my C# code afterwards. Since the whole program language is written in C# that sounds like a pain?
As far as I got edge will let it run as just one process. Can I consider the electron application as an own thread which would still run while my C# code is stuck somewhere?
My option:
I am still positive I want to write my desktop GUI with HTML/CSS/JS. What I considered instead of using electron-edge is writing an own electron application which does communicate with my C# backend using named pipes. I wonder if there are larger roadblocks why I wouldn't want to do this and use electron-edge instead?
My question:
I would like to get feedback for my two concerns mentioned above and I also would like to get input about my option to create the GUI as own electron process, so that I have two processes (GUI+Backend) when someone runs my application.
Electron.NET may be a option for you. You can write c# code with electron.
You can do it in many ways
1) COM. Create C# COM DLL. Create wrapper functions for the DLL using N-API (Native node module) or use FFI. You can access the functions from JS.
2) Create a .Net web server and include your functions as REST endpoints. From UI make http request to communicate (Clear separation of UI & BEnd)
You can checkout my github repo for a few alternatives to electron.
I think a most import question would be how your frontend interacts with the backend? Is there any notifications need push to the frontend?
WebSocket could be a good option for two ends communication.
Is it possible to embed Gecko in Python so that I can display HTML documents. And then possibly create custom Javascript bindings so that, I can call my own Javascript functions in the HTML document that will do some task that are not normally allowed in the browser, like making system calls. This will be done by the underlying python program.
There are a variety of ways to do this, actually. First, are you using another GUI library (e.g. wxPython, Tkinter, PyGTK, etc.) and you want to embed Gekco into a window that you create in one of those frameworks? i.e. Are you trying to embed a Gecko frame into a Tkinter (or wxPython, or PyGTK, or...) window?
Is using ONLY Gecko for the GUI a viable alternative? If so, you might want to take a look at XUL (and xulrunner). Gecko can interface with the outside world via XPCOM, and there is some integration of Python with XPCOM (see pythonext at Google Code). So, it's possible to write a mixed application where the UI elements are described in XUL with active javascript and signals are sent to/from the UI and your python code (which runs locally and can execute arbitrary system calls, etc.)
Along the same lines, but somewhat more straightforward, you can create a python script that launches a xulrunner app AND a locally running webserver. The xulrunner app hosts the GUI, along with active javascript code, while your locally running webserver executes arbitrary python code (including local system calls). I've used the ("batteries included") BaseHTTPServer many times to do something similar and I'm confident that you'll find it relatively straightforward to do so.
I have read a great deal of discussions about javascript templating and Search Engine Optimization. Still, I haven't found a satisfying answer to the question (either poorly-documented or outdated).
Currently I am looking into handlebars.js as a client-side template solution, because I love the possibility to create helper functions. But what about indexing for search engines? Does the bot index the generated content (as intended) or only the source with the ugly javascript pseudo-variables? I know that there are lots of threads going on about this matter but I feel that nobody does exactly know the answer.
If engines like Google would not index these templates properly, why would one bother using this for public websites?
Another question within this context: Is it possible to render Handlebar.js templates on server side and then present them onto the client side? Obviously to avoid all this SEO discussion.
For dom crunching client side, most web bots (i.e. Google and others) don't interpret js on the fly and parse newly rendered content for indexing. Instead Google (and now Bing) support the 'Google Ajax Crawling Scheme' (https://developers.google.com/webmasters/ajax-crawling/docs/getting-started) - which basically states that IF you want js rendered dom content to be indexed (i.e. rendering ajax call results), you must be able to:
Trigger the async js rendering via the url using hashbangs #! (i.e. http://www.mysite.com/#!my-state), and
Be able to serve a prerendered dom snapshot of your site AFTER js modification on request.
If using a client side MVC framework like Backbone.js, or Spine - you will need to provide this service if you want your web app indexed.
Generally this means you intercept a request made by the web bot (explained on the link above), and scrape your side server side using a headless browser (i.e. QT + capybara-webkit, HtmlUnit, etc.), then deliver the generated dom back to the requesting bot.
I've started a gem to do this in ruby (now taking pull requests) at https://github.com/benkitzelman/google-ajax-crawler
It does this as rack middleware using capybara-webkit (and soon phantomjs)
I do not know about Handlebar.js, but for my understanding SEO have some problem with CONTENT in JAVASCRIPT. Make sure your content is visible to Search Engine (use a spyder simulator for some test). Avoid spyder traps generally would be the way to go. Hope it could help you.
Search engines don't run JavaScript, so if you want to have your content indexed you'll need to render your templates on the server as well. You can use handlebars in Node (server-side JS) to render your template there when the page request comes from a spider. It's more work but it's possible. Github, google plus, and twitter all do something similar.
You could use Distal templates which puts the templates as part of the HTML for SEO.
See Spiderable for a temporary solution Meteor project (which uses Handlebars.js) uses for SEO purposes.
http://docs.meteor.com/#spiderable
Does the bot index the generated content (as intended) or only the source with the ugly javascript pseudo-variables?
Neither, because indexer bots don't run JavaScript and you don't serve up templates as HTML documents.
Build a site that works without JavaScript, then build on top of it.
I'm developing a jQuery-based pivot table.
The goal is not a web app but a desktop-based application (C++). In my idea, data is retrieved by the application from the database, then passed to a html page and then showed through the pivot-table plugin.
There is no web server and the web page containing the plugin cannot access to the database.
So, how to pass data in an efficient way? I've seen other questions here on SO around this matter, but I think we're in a different scenario. Of course I can write the data in a txt/xml/js file, but I've experienced that for huge amounts of data, writing down files is costing a lot.
If you don't want to add support for the http protocol to your application, and you don't want to write to additional files, then IMO your best bet is to create a wrapping http server for your application. Then the javascript page can access the running wrapper which can talk to your "real" application.
You could create such a server relatively easily in python using the twisted framework, ruby using rails and the bundled webrick server, or the v8 Javascript engine node.js. (I'm sure there's dozens of other options out there too)
Which of there would be best for you will depend a lot on which languages you have experience with and what your deployment requirements are (supported OSes, existing installed applications, installation size, license terms on your software etc.)
Do you have a specific framework for your desktop app ? If you use Qt for the GUI, you can also integrate javascript quite easily.
http://efforts.embedded.ufcg.edu.br/qt/?p=84
You might be able to use named pipes to pass data to a static page.
It might also be better to just make your c++ program into a simple web server which opens a port, and have it generate the web page when the user goes to http://localhost:8080.
I know you can just use CSS to hide the DIV or Silverlight Plugin, but is there a way to instantiate a Silverlight Component/App using JavaScript that doesn't show any UI element at all?
There is alot of great functionality in Silverlight, like MultiThreading and compiled code, that could be utilized by traditional Ajax apps without using the XAML/UI layer of Silverlight at all.
I would like to just use the standard HTML/CSS for my UI layer only, and use some compiled .NET/Silverlight code in the background.
Yes you can, and some of the reasons you make makes perfect sense. I did a talk on the HTML bridge at CodeCampNZ some weeks back, and have a good collection of resources up on my blog.
I also recommend checking out Wilco Bauwers blog for lots of detail on the HTML bridge.
Some other scenarios for non visual Silverlight:
Writing new code in a managed language (C#, Ruby, JScript.NET, whatever) instead of native (interpreted) JavaScript.
Using OpenFileDialog to read files on the client, without round-tripping to the server.
Storing transient data securely on the client in isolated storage.
Improving responsiveness and performance by executing work in the background through a BackgroundWorker or by using ordinary threads.
Accessing cross-domain data via the networking APIs.
Retrieving real-time data from the server via sockets.
Binding data by re-using WPF's data-binding engine.
Yes. I think this is particularly intriguing when mixed with other dynamic languages -- but then, I'm probably biased. :)
Edit: But you'd need to use the managed Javascript that's part of the Silverlight Dynamic Languages SDK and not the normal Javascript that's part of the browser.
Curt, using Managed JavaScript would still require you to have some Silverlight/XAML display layer being visible on the page, correct? Is there a way to entirely get rid of any Silverlight/UI element from being displayed?