I'm interested how I can migrate JSF application to JavaFX 2.0 Application? I want to preserve the managed beans where I have integrated the business logic. Can I somehow use the managed beans as backed and use JavaFX for presentation layer?
What are the options?
Options:
Use CaptainCasa, which is a framework for taking JSF pages and rendering them in a JavaFX client.
Do as Alexander recommends and rewrite a lot of your app to switch the view, control and navigation management to JavaFX.
Host the existing JSF application in a WebView, incrementally enhancing and migrating parts of it to pure JavaFX on an as required/time permits basis.
I'm not a JSF expert, nor do I know your application, so I can't really recommend what might be the best approach for you. Definitely option 3 is the easiest.
Read JavaFX in Front of JavaServer Faces: CaptainCasa for more information on CaptainCasa.
WebView is not a full browser engine only an HTML viewer, so if you need a bit more functionality, you could adapt something like Willow or WebFX to handle some of the page navigation aspects that a browser normally would do.
I assume you want to keep the managed beans running on a server rather than integrate them into your client, in which case you are going to need to develop a communication layer to communicate between the clients and the server. You could use REST for this as demonstrated in the Henley data sales sample app, though it may be easier to use something like the Hessian system outlined in this blog.
I've found another option to evaluate the trouble - try to lookup in google the next request:
"JSF site:fxexperience.com"
fxexperience.com - site-blog, which supported by JavaFX developers, and except other posts, they weekly provide link batches on different interesting resources.
For instance, I've found such link : http://www.jsfcentral.com/articles/jsf_and_javafx.html
I expect, if decision exists, it could be found there.
Related
I am planning to make an application that has views with complex forms and logical validation on the client side. I plan to use AJAX for submits and have some visual appeal.
I want a recommendation from those who have experience developing with Bootstrap and/or CoffeeScript and Vaadin. I have two options:
Using Bootstrap / CoffeeScript and some framework for the server site, such as Play Framework, Rails or Django
Vaadin
The criterion that concerns me is related to the complications that may arise in the client side JavaScript and/or HTML5 validation as well as in CSS and HTML code to be written using Bootstrap. Is it worth using CoffeeScript over Vaadin in a practically ria app? I see that there are many who have chosen Bootstrap and I'm sure they have their reasons.
Help me with the decision. Some relevant documentation could be helpful, too.
Vaadin
Vaadin in an amazingly good tool for building interactive desktop-style web apps developed in pure Java and delivered via regular web browsers.
Benefits
Vaadin 6, 7, and 8 apps run entirely on the server-side. The JavaScript library automatically installed by Vaadin into the user’s browser window simply:
Draws on-screen whatever the server-side app tells it to.
Feeds user actions (clicking, typing, and so on) back to the server for the app to consider and respond.
So there is no "logical validation on the client side" or "html5 validation", at least not from the Vaadin app developer’s point of view. The Vaadin framework may do so under-the-covers in its internal implementation, but that is none of my concern as a Vaadin app developer. That’s the core benefit of Vaadin: I don't care how Vaadin gets my forms onto the user’s screen. As a Vaadin app developer, I am not writing any JavaScript, HTML, DOM, CSS, or AJAX. Just pure Java.
The style is similar to Swing: Instantiate a layout (a form), add labels, add buttons, add fields, add other widgets. Attach validators as needed. Nest additional layouts, for complicated forms. All of that executes in memory on the server-side, all in pure Java. Finally tell the layout to show itself. Poof, like magic, Vaadin tells the browser to display a likeness of that form.
If you want to develop desktop-style business-style apps that happen to be deployed through a web browser, Vaadin is a wonderful tool.
Trade-Offs
Trade-offs include:
Lots of memory and CPU usage on the server-side.
Giving up control over the HTML/CSS/JavaScript.
Scaling
Your web app lives on the server, not the client. All your business logic, the users’ entered data, the internal representation of all the users’s forms such as row items in a table, all this lives on the server. Multiply that by number of users. This means a Vaadin app can demand much memory and CPU usage.
That may limit scaling up. But given 64-bit Java, multiple gigs of memory, and multiple cores on even the lowliest of machines such as a Mac mini, scaling-up is likely an issue only for the largest/busiest of apps.
And even in those rarer of large/busy app there may be ways to handle scaling in Vaadin. All of the app lives in a Servlet Session. Some web infrastructure allows such session state to be moved between servers or even persisted out to storage to be picked up by other servers.
Or your app may scale well. Simulations with 11,000 simultaneous clients have been done. See:
Vaadin Scalability Study - QuickTickets (company blog post)
Scaling with Vaadin and WildFly Webinar with Arun Gupta (video presentation, YouTube)
Control Over HTML, CSS, JavaScript
If your team is more comfortable or experienced with conventional web app architectures, then Vaadin may not be for you. In Vaadin you write your app entirely in pure Java, and Vaadin translates that to HTML, CSS, and JavaScript automagically.
You can tweak the CSS a bit. And even without touching CSS, Vaadin’s "themes" (Valo, Reindeer) give you much control over colors, sizes, and fonts if you wish to override the defaults. But know that Vaadin is in the “driver’s seat” in generating the HTML & CSS; you are just passenger who is allowed a small bit of “backseat-driving”.
If your goal is something other than developing desktop-style apps, if you want to take full control of the HTML/CSS, then Vaadin may not be for you.
Updates
Vaadin 8 released
On Feb 22, 2017, Vaadin 8 was released. Biggest enhancement is re-written data model and data binding API utilizing modern Java features, such as generics with type parameters and lambda expressions. Also, more efficient with memory and CPU.
Vaadin 7 released.
While largely the same architecture as Vaadin 6, 7 is better than ever. See: What's New.
I would go with Rails 3.2 + Bootstrap + Backbone.js, the stack we use here.
Rails: Nice community, solid platform, very easy to develop for, can deploy to Heroku (God bless Heroku).
Bootstrap 2.0: HTML5-compliant, nice out-of-the-box features, good community (just look at their github page), sensible js plugins.
Backbone.js: Very nice for client-heavy applications, plays nice with the rest of the stack (specially jQuery), provides a good user experience when used right, unobstrusive. Specially good for dynamic forms since you can refactor a lot of code using specialized views (autocompletes, tables with multiple items, related select boxes, etc.).
As for documentation, both Rails's and Bootstrap's are top notch and you can find a lot of books about them. Backbone.js, despite its large user base, is more specialized, but you can still find a lot of good screencasts and e-books in the Net (I recommend the works of peepcode and thoughtbot).
Good luck with your app!
PS: Another good point of using Rails is the set of gems and addons you can use. Full text search? Sunspot. Audit and Versioning? PaperTrail. BDD? Cucumber. I suggest you checkout the Ruby Toolbox site.
I'm looking for a java based CMS application that will allow me embed specific UI 'component's or 'regions' (eg. newsfeed, page-section, video, etc.) into pages of an existing J2ee web application. The idea is to mix managed content with custom web-application function, where the 'dominant' web-application is our custom application but it integrates these components for which the content can be manged by A CMS. I have looked through a number of CMSs (Jahia, Magnolia, Alfresco, Nuxeo, Walrus and a couple more), but haven't found anything that readily provides managed components that I can integrate easily. Integration can be at the controller, jsp or even client (Ajax/iframe) level, but I am trying to stay away from introducing portlets into my stack.
I am currently using Spring and Struts2.
Thanks
I believe the Portlet Framework suits your needs here. Many CMS's support this specification and the main point is to absolve you from doing the low level, often very messy integration you're talking about. I use Liferay 6 with moderate satisfaction.
There are so many languages in web development that sometime I get confused which one to learn and start with. I like Java, but dont like JSP for presentation, are there any front-end technologies that best suits with Java/Java EE backend for web application development?
The web-layer technology that is promoted in recent JavaEE versions is JSF. It uses facelets instead of JSP for its views.
JSP with JSTL is pretty fine though, I don't see a reason to drop it. You can use it with any web framework, like spring-mvc, struts, or other frameworks with different rendering technologies like GWT, Vaadin, Wicket, etc.
With most things it depends on what your project requires. Here are two powerful web techologies you may find useful.
Vaadin (Front and backend integrated as pure Java)
For rich, AJAX heavy applications Vaadin can be a great fit.
Advantages:
- Rapid development for complex interaction between UI components and backend beans
- Pure Java solution, no need to worry about creating markup or maintaining massive javascript files
- Good documentation
- Many powerful components out of the box and through the open source community
Disadvantages:
- There can be a steep learning curve to understand the various components
- Extending/changing some features (such as how a UI table retrieves data from a data source) can be very difficult
- If your application needs to be highly scalable, keep in mind this framework is stateful
- Handling back button on browser and dynamic URLs is extra work
Spring MVC (Front is JSP or HTML, backend is Spring MVC)
If you want to maintain total control and scalability, Spring MVC with or without JSP is your best bet. Here's a good hello world and more spring mvc tutorials are available on that site.
Advantages:
Relies primarily on open standards
Highly scalable
Helps enforce proper MVC in your code
RESTful framework, allows the developer to easily handle dynamic URLS and GET/POST separately
Retain total control by creating the HTML/CSS/JS
Note: For a HTML/CSS/JS solution, I recommend starting with something like Zurb Foundation or Twitter Bootstrap. It will save a lot of time compared to starting from scratch. Download the latest and import it into your webapp folder to get a quick boost on your project.
Disadvantages:
- Managing AJAX calls can become challenging on large applications
- A more indepth knowledge of HTML/CSS/JS will be required (compared to Vaadin)
I think Spring MVC with ExtJS is the best option as ExtJS MVC really make the code readable and easy to manage. Similarly, IC of spring MVC will also make life easier for developer. I would recommend to look into Play framework. Play for java is good but if you want to dig more then obviously it will give you hard time as it mainly developed for Scala.
Depending of the front end type you want to write, there are several options. If you can accept the style and model, have a look at SmartGWT. if you want a more GMail-like experience plain GWT 2.2 is pretty nice.
I'm asking this question because I'm having some difficulty choosing a framework (or selection of technologies) that I can learn and use for developing a web-based UI for a small Java application:
For background information relating to the app I'm developing please read this question:
So, developing the Java application is going ok and now I'm in a position where I would like to develop a web-base UI for it.
The application and database (MySQL) currently run on a Debian Linux box, as such I've decided that it would sense to use Tomcat to run the Web App. The Web App is to serve the following purposes:
1. Manage the execution of the App by CRUDing data from the MYSQL database.
2. Display status information about the app (i.e. what orders it's placed, what orders are pending, etc.)
3. Produce on demand reports on stuff like the running profit and loss, historic and realtime prices and pricing analytics
So far so good now here's the problem:
There are a bewildering number of choices for how to develop the UI, to name a few I've looked at:
JSPs + Spring MVC
JSPs + Sping WebFlow
JSPs + JSF + Facelets
Wicket
JSPs + JSTL
etc, etc...
The choices seem endless. Is there's a clear industry standard for developing web based UIs using Java related technologies? If so what is it? Ideally I would like to learn a framework which I can use in the majority of real world jobs (and preferably one which can be used from Eclipse).
Thanks and Kind Regards
Personaly, I prefer another approach,
I would go for Eclipse of course, Spring (or other IOC container), Hibernate / JPA + JAX-RS or JAX-WS for the server layer, but not nessecarily JSF / JSP for UI.
For presentation layer, I would rather go with Flex, GWT, or a JQuery in an SOUI approach. (the service layer returns incremental updates in the form of XML or JSON, I swore not to mention the term AJAX)
Your service layer would serialize partial object graphs by demand from the presentation layer, which will act as a disconected client (work on an "offline" dataset , and update dirty on demand)
But that is just my wet dream, and in my current project I'm stuck with Spring MVC, and JSP + JSTL
I would give Jboss SEAM a test drive, just because Gavin King is behind it, but I think its JSF based.
I don't know why I don't see JSF as a SOFEA / SOUI approach, as JSF and AJAX go together well, but for some reason, JSF didn't win my enthusiasm as much as the above suggestions (Flex as a favorite)
See my related question: Web architecture: MVC, Lazy initialization, Data transfer Objects, Open Session In View, is there a consensus approach?
Is there's a clear industry standard for developing web based UIs using Java related technologies?
Well, Sun's Java EE standard is Java Server Faces (JSF) but the version 1.x of JSF is IMHO a kind of failure. This explains why they are so many alternative out there. But NO, there is no clear winner.
Ideally I would like to learn a framework which I can use in the majority of real world jobs (and preferably one which can be used from Eclipse).
Actually, Matt Raible has done very famous presentations on presentation frameworks that you'll find in Comparing JVM Web Frameworks Presentation (the latest version goes beyond Java frameworks only). Really, have a look at both of them, this is very, very good material (with real life metrics).
Personally, I'm a JSF 1.x skeptic so I would not go in this direction (there isn't lots of demand for JSF in my country anyway) but rather choose an alternative. I think that Struts 2, Spring MVC, Stripes (this one is my preferred one), Wicket (this one is getting more and more attention) are all decent choices, they'll all get the job done, the 2 first one being I believe more asked on the job market (but not the smartest). For the final choice, I'd follow Matt's advice: Eliminate, Don't Include. If the popularity on the jobs market is an important criteria, then I guess Stripes and Wicket will get eliminated. If configuration verbosity is a concern, Stripes wins. If you're looking for a kind of Swing experience, Wicket is your friend.
Now, I need to mention that the freshly released JSF 2 and CDI (JSR 299) should be a big improvement (according to the people who worked on it). As I said, I'm a JSF skeptic and I need to take a second look (because Gavin says so). But I still didn't so I can't say anything for now and I won't make any bet on the adoption and future market demand of this new version. But it's worth noting that JSF 2 with CDI should be a really new and different experience.
If you have a Java based web application (J2EE webapp - never mind which other underlying frameworks are being used), and you wanted to introduce a Flash based front-end, would you use Laszlo or would you rather expose a ReST-like XML interface and build and deploy a Flash application that uses that?
On one hand, Laszlo is quite amazing - doing for Flash what JSP does for HTML. It is easy to work with. It fits in very well with the rest of the web application (which is JSP based).
On the other hand it might be better to develop a complete Flash app decoupled from the server and use an XML-over-HTTP mechanism to bind the two. This would have the added advantage of being able to use the same XML interface for an AJAX front end if needed.
What would you do, and why?
I would create the contract-first services, deploy them separately, and then write the RIA client to access them.
Coming up with the schema first has the added benefit of completely decoupling the two during development. The RIA developer can create some synthetic XML streams to use for data while waiting for the services to come on-line.
I might have considered Laszlo in the past, but today, I'd stay within the Java stack and use JavaFX.
Laszlo is the product that never made it, there isn't a big enough ecosystem of developers around it.
I'd use Adobe Flex for the front end. The same benefits of using a markup language for doing flash, but it has a much larger developer base and open source projects to draw upon. For the data communication, use either REST or if you want to get clever, use BlazeDS.
OpenLaszlo is a complete RIA framework, so I'm pretty sure that you can 'compile' it to a completely standalone app that communicates with the server over HTTP. It's really very similar to Flex. The advantage Flex has is a much bigger community, a full-blown IDE, and more resources (Adobe), while OpenLaszlo is a little more innovative in that you can deploy to Flash or AJAX from one codebase.
I've actually spent some time working on a implementation similar to what you're suggesting. I had a complied Open Laszlo front end embedded in a web page with a Django (a python MVC library) REST interface on the backend and no Open Laszlo server. It works reasonably well, but there are a couple of things to watch out for. Open Laszlo only supports calls to GET and POST, so you won't be able to easily use the DELETE and PUT methods in your REST API. The other is the lack of community around Laszlo (as mentioned elsewhere). I can sometimes be frustratingly difficult to answer some basic questions when using Laszlo, particularly around the XML HTTP API and XML replication features in the framework. I personally never really looked at the Laszlo back end server seriously as I wanted an open API that could be consumed easily by other clients.
All this being said, the implementation does work and can be effective if you're willing to work around the limitations mentioned above. Plus Open Laszlo is free, which can be a really big plus if your working on a budget.