I just realized a JSF (web JavaScript application) that connect to a MongoDB database and generate a report (PDF) thanks to JasperReports Library (so with a .java file).
Is it possible to do the same thing with a web application in CoffeeScript and Node.js? I am really new to this, so I don't know where to start.
For example: Is it possible to run a .java thanks to Node.js or CoffeeScript?
JSF is actually a JavaServer Faces application, not a JavaScript application. JavaScript (which Node.js, CoffeeScript are based on) is not equivalent to Java despite the similarity in names.
If you already have a JSF-based application then you already should have everything you need to create a web-based application. There is no need for Node.js, CoffeeScript, etc.
Go take a look at JSP, Tomcat, etc. to figure out how to render web pages rather than output to PDF and you should be set.
If you want to rewrite your application in javascript and run it on node.js, you should be able to use PDFKit to build the PDFs.
If you only wish to use your existing application and integrate it with a node.js server, I think you would be wise to run them in parallel (or proxy requests to your JSF application through node, in case that makes sense). It's hard to give a better answer unless you can state more clearly what it is you want to accomplish.
Yes, it's possible. You can start / stop / control another process with Node.js - so You can start .java in another process and use it to generate PDF. But ... it may be not very efficient in terms of resource usage, so it's an open question.
Or, you can write a simple worker that will generate PDF from JSON data and use 0MQ or other inter-process communications between Node.js and this Java worker.
He-he, JSF was one of the worst technologies I ever saw (I believe it's still in the same state now as it was in 2007 when I left Java), even dumb JSP and servlets was better...
Related
Hope I'm not being to general but: I have been tasked with the job of "rejuvenating/modernizing" a monolithic Java EE (JSF/CDI/EJB/JPA) app. Since the requirements state that it should support multiple clients, I have split up the code in a server (JAX-RS interfaces) and a client part (not yet done)
The server is pretty straightforward but I'm wondering about the UI part. Nowadays (hope I don't sound too oldskool) various Node JS spin-offs seem to be popular but I'm under the impression that they have the most value to offer in the "scalable server" section. Does the various Angular/React/Node framework have anything to offer for the client if you have something more complex than a single page app?
It appears to be a really hard time to pick a UI technology nowadays. Sure, the server/DB part which contains most of the business logic are pretty future-proof but still, one would like to focus on one UI technology. There are various jQuery-based frameworks like Kendo, Vaadin & co etc. One option would be to stick with JSF + ICEfaces/PrimeFaces and just work with the REST interface. And then there is JavaFX which looks nice but the future looks a bit uncertain.
So. If the backend is not going to be Node JS, does Node JS have anything to offer for the UI part that can't be done more easily with other frameworks and does anyone have other insights on the UI layer in general. Predicting is hard, especially the future ;-)
Node.js is a way to run javascript on the server side, not client side. That said, npm (nodes package manager) or its wrappers (like bower) are quite often used to manage the client side dependencies - which is very useful to have.
Angular and react (among others) are client side javascript ui frameworks to help make writing ui much nicer. Neither depend on the backend being written in node.js and can work with any rest api (or other server side apis) - or no api at all if that backend injects all the data the page needs into the page itself.
Electron, which combines NodeJS and Chromium (render Process).
https://electronjs.org/
Formerly known as atom shell it was created by Github, it is the core of the Atom Editor, VS Code, Slack app, and a ton of “thick client” applications. https://en.m.wikipedia.org/wiki/Fat_client
There are several implementations which allow you to use Node.JS modules on a client-side (ie. web browser). You can then use html/css and call Node.JS modules directly from your DOM which is used to implement UI.
I'm most familiar with NW.js which I've used couple of times. Others would be for example Electron or AppJS
Express JS uses templates for generating HTML and then server sends them to client in response. There may be several other templates from which HTML can be generated. The ones I was able to discover are:
Jade (http://jade-lang.com/)
EJS (http://embeddedjs.com/)
In my app, I need to use both ExpressJS and AngularJs. I am new to both technologies. While learning angular, I had to use it in pure HTML. After learning ExpressJs, I realized, in order to use angularjs, I need to use them in any of the above templates which will be converted to HTML while sending to client.
Now, I want to use expressjs as my server and angularjs as my client side app. For this, I think I have two options.
Option 1
I can stop using templates altogether and use our NodeJS server to respond by sending simple HTML files. These HTML files will then contain AngularJS coding within them. AngularJS then, on client side, will act as our application. It will demand other HTML documents from the server. Or it can also be used like AJAX, where we can only request the piece of information to update just part of the page rather refreshing the whole page for a minor change.
Option 2
I can use angularjs inside expressjs templates (jade or ejs).
Kindly, help me in understanding the pros and cons of both options. Which one will be your choice in such case.
This is very much an opinion question and Stack Overflow admins hate anything that smacks of opinion, but here's my experience and opinion nevertheless.
I've done a couple of apps now using purely static files (HTML, CSS, and JavaScript) with those calling a service on the back-end to deliver the data. It reduces the back-end, whatever it is (I've used both Java and Node.js), to just being a set of service URLs but it works very very well.
You've got a fantastic hard line between the responsibilities of the
two systems
It's very easy to work on and test each one independently
Bugs are usually very clearly in the front-end or the back-end (all
you have to do is look at the data transferred to know)
The back-end services are ready to be reused to support alternative UIs from the
command line or something mobile specific if you want
You can use one technology for the back-end to start with (say Node.js or Ruby on Rails) and then switch to something else later if you need to. As long as the API stays the same the front-end never knows.
I personally use AngularJS with Express/Jade. The setup is actually pretty simple and I find writing Jade much more enjoyable than writing HTML. I've also adopted writing my Angular code in CoffeeScript as, again, it makes for quicker development. If you are looking to save keystrokes then Jade is a great solution and its integration with Express makes it a no brainer. If you aren't worried about producing code more quickly then there is absolutely no problem with using HTML.
I will point out that one of the greatest benefits I have found to using Jade over HTML is the ability to develop a single page in multiple files, then use include to have them concated before compiling into HTML. This allows you to take larger pages and break them into more manageable chunks. Together with Angular's templating, this can relieve much frustration.
Really it is all a matter of opinion, but since I decided to give Jade a shot, I have not regretted it and I have never ran into a situation where my HTML was rendered incorrectly when using Angular.
I went with option 1 because I didn't want to deal with any potential issues with jade or ejs converting the template incorrectly and interfering with Angular. My app essentially has the index page (which is really just the basic page template with my css and js includes) come out of Express as jade and then angular takes it come there and all my angular templates are in a separate location than my jade template.
Recently I started playing with node.js.
Since I'm developing a web app, I was interested in the benefits of google's javascript V8 engine, i started reading stuff about all this - and node.js.
An example of a webapp which uses node.js: http://bodesigns.com/simple-web-app-using-node-js/
As you can see, it uses node.js to connect to a mysql database. Some questions about this:
- First of all, is this safe? I mean: the username and password are stored in the file. I know, in PHP it is to, but a PHP-file is server-side. Node.js is server-side?
Second, with this (i'm also building a part of the web app with google maps stuff), i could replace the PHP-code I have now to collect some data from a mysql database? What are the (dis)advantages of replacing the PHP-code with node.js code?
Last: can I run a node.js server asynchronously? I mean: i have a HTML-page with a link (). When i click it, it must "run" the node.js-script, which collects data form the mysql-database. Like in the example. So when the page loads, only an empty map has to be visible. If you click something, markers have to show or hide. Is this possible?
My apologies for my bad English.
First of all, is this save?
node.js runs on the server, the code doesn't need to go to the client so it's safe.
What are the (dis)advantages of replacing the PHP-code with node.js code?
Do you need to rewrite code that already works? If your writing new code then PHP vs node.js is a completely different and application specific discussion. For generic applications they are both suitable
Is this possible?
Yes, however it's also possible with PHP.
I am developing a Java EE based web application. We have a very limited time to come up with a alpha version and trying to decide on a web framework to use. It has to be something easy to learn but powerful. Standard JSP/Servlet is not an option here due to the time it takes for the development. Appreciate if anyone could advice. Current options are Wicket and GWT. (JSF is also an option)
Wicket is component-based and comes with a bunch of standard components (like pagination, auto-complete, data grids, form handling etc.). If you want to create a standard panel (with the possibility for easy re-use) just create your HTML fragment to use a template (with wicket:id attributes wherever you want to bind dynamic content or sub-components) and a corresponding Java file. Furthermore, you can attach specific CSS and JS files.
In my opinion, Wicket development is good value (functionality) for money. And you get a lot of built-in AJAX functionality without even writing (not reading) any JS. E.g., change the model for a component, attach the component to an AjaxRequestTarget and the panel is automagically repainted via DOM manipulation.
For a quick overview and intro I recommend Wicket in Action by Dashorst & Hillenius. (And don't miss out on other great resources.)
Everything depends on your application. I don't have experience with Wicket, not much with JSF. I have big experience with GWT.
GWT is good if your application has to be mostly dynamic. In GWT you can change everything on the page not even calling the server. GWT is compiled to Javascript. On the other hand, if you have big project, it is quite frustrating if your application in development starts few minutes, because it has a lot of code to compile to Javascript. My opinion: it is not good for big projects.
If you don't need to change your pages so much client-side, I would use JSF2 (or Wicket, if I knew it).
Have a look at this comparison of Wicket and GWT, this may help you decide for yourself:
Wicket and GWT compared with code
I'm starting work on a new website (sort of an e-commerce product comparison thing) and I'm trying to choose what technologies to build it on. I've ruled out PHP and I don't think I want to use Python or Ruby. I really like Java and Hibernate so I started looking into Java-based web technologies.
My problem is that all of the documentation and examples I've read can't seem to stop repeating the words "enterprise" and "web applications." I'm afraid of ending up with giant XML configuration files and business-oriented components while losing the ability to actually design the website. From what I've read of JSF, I like the idea of reusable components, but I still want the ability to customize individual pages. So my question is, are JSF/Seam/Spring well-suited for non-enterprise development? If not, what Java technologies are?
I have just started looking into JSF/Seam so please forgive me if this is an uninformed quesiton. Thanks in advance. :)
No problem. The JSF/Seam stack gives you all the customization you want, and it has very few XML files. In fact, it uses a lot of annotations to define entities and components, so you don't have to worry about writing tou much XML (it is one of the reason why Seam was invented).
JSF's standard components are rendered as simple HTML tags, while if you want to go AJAX and use Richfaces it will be a little harder to customize it, but nothing dramatic. I can assure you that for the view part, you can write whatever you want in your webpages.
Here's a nice reference of how the JSF tags are rendered.
For the model and DB part, the JPA framework gives you the ability to work with simple Java Objects, and sometimes using it in an "enterprise" context with legacy schema is even more difficult, so don't worry.
For a simple website you may safely skip the EJB part, this will help you writing a more cleaner project structure. You can package all your website in a simple .WAR file.
As for the "enterprise" word, I think it is more related to the fact that the Java EE framework gives you the feature you may need in an enterprise context, (i.e. EJBs), but you can avoid them.
They don't bite.