Well, can they? Like jQuery using a fadeIn function for something on a C++ app, can it work?
I think you are confused about what runs where.
jQuery usually requires a browser with a Document Object Model to run.
While this is something a C++ application could probably, theoretically, provide somehow, it's not really practical.
You want to investigate UI and effects libraries native to C++ rather than JavaScript libraries.
What do you want do achieve and most importantly, on what platform?
It would require your C++ app to contain both a JavaScript interpreter and a HTML DOM (because that's what jQuery operates on to do things like fadein effects).
Such C++ apps exist - they're called web-browsers. I suppose you could embed an open source web engine like Webkit in your app, but at that point you'd basically be developing a webapp and might as well drop the C++ part altogether.
If your C++ application use WebBrowser control for example to display a web page which use jQuery.fadeIn then you can "combine" both technologies.
Nevertheless I would more see that jQuery.fadeIn will work parallel to your main application and they will not work really together.
Related
I would like to load a DOM using a document (in string form) or a URL, and then Execute javascript functions (including jquery selectors) against it. This would be totally server side, in process, no client/browser.
Basically I need to load the dom and then use jquery selectors and text() & type val() functions to extract strings from it. I don't really need to manipulate the dom.
I have looked at .Net javascript engines such as Jurassic and Jint, but neither support loading a DOM, and so therefore can't do what I need.
I would be willing to consider non .Net solutions (node.js, ruby, etc) if they exist, but would really prefer .Net.
edit
The below is a good answer, but currently I'm trying a different route, I'm attempting to port envjs to jurassic. If I can get that working I think it will do what I want, stay tuned....
The answer depends on what you are trying to do. If your goal is basically a complete web browser simulation, or a "headless browser," there are a number of solutions, but none of them (that I know of) exist cleanly in .NET. To mimic a browser, you need a javascript engine and a DOM. You've identified a few engines; I've found Jurassic to be both the most robust and fastest. The google chrome V8 engine is also very popular; the Neosis Javascript.NET project provides a .NET wrapper for it. It's not quite pure .NET since you have a non-.NET dependency, but it integrates cleanly and is not much trouble to use.
But as you've noted, you still need a DOM. In pure C# there is XBrowser, but it looks a bit stale. There are javascript-based representations of the entire browser DOM like jsdom, too. You could probably run jsdom in Jurassic, giving you a DOM simulation without a browser, all in C# (though likely very slowly!) It would definitely run just fine in V8. If you get outside the .NET realm, there are other better-supported solutions. This question discusses HtmlUnit. Then there's Selenium for automating actual web browsers.
Also, bear in mind that a lot of the work done around the these tools is for testing. While that doesn't mean you couldn't use them for something else, they may not perform or integrate well for any kind of stable use in inline production code. If you are trying to basically do real-time HTML manipulation, then a solution mixing a lot of technologies not that aren't widely used except for testing might be a poor choice.
If your need is actually HTML manipulation, and it doesn't really need to use Javascript but you are thinking more about the wealth of such tools available in JS, then I would look at C# tools designed for this purpose. For example HTML Agility Pack, or my own project CsQuery, which is a C# jQuery port.
If you are basically trying to take some code that was written for the client, but run it on a server -- e.g. for sophisticated/accelerated web scraping -- I'd search around using those terms. For example this question discusses this, with answers including PhantomJS, a headless webkit browser stack, as well as some of the testing tools I have already mentioned. For web scraping, I would imagine you can live without it all being in .NET, and that may be the only reasonable answer anyway.
Is it possible utilize javascript in the making of windows desktop applications.I use borland delphi and i need to use javascript in my grids.
Worm, I've written a complete solution for you. See the screenshot attached below ...
A basic summary of what I can give is this ... a component that allows you to execute javascript, call delphi from from javascript, and access javascript functions and objects once you connect a script.
Here is a link to an brief article I wrote describing what you can do with javascript. At the end of the article is a zip file containing the source code and a compiled example program you can use to test out whatever javascript you want to write.
AJAX is a technology commonly applied in web applications where javascript is being executed by the client. Such notions are very difficult to apply in desktop applications. You could use background threads to perform expensive tasks to avoid freezing the application and then update the UI with the results of this background tasks.
Thanks a lot sysrpl.
This solution based on ActiveX and Internet Explorer. Required to write too much additional code for each JavaScript function/fearture you going to use.
I strongly suggest take a look on SpiderMonkey (Firefox) javascript wrapper. It's ready for RTTI.
http://code.google.com/p/delphi-javascript/
Required only 1 DLL. Compatible with XE2/XE4/XE5. Ready for x86 and x64 systems.
You can use one of JavaScript interpreters that are available on the market. First of all it's Windows Scripting Engine itself, that offers JScript (delphi wrapper would be needed for comfortable work). Next, it's FastScript by FastReports. There are more available, but I don't remember the names at the moment.
The problem, though, is that the language itself is not enough. What you seem to want is to use JavaScript code which makes use of HTML DOM and various browser classes. Obviously they are not available unless you have a browser engine itself in your program. I.e. if you embed TWebBrowser or link to Mozilla engine, you get the browser and you can run scripts inside of the browser window.
But if you want to automate Delphi GUI with JavaScript, this is probably not the best idea - browser-located JavaScript code will be useless for this.
A lot of questions have been asked and answered about running server-side javascript on Google App Engine, but all of the answers deal with Java instances in order to make use of Java-based JS interpreters like Rhino, Rhino for Webapps, etc.
Is there any way to execute server-side javascript code on a Python GAE instance? I'm thinking something exactly along the lines of pyv8, but with support for App Engine (which I guess would mean a pure python implementation of the interpreter).
The only solution I can come up with at the moment is to use some sort of gross hack to run a Java and Python GAE instance side-by-side (via different versions) so they can both talk to the same datastore, let the Java instance host the JS code, and use an API to talk back'n'forth. Not very appealing.
No need to get into all the "this is unnecessary, you shouldn't be doing this" discussion -- I know this isn't ideal and I'm simply curious if it can be done.
As far as I can find: No
I've done a bit of searching, but it seems that nobody has tried to implement a pure Python Javascript engine, and I can't blame them: it would be a huge amount of work for very few use cases (unfortunately, yours is one of those). A couple of projects—Grailbrowser and Pybrowser—have Python code to render HTML, so might one day aim to run javascript, but it's not even started, and neither of them look in active development.
The most likely way it would ever happen is if Google were to offer the Parrot VM (which can run various dynamic languages) on Appengine. That's a cool idea, but I'm not holding my breath.
What might work is to run Jython (and Rhino) in a Java instance. Of course, then you'd have to get to any App services through the Java API, not the Python one, which would be ugly.
Actually, it can indeed be done, using either AppEngineJs or ESXX:
http://www.appenginejs.org/
http://esxx.blogspot.com/2009/06/esxx-on-google-app-engine.html
I am currently trying to solvevthe same problem with PyJON
http://code.google.com/p/pyjon/
Seems to be a pure Python JavaScrit parser an interpreter.
I have the following situation. A customer uses JavaScript with jQuery to create a complex website. We would like to use JavaScript and jQuery on the server (IIS) for the following reasons:
Skills transfer - we would like to use JavaScript and jQuery on the server and not have to use eg VB Script. / classic asp. .Net framework/Java etc is ruled out because of this.
Improved options for search/accessibility. We would like to be able to use jQuery as a templating system, but this isn't viable for search engines and users with js turned off - unless we can selectively run this code on the server.
There is significant investment in IIS and Windows Server, so changing that is not an option.
I know you can run jScript on IIS using windows Script host, but am unsure of the scalability and the process surrounding this. I am also unsure whether this would have access to the DOM.
Here is a diagram that hopefully explains the situation. I was wondering if anyone has done anything similar?
EDIT: I am not looking for critic on web architecture, I am simply wanting to know if there are any options for manipulating the DOM of a page before it is sent to the client, using javascript. Jaxer is one such product (no IIS) Thanks.
Have a look at bringing the browser to the server, Rhino, and Use Microsoft's IIS as a Java servlet engine.
The first link is from John Resig's (jQuery's creator) blog.
Update August 2 2011
Node.js is coming to Windows.
The idea to reuse client JS on the server may sound tempting, but I am not sure that jQuery itself would be ready to run in server environment.
You will need to define global context for jQuery somehow by initializing window, document, self, location, etc.. I am not sure it is doable.
Besides, as Cheeso has mentioned, Active Server Pages is a very outdated technology, it was replaced with ASP.Net by Microsoft in the beginning of the century. I used to maintain a legacy system using ASP 3.0 for more than a year and that was pain. The most wonderful pastime was debugging: you will hardly find anything for the purpose today and will have to decript beautiful errors like in IIS log:
error '800a9c68'
Application-defined or object-defined error
Nevertheless, I can confirm that I managed to reuse client and server JScript. But this was code written by me who knew that it was going to be used on the server.
P.S. I would not recommend move that way. There are plenty templating frameworks which are familiar to those who write HTML and JavaScript.
JScript runs on IIS via something called ASP.
Active Server Pages.
It was first available in 1996.
Eventually ASP.NET was introduced as a successor. But ASP is still supported.
There is no DOM for the HTML page, though.
You might need to reconsider your architecture a bit.
I think the only viable solutions you're likely to find anywhere near ready to go involve putting IIS in front of Java. There are two browser-like environments I'm aware of coded for Java:
1) Env-js (see http://groups.google.com/group/envjs and http://github.com/thatcher/env-js )
I believe this one has contributions from jQuery's John Resig and was put together with jQuery testing/support in mind.
2) HTMLUnit (see http://htmlunit.sourceforge.net/ ) This one's older, and wasn't originally conceived around jQuery, but there are reports in the wild of using it to run jQuery's test suite successfully (http://daniel.gredler.net/2007/08/08/htmlunit-taming-jquery/ ).
If you want something pure-IIS/MS, I think your observation about windowsScript host and/or something like the semi-abandoned JScript.NET is probably about as close as you're going to come, along with a port (which you'll probably have to start) of something like Env-js or HTMLUnit.
Also, I don't know if you've seen the Wikipedia list of server-side JavaScript solutions:
http://en.wikipedia.org/wiki/Server-side_JavaScript
Finally... you could probably write a serviceable jQuery-like library in any language that already has some kind of DOM library and first-class functions (or, failing that an eval facility). See, for example pQuery for Perl (http://metacpan.org/pod/pQuery ). This would get you the benefits of the jQuery style of manipulating documents. Skill transfer is great and JavaScript has a wonderful confluence of very nice features, but on the other hand, having developers who care enough to learn multiple languages is also great, and js isn't the only nice language out there.
I think it's mainly a browser based script so probably you are better of using technologies based on VB or .NET to perform or generate HTML from templates. I'm sure there are because in the java world there are a few of these around (like velocity). You'd then use jQuery to create or add client side functionality and usability so it makes the website more usable than it would have been.
What exactly do you mean by
"A customer uses JavaScript with
jQuery to create a complex website"
Half the point of jQuery is to make it easy for the developer to manipulate the DOM, and therefore add interactive enhancements to a web site. By running the Javascript on the server and only rendering HTML you will lose the ability to add these enhancements, without doing a round trip to the server (think WebForms postback model...ugh).
Now if what you really mean is the customer uses a site builder based on jQuery, why not have that tool output flat HTML in the first place?
Take a look at this technology. You can invoke scripts to run at server, at client, or both. Plus, this really implements the firefox engine on the server. Take a look at it.
Aptana's Jaxer is the first AJAX web server so far. I have not tryed it yet, but I will. Looks promising and very powerful.
I understand the purpose of GWT, but I'm wondering if I can use it to compile a few functions from Java to JavaScript just to make sure that I don't have to maintain the same code in two different languages.
Or would GWT bring along too much library/support overhead along to make this a reasonable choice?
For future projects, I have the same question about Script# (the C# compiler).
Followup:
Script# seems to produce very readable JavaScript from C# (pages 35-51 have some examples of C# code and the generated JS code).
I found out that there is a -STYLE flag to make the GWT output "pretty" or even "detailed." I still don't know if the emitted JS relies on large libraries or if there are other "gotchas" involved.
Yes, you can do just that. Here's the way to invoke it from Javascript (Source):
How can I call one of my GWT Java methods from my application host page?
In order to accomplish this, you'll
first need to create a JSNI method
that creates a JavaScript method that
in turn makes the call to your Java
method. In your GWT application's
onModuleLoad(), you would call that
JSNI method so that the JavaScript
method is defined. From your
application host page you would then
call the created JavaScript method.
Confused yet? It's actually quite
simple.
The code snippet below shows an
example of this (courtesy of Robert
Hanson):
private native void initPlaylistJS (PlaylistTable pl) /*-{
$wnd.addClipToPlaylist = function (clipId, clipTitle) {
pl.#com.foo.bar.client.PlaylistTable::addClip(Ljava/lang/String;Ljava/lang/String;)(clipId, clipTitle);
};
}-*/;
In this example, you would need to
make a call to initPlaylistJS(pl) in
your GWT module's onModuleLoad(). Once
your GWT application loads, the
JavaScript method is defined and is
callable from outside of the GWT
application.
As for the 'baggage', GWT compiles a single monolithic file, so you don't need to include anything else.
One extra thing to note is that in my experience GWT is not perfectly suited for sharing code between the server and the client, since the server part needs to become GWT-compilable, that is only include classes which are part of the emulated JRE or for which you have the source available for compilation.
GWT is not a general-purpose Java-to-JavaScript converter, though it converts a useful part of the JRE for web applications (and of course the GWT widgets). It's not really worth using for a "few" functions just to avoid coding in JavaScript. Of course if you are building a complex UI which consequently involves complex JavaScript coding, then GWT really shines. If you write Java methods to help implement the logic of your GWT event handling, then these will get converted to JavaScript functions along with everything else. However the main benefit of GWT is how easy and natural it is to debug your UI in hosted mode - that's the main productivity gain (as well as the familiarity of the widget API for desktop application developers).
If you've already got the functions implemented in javascript, would something like Rhino make sense to execute the Javascript code inside the JVM on the server-side?