I need to make a web page where the input and the output is displayed, but the code where I "do stuff" must be in writing in Julia, how can I do this?.
to be clear, I want something like this:
Web ----> Julia ----> Web
|input | do stuff | output
I don't know what I need to make this possible, I need any kind of Server-side?
I'm a very novice in programming, so I don't know how to search this on internet, I will be thankful with any help.
In addition to the Julia webstack, you might want to look into Genie.jl. It's looking like a nice framework and was used to build this website.
If you need to accept input from the web and then output corresponding data after processing it with Julia, then definitely you need to use some form of server side Julia, since Julia does not run in the browser.
In terms of workflow, what you need is very simple:
1/ first, you need to display a form, to accept user input;
2/ second, the form needs to be POST-ed back to the server - where the data in the payload is processed;
3/ finally, you need to send back a response.
You can use a Julia framework like Genie (author of Genie writing this, btw) to have everything Julia in your stack - or you can use some other web stack (PHP, ruby, python, etc) for 1/ and 3/ and have a local Julia script process the data, invoked by the web scripts.
If you don't have experience developing web apps but have/need Julia skills, you're probably better off using Genie. It knows how to render HTML, it provides a nice MVC workflow, has a clear file structure and comes with some generators, does input sanitization in the persistence layer, etc. And it's very easy to accept input, add your data processing logic, and output your response.
But I must warn you that it's still very much work in progress - and this is visible in the state of the documentation (working on it, but boy this is time consuming). You can give it a try and open up issues in GitHub if you get stuck. Also, I would not recommend it for any mission critical apps yet - it needs more testing.
I will copy part of the answer from: How to make a GUI in Julia?, and add a few more.
If you are developing you code within an [Jupyter/IJulia] notebook,
and need very simple interaction, such as slider to change some input
values, the Interact package is the easiest thing to get started
with.
To develop full fledged web UIs, take a look at Escher.
Inspired by the Elm, it provides a functional library of UI
components. Interactive web UIs are created in 100% Julia. There is
no differentiation in code between the client and server sides. The
framework handles all of that.
Another web framework worth looking at
is Genie, which based on the traditional MVC design pattern. It also
includes an ORM. An example of an application written in Genie is
this listing of Julia packages: http://genieframework.com/packages
If you application is relatively simple, and you are happy working with a slightly lower level API, the Mux.jl middleware framework (which Escher uses) allow you to write simple handlers to http requests.
If you want to create cross platform desktop apps, but want to work with
web technologies (i.e. HTML/CSS/Javascript), use Blink. This is a
Julia wrapper around the Electron. You could potentially write an
Escher or Genie application, and wrap in in Blink.jl to create a desktop app.
All of these packages are currently useful and well maintained. Unfortunately, some of the higher level frameworks in juliawebstack are no longer maintained.
Related
Currently, we have a number of GUIs that have been developed using PyQt4 and PyQtGraph.
We need to make these interfaces accessible to a number of remote users and are hoping to do so by serving the GUIs through an HTML/CSS/JavaScript Web-Application.
The link below provides a few suggestions for this task, but these seem to apply to a project that is in its initial stages of creation. I'm familiar with the development of Python-JavaScript Web-Applications using the Pyramid Server and would like to use this same method for providing users access to PyQt4 GUIs that have already been developed.
https://softwareengineering.stackexchange.com/questions/109572/can-i-create-a-desktop-python-gui-application-and-run-it-as-a-web-app
So my question is, can I serve a functional PyQt4 GUI as a widget using HTML/CSS/JavaScript?
This is hard. In theory you could use a VNC-like approach that sends an image of the window to the client browser and sends user events back to the server. This will probably have poor interactivity depending on the networking and would require a lot of server power, depending on the number of users. (For an example of this, see: https://github.com/campagnola/webqt)
You're probably better off distributing the application with something like py2exe, py2app, cx_freeze, etc.
I personally haven't tried it but you could look into Wt: http://www.webtoolkit.eu/wt/
It is a C++ framework that has a Qt flavour. It has a Java version called JWt. Hence, a Jython binding exists for us Python programmers: http://www.webtoolkit.eu/wt/other_language
It is not a direct replacement of Qt, and might need modification to your Qt code to work as a Wt web app, but it certainly seems worth it to look into.
This is a question about the best way to structure an app that has both server-side and client-side needs. Forgive the length -- I am trying to be as clear as possible with my vague question.
For a standalone non-web-connected art project, I'm creating a simple browser-based app. It could best be compared to a showy semi-complicated calculator.
I want the app to take advantage of the browser presentation abilities and run in a single non-reloading page. While I have lots of experience writing server-side apps in perl, PHP, and Python, I am newer to client-side programming, and neophyte at JavaScript.
The app will be doing a fair bit of math, a fair bit of I/O control on the Raspberry Pi, and lots of display control.
My original thought (and comfort zone) was to write it in Python with some JS hooks, but I might need to rethink that. I'd prefer to separate the logic layer from the presentation layer, but given the whole thing happens on a single non reloading html page, it seems like JavaScript is my most reasonable choice.
I'll be running this on a Raspberry Pi and I need to access the GPIO ports for both input and output. I understand that JavaScript will not be able to do I/O directly, and so I need to turn to something that will be doing AJAX-ish type calls to receive and sent IO, something like nodejs or socket.io.
My principle question is this -- Is there a clear best practice in choosing between these two approaches:
Writing the main logic of the app in client-side JavaScript and using server-side scripting to do I/O, or
Writing the logic of the app in a server-side language such as Python with calls to client-side Javascript to manage the presentation layer?
Both approaches require an intermediary between the client-side and server-side scripting. What would be the simplest platform or library to do this that will serve without being either total overkill or totally overwhelming for a learner?
I have never developed for the Raspberry Pi or had to access GPIO ports. But I have developed stand-alone web apps that acted like showy semi-complicated calculators.
One rather direct approach for your consideration:
Create the app as a single page HTML5 stand-alone web app that uses AJAX to access the GPIO ports via Node.JS or Python. Some thoughts on this approach based on my experience:
jQuery is a wonderful tool for keeping DOM access and manipulation readable and manageable. It streamlines JavaScript for working with the HTML page elements.
Keep your state in the browser local storage - using JavaScript objects and JSON makes this process amazingly simple and powerful. (One line of code can write your whole global state object to the local storage as a JSON string.) Always transfer any persistent application state changes from local variables to local storage - and have a page init routine that pulls the local storage into local variables upon any browser refresh or system reboot. Test by constantly refreshing your app as part of your testing as you develop to make sure state is managed the way you desire. This trick will keep things stable as you progress.
Using AJAX via jQuery for any I/O is very readable and reliable. It's asynchronous approach also keeps the app responsive as you perform any I/O. Error trapping and time-out handling is also easily accomplished.
For a back end, if the platform supports it, do consider Node.JS. It looks like there is at least one module for your specific I/O needs: https://github.com/EnotionZ/GpiO
I have found node to be very well supported and very easy to get started with. Also, it will keep you using JavaScript on both the front and back ends. Where this becomes most powerful is when you rely on JavaScript object literals and JSON - the two become almost interchangeable and allow you to pass complicated data structures to/from the back end via a few (or even one!) single object variable.
You can also keep your options open now on where you want to execute your math functions - since you can execute the exact same JavaScript functions in the browser or in the node back end.
If you do go the route of JavaScript and an HTML5 approach - do invest time in using the browser "developer tools" that offer very powerful debugging tools and dashboards to see exactly what is going on. You can even browse all the local storage key/value pairs with ease. It's quite a nice development platform.
After some consideration, I see the following options for your situation:
Disable browser security and directly communicate with GPIO. No standard libaries?
Use a JavaScript server environment with GPIO access and AJAX. Complexity introduced by AJAX
Use the familiar Python and use an embedded web browser If libraries are around, easy
Don't add too much complexity if you're not familiar with the tooling and language
Oh what a nice question! I'm thinking of it right now. My approach is a little difference:
With old MVC fashion, you consider the V(iew) layer is the rendered HTML page with Javascript CSS and many other things, and M and C will run on the server. And one day, I met Mr.AngularJS, I realized: Wow, some basic things may change:
AngularJS considers the View ( or the thing I believed is view ) is not actually view. AngularJS gave me Controllers, Data resources and even View templates in that "View", in another word: Client side itself can be a real Application. So now my approach is:
Server do the "server job" like: read and write data , sends data to the client, receive data from client ect....
And client do the "client job": interact with user, do the logic processes of data BEFORE IT WAS SENT such as validation, or format the information collected from user ect...
Maybe you can re-think of your approach: Ask your self what logic should run at client, what should at server. Client with javascript do its I/O, Server with server-side script do its I/O. The server will provide the needed resource for client and javascript use that resources as M(odel) of it's MVC. Hope you understand, my bad English :D
Well... it sounds like you've mostly settled on:
Python Server. (Python must manage the GPIO.)
HTML/JavaScript client, to create a beautiful UI. (HTML must present the UI.)
That seems great!
You're just wondering how much work to do on each side of the client/server divide... should be functionally equivalent.
In short: Do most of the work in whichever language you are more productive in.
Other notes come to mind:
Writing the entire server as standalone python is pretty
straightforwad.
You don't have to , but it's nice and
self-contained if you serve the page content itself from it.
If you
keep most of the state on the server/python side, you can make the
whole app a little more robust against page reloads (even though I
know you mentioned, that should never happen).
I find myself in a bit of a conundrum. I'm building a new, modern, web-based application and not only do I have to pick a technology, I have to pick an architecture. I think it is fair to say that these days its a tough choice because we have more options than we did even 5 years ago.
First things first, I've made the decision that Scala will be the server-side language. I have my reasons, and this is not a Scala versus XYZ post - that choice has been made. I've also sucummed to the fact that we're on the web, in the cloud, so I'm not even going to try and get away from Javascript. Maybe I will with CoffeeScript, but I will be writing Browser-hosted code.
Now, assuming Scala, most people would probably jump to either Play! or Lift. Probably Play! given it's endorsement from Typesafe, but I think I have another more important question that needs answering first. What's the architecture? If I want a very rich client, do I really need more than a simple stateless service layer based on the fact that we'll have a tonne of Javascript anyway? I'm not sure it'll be a single-page webapp, but is something like BlueEyes potentially the right choice? Lift and Play! are much more heavyweight in that they take on much more responsibility. They generate the HTML and for these frameworks, the browser is pretty dumb. Things like routing, validation, Ajax and Comet support are all server-side concerns. Because the browser is more capable today, rich, interactive features are normally implemented by generating and injecting Javascript from the server.
My question boils down to this. Do I go with a traditional Lift/Play! framework where the server takes on both the client and server responsibility or do I go with a rich client + REST-style service layer where the client takes a more prominent role in the application? An architecture where the client deals with routing, validation, binding, etc. I'm seeing frameworks like KnockOut.js, Sammy.js, Sproutcore, Backbone.js,... I'm not going to list them all but suffice to say that they all take on some of these framework features from a client-side perspective.
If I choose Play!, am I giving up some of that rich UI? What about situations where I want to provide service API's for integration/mashup/mobile purposes? How would Play! help me here? Clearly BlueEyes plays well here. I think I need a service layer regardless.
If I choose BlueEyes, what does my client code look like? How many of these Javascript-based frameworks do I need to give me what I need? I still want most of my business-logic in my service layer, but routing, binding.. all that UI stuff would be a concern of the client.
I'm not sure there is a right or wrong answer, but I think this community can probably point me in the right direction.
I also posted this to my blog at http://www.andyczerwonka.com/picking-a-web-technology-isnt-as-easy-as-it-u-45228
If all you want is a REST API on the backend, then Lift, Play! or Blueye will work just fine. But I'll just point the advantages of using Lift.
It is not true that Lift tries to impose doing both, the front and back end. We support REST-only use of Lift and it is encourage for the right project.
While Lift comes with jQuery and blueprint, you can use any javascript library and css framework, there is currently a lot of people on the mailing list showing how they use twitter boostrap with Lift. See this Lift module that helps integrating Bootstrap.
With Lift, you can start stateless, and if along the way you find that your needs change, you can go statefull. You can even mix and match them on the same application.
Want some modern looking UI? Lift's comet support is one, if not the best one, out there. Very simple to use, proven and tested on many browsers/workloads. I have written several posts showcasing Lift's comet support.
If you decide to use Lift for both, front and back end, you get for free an application that is secured by default, no need to worry about xss, xsrf, or many of the top 10 OWASP security vulnerabilities.
Need commercial support, there is a growing list here
Need training? There is a Basic training coming up in London and the founder of Lift also provides other training sessions.
There are several books about Lift available. Lift in Action , Simply Lift and Exploring Lift
There is a very active community ready to help.
Who uses Lift? Just to name a few: Foursquare , OpenStudy , The Guardian UK, StackMob and many more.
Well, I should stop here, but in short, Lift is an awesome framework that has a lot to offer, you take as much or as little as you need.
The Play 2.0 Beta contains a sample application that is exactly what you are looking for (ZenContacts).
Its server side is just a bunch of restful interfaces while its client side leverages coffeescript etc. to build a rich user interface.
As far as I know, both Play! and Lift can be used as basically a "back end", and you can use HTML5+CSS+JS as your "front end"; they do not necessarily restrict your ability to create the front end you desire, so rejecting them for that reason would be silly. Notice things like knockout.js advertise that they "work with any web framework". However, it might be true that they are more "heavyweight" than what you need.
I have never heard of BlueEyes before, but it appears to be aimed at a particular kind of use case. If that fits your bill, then it will probably be the most streamlined solution to your problem.
But if this is something you plan to actually put on the web, "routing, validation, binding, etc" practically need to be handled by the back end; I simply cannot imagine any of these things (securely) being handled by code that runs in the client's browser. Also, if your users choose to disable JavaScript, your website would be completely unusable.
If I choose Play!, am I giving up some of that rich UI?
What exactly you mean by rich UI? more javascript on the frontend?
If you consider - HTML5+CSS3+jQuery as a rich UI - then these work very well with any "backend" (Lift/Play).
The other thing which you might want to consider is the maturity of the framework.
Like you mentioned Play 2.0 supports Scala natively, has endorsement of Typesafe and is rapidly being adopted.
Plus you can expose RESTful services easily and consume then in the frontend (one of your requirement).
Leaning towards HTML5+CSS3+jQuery + Play 2.0 :)
just my thoughts..
What's the architecture?
Play! strongly encourages your server to use an MVC architecture, creating packages in a standard pattern:
app/
controllers/
Application.scala
views/
Application/
index.scala.html
models/
public/
images/
stylesheets/
javascripts/
This makes it easier to follow the architecture than to break it.
I can't speak for either Lift or BlueEyes, but afaik neither of them encourage an architecture as strongly.
Definately have a look at http://twitter.github.com/finagle before making up yiir mind. Finagle can take care of most of your backend stuff. It's desinged around a very flexible architecture that separates concerns cleverly using filters.
I have looked at apache click, wicket, a little bit Lift (feel a bit like wicket), and then play 1.2.4. So far so good with Play. Really beautiful approach to the web development. Keep up the nice work, play! team.
I am facing a decision about the web application architecture I am going to work on.
We are a small team and actually I will work on it alone (everybody work on something else).
This application will consist of front-end build on the ExtJS library
and it will use the model "load page, build GUI and never refresh".
On the web "desktop" there will be a lot of data windows, map views (using openlayers + GeoExt) and other stuff.
GUI should be flexible and allow every user to modify (and persist) the layout to fit his/her needs.
It should be possible to divide the application into modules / parts / ... and then let users in specific groups use only the specific modules. In other words, each group of users
can have different GUI available on the web "desktop".
Questions are:
First of all, is this approach good?
There will be a lot of AJAX calls from clients,
may be this could be a problem.
How to handle code complexity on client side?
So far I have decided to use dojo.require / dojo.provide feature and divide the client side code into modules
(for production they will be put together using dojo build system)
I am thinking about to use kind of IoC container on client side, but not sure which one yet.
It is very likely that I will write one for myself, it should not be difficult in dynamic language like JavaScript.
How to handle AJAX calls on server ?
Should I use WCF on server side ? Or just ordinary ashx handler ?
How to handle code complexity on server side ?
I want to use Spring.NET. May be this approach could help with modularity problem.
Data access - here I am pretty sure what to use:
For DAL classes I will use nHibernate. Then I compose them with business classes using Spring.NET.
I would really appreciate some advice about which way to go.
I know about a lot of technologies, but I have used only little part of it.
I don't have time to explore all of them and be fine with the decision.
We do this type of single page interface where I work on a pretty large scale for our clients. (Our site is not an internet site)
This seems to work pretty well for us. The more js you have the more difficult it gets to maintain, so have as many automated js tests as you can and try to break up your js logic in an mvc fashion. 4.0 is supposed to make this much easier.
Ext 4.0 has this built in if you are trying to limit the code you bring down. If you have the same users day after day, then I think it would be best to just bring all the source down (compressed and minified) and cache it.
We've found asmx to work really well. I have nothing against wcf, but last I looked it seemed like more trouble than it was worth. I know they have made many improvements recently. asmx just works though (with a few request header changes and managing the "d." on the client side).
Our Server side data access layer is pretty complex, but the interface for the ajax calls is pretty simple. You have not really given enough info to answer this part. I would start as simple as possible and refactor often.
We are also using nHibernate. Works fine for us. We have built a DDD model around it. It can take a lot of work to get that right though (not sure if we have it right after months of working at it).
If I were you I'd start with just extjs, your web service technology, and nHibernte.
I would recommend ASP.NET MVC 3 with Razor instead of a lot Javascript and calls to Service you can just do ajax calls to an Action in a Controller and that will let you have more maintainable code and use a IoC like Ninject. EF instead of NHibernate.
But it's your decision.
I would look into using a tool like Google Closure Compiler, especially if you're dealing with a very large project. I don't have too much experience with ExtJS, but large projects in JavaScript are hard and something like Closure Compiler tends to make it easier.
I would like to know, how powerful/viable are JavaScript only clients based on say, GWT/gxt/vaadin, when compared to DHTML clients such as those made with wicket, tapestry, click etc?
My boss has insisted on using GXT (due to its nice colors and theme) on a project that will most likely become very big with lots of screens. I am against the idea of a javascript only client, especially when the javascript is generated from Java code. I have tried to advice him that we use something like wicket whereby we construct the screens with html but put in ajax where and when neccessary.
How viable is such a JavaScript client? I understand that JavaScript was intended for minor web page enhancements, and not all browsers, especially mobile devices have complete support for JavaScript.
Yes, it is viable for certain applications. Consider Gmail, Google Docs and Google Maps as typical applications where this works, and is probably the most feasible approach.
Some rich UI JavaScript frameworks, such as Ext JS also rely on this technique.
I've built javascript only web apps for ages.
First in SAP projects for big multinationals. And now on a new project:https://beebole-apps.com?demo
So yes it is powerful and viable.
Javascript-only webapp can be extremely powerful, and it's viable for certain applications, say, an Instant-Messenger webapp?
You mentioned that there are lots of screens in your web-app. One of the advantages from GWT/GXT is the fact that you can unit test your UI-layer with JUnit. This is an extra testing you can do on top of, say, Selenium. This is essential if you'd like to make UI testing a part of the continuous integration process, and, as the team grows, you'll definitely want to have tests around to make sure everything works (At least in theory.)
However, if what your boss meant to do is to build an in-house, custom Javascript engine using GWT's JavaScript Native Interface (Link), then I'm not sure...
Another advantage with GWT-like-engine over Wicket is that you can rely on HTML-code-gen to generate standard-compliant (In theory) HTML code. With framework like Wicket, it is hard to ensure every single developer on the team to author good HTML code - Especially when the team gets bigger.
Disclaimer: I'm a member of the Vaadin team.
Our Timeline demo is a good example of what can be achieved with Vaadin and GWT in client side, but I think all of the options presented in this discussions are viable given enough time.
Since you are going to start a big project you should build a simple proof-of-concept app with each of the relevant frameworks. If your PoC includes at least some of the more complex use cases you'll probably can make a pretty informed choice based on the experiences you get while building them.
I urge you to at least evaluate Vaadin. With it you write only server-side Java code and Vaadin will create a slick and professional browser UI for you. Client side can be easily extended using standard GWT (also pure Java), and there are no HTML templates, tag libraries or XML configuration involved at all. A Vaadin UI is fully Ajax'ed and lazy loading out of the box, and it easily integrates with any server side technologies, eg. Spring.
In addition to the development model advantages you get top-notch documentation, a bi-weekly update schedule, a very lively community filled with helpful experts, 100+ useful open source add-ons, and a 10 year old backing company with help on hand should you need it.