Develop Reference

Vaadin vs. Bootstrap

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.

How much effort needed to deliver a solution based on Apache Ofbiz?

I was trying to get some info from documentation, but it seems that it is one of those projects that you have to check out and play with it to figure the answers out ...
I noticed of hight activity on mailing list and quite a lot of commits, it's a good sign. But when I was looking into the code base (btw 536MB big - not a good sign), I didn't find to much J2EE app fashion in it. No spring, ejb, weird folder structure, quite a lot of non-standard jar libraries. It's like the developers didn't like it so they've done things their own way :-)
I've been using a few similar platforms, mainly portals and for example Liferay is quite easy to work with because it looks as one would expect it to. It is based on Spring, it has, transparent service and dao layer, it has simple plugin architecture (plugin = WAR) etc., typical J2EE development.
I'd like to know what are the key aspects that a developer should be aware of before he decides to use it. And as it is quite non-standard J2EE application, how much time consuming is to get to know it to be able to be productive.
What are its (dis)advantages in comparison with other ERP systems like OpenBravo. If I need mainly Cart rather then ERP backend, should I be interested in OpenTaps ?
I was also playing with Broadleaf Commerce which is way easier to start with.
Thanks very much in advance.

There is a learning curve and it's not easy to get skilled developers who understand the core of the system which is the Entity Engine and Entity Model.
The database model is built on the Universal Data Model which is why it can support a very wide range of data types. Even JIRA is built on the OFBiz Entity engine.
There are many Ecommerce shopping carts built on OFBiz, and it depends on the extent to which you need to customize products or build configurable packages.
It's very well suited for vanilla products i.e. pick and choose, compare, add to cart. Easy to call web services and expose web services, easy to integrate with PayPal etc. So if you're selling Tshirts and Flowers, it's good.
Anything like configuring a complex product like a laptop with various options will require some custom coding in Beanshell (BSH) or Groovy in addition to Java code.
Also it does not naturally integrate with app servers, it runs on it's inbuilt Tomcat but porting to Weblogic etc will be some effort.
The other problem is not enough detailed documentation, I would not say it is missing, it's light - the developer cannot expect an easy tutorial for eveything, it's more "ask and you shall receive" and you will get help on the forums - Usually you get direct replies from David Jones who wrote the framework, so that is helpful. But people who start with OFBiz need at least 3 - 4 months of studying the code and running simple applications before actually building anything.
That's my personal opinion, hope this helps.
I have not worked with Opentaps so really can't comment on that.

Re other Open Source ERP projects: watch out for projects dominated by one company, where the Open Source thing is a marketing vehicle, and it's really Open Core.
Open core means you pay for "plugins" to complete your system, and there is no incentive to standardise and to move functionality into the core.
If it's dominated by one company, they may take the project private at any time, as happened with Compiere.
OFBiz is a genuine community project hosted by the Apache Software Foundation.

Develop A Search Engine Front End In Java

I have to create a search engine front end for my IR project. I know java very well but I'm not using it for web applications yet. So, I need to choose what to learn to achieve my goal.
I found that java has many technologies such as : jsf , jsp , spring , gwt ... So what of these technologies suite my needs and which ones can I learn fast?
edit :
My web app should have two pages (first to submit a search query, and second to display the search results).

Since you know Java but not the plethora of web app frameworks, I would stick with GWT. While it does have a learning curve to be sophisticated with it, in fact you can build a working default app with one click in Eclipse. That will be enough to get you started.
Next you need a search engine. Lucene is the premier Java search engine application and is well-documented. However, it's large. You may get there faster using the VectorClassifier in Classifier4J. This will is simple enough that you can actually understand the whole thing in a limited amount of time (which would lead to a higher grade if I were grading this project).
Starting with the GWT Hello World "greeting" start app, instead of sending your name you send your search terms. Then in the servlet, you'd match the search terms to your documents with Classifier4J, which gives you scores. You'd return the scores in the greetService RPC call and show them with the document titles in your page.

Being the standard web framework in Java, I suggest looking at JSF first. It's relatively easy to learn and there are a lot of components available for it from third parties (e.g. PrimeFaces). Do make sure you start using a recent version of JSF (e.g. 2.0 or 2.1) as older versions (1.1, 1.2) are somewhat limiting.
Wicket and GWT are quite nice too, although GTW has a little bit of a learning curve. Then again, most every technology has such a curve and this really shouldn't stop a professional developer. Those two however are alternatives to JSF, you don't use them in addition to JSF.
I would not really suggest going with JSP and Servlets. Those are representatives of 2000-era technology that have little place in today's development landscape (Servlets definitely still have their use, but for specialized cases, not as a primary component for UI elements).

If you are not limited to page-oriented approach, I recommend you to take a look at Vaadin. It is based on GWT, but much easier to learn for a Java developer. I think the the functionality you need can be implemented in one or two Java classes.

I've the same use-case as you. Underneath I use Lucene as my search engine. The beauty of using IR libraries is that the search input screen is simplified. I have just 1 text-field on my web page (like www.google.com).
I'd suggest you stick to the basic web technologies of Java EE for this and those are Servlet and JSP. You describe the UI in JSP and have it POST it to Servlet and then Servlet will use a service layer for application logic.

I suggest if you don't have experience with Java Web app development, go for Servlet/JSP model. It's simple and intuitive. Also, JSPs can have Java code.
GWT is a bit complicated, so is Spring.

JSF
Wicket
JSP/Servlet

Servlet(JSP)||JSF & Elasticsearch||Solr
Yes jsf is the newer technologie but you didnt need something big for this project..
here is a nice example project https://github.com/scrutmydocs/scrutmydocs

What's the best modern way of developing open web apps with a rich JavaScript API for data access?

The company I work for has a powerful Java based server component framework for interacting with special control systems.
We have a UI framework but this is also Java based. A customer can use a Java Applet to access control information etc.
I've recently started working on a rich JavaScript API to access this control system information remotely. It's currently a prototype. It's nice because anyone who's familiar with JavaScript can access our Components remotely. So far it works really well. I've written some prototype applications that use this API. This gave me an introduction to jQuery - great! I've also added the ability for the JavaScript API to make RPC calls to Java as well as a session based Component architecture for when you really need something held on the server.
So far so good. I have to admit though that I'm not really a 'web developer'. I've never used Structs, Spring or any of the MVC based architectures for serious Enterprise based web development (I AM very familiar with design patterns though). My background is application development.
I'd like to know from the pros whether this is the right approach or whether I'm missing anything. Someone I work with has created a really neat Server Side Include architecture. However, I'm wondering now whether this is really necessary? After, I think I can create just about anything using my JS API and jQuery. Should I consider any other 'server' based architectures in this new age of open web apps?
As far as browser support goes, I'm not concerned about the older generation of browsers (please no lectures here, the old technologies we've got will do for IE6 and alike).
By using this open client side technologies, I'll be able to write sophisticated open web apps. Very little server side code will be needed in reality because of my API. I'll be able to take advantage of HTML 5 features etc. But am I missing anything? Should I be considering other server side based Java technologies like Server Side Includes? Am I too client focused?

Well there are four ways to create modern RIAs: HTML5/Javascript, Java Applets, Flash/Flex and Silverlight. Only the first two are open.
Applets are a nuisance and not really liked by people. Personally I'd go with HTML/Javascript.
Since you are a Java shop I'd recommend going with GWT for the following reasons:
It's open source with business-friendly license.
It creates minimum-size browser-optimized javascript.
It's actively developed and used by Google. This is a guarantee that it'll be supported for some time.
There are a lot of developers with knowledge of it.
It has good documentation and very active user group.

I'm sure there are many opinions on this, but my take is that with HTML5, faster Javascript interpreters, client side persistent storage, etc. it makes it pretty compelling to put all the UI application login in the client (browser), and just use some form of RPC (with JSON serialization) to the server. Therefore templating engines, SSI, or any server side generated markup is no longer required for interactive applications. It's still fine for semi-static documents. For that I use sphinx document generator.

Fast-forward two years, and you now have TodoMVC at your disposal to help answer this question. GWT is still mentioned, though as far as server-side technologies go, The Holy Grail is probably what you're looking for to maximize code reuse on client and server.

Restrictions/disadvantages of developing portlets for Liferay [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm considering developing an application as portlets, to be integrated in Liferay portal. Are there any significant disadvantages or restrictions in developing such an application, as opposed to developing a normal web application using Spring framework?
Liferay seems to require that all content is added as portlets. Another option I ponder is to use Liferay just for some parts of the application and add external links to other self-developed content, developed as a normal web application. That would, however, create a need of multiple user authentication mechanisms and some kind of cross-site authentication between Liferay and the other web application.
Which is the best way to go?

(Disclaimer: I'm one of Liferay's developers)
I think both options are good depending on your needs. If you have previous experience developing standalone web applications but no experience developing portlets, then picking the former will get you started faster. The drawbacks would be that you would have to implement your own users and permissions system and would not be able to leverage the portal services provided by Liferay. If you decide to use this alternative, note that you can deploy regular WAR files to Liferay and it will automatically create a simple portlet that uses an iframe to show your app. This will allow you to put the standalone app along with the portlets in Liferay's pages.
Developing a portlet for Liferay starts to pay off when you start leveraging the portal services it provides. To start with by developing a portlet you can forget about developing your own user system and use the one that Liferay provides (which is quite powerful). You can also use other services such as permissions, comments, tagging, categorization, data scoping, etc. which will allow you to develop pretty complete application in a shorter time. The drawback is that the first time you do this you'll have to learn several new things, but the second time you'll go much faster.
I hope that helps.

I've been using Liferay for about 2 years now for an internal application. We had the same discussion many times throughout the development cycle before our first release. We had to fight Liferay a few times, sometimes because of our own lack of knowledge, sometimes because of the portlet environment, and occasionally because of Liferay.
If you want the layout options for multiple applications that you can get from a portal, then you should certainly use Liferay. If you are writing a single application, then I would probably not use Liferay. I think a hybrid of some Liferay and some not is by far the worst option.
We are probably not leveraging Liferay to its fullest capabilities, but if this is your first Liferay app, then chances are you won't either because of the learning curve. We originally hoped to have many different portlets for the different aspects of our application, but due to a lack of good inter-portlet communication mechanisms during development ( pre JSR-286 ) we ended up writing a single application. Now that we ended up in that boat, I wish we had gone without Liferay since all we are really using is some user management capabilities.
We use JSF and facelets (both new technologies to us, so the pain may have been self inclicted) and while we've gotten better at it, it seems like there were a few hoops we had to jump through in order to get it working correctly in a portlet; Things that wouldn't have had to happen in a regular web-app environment. For many frameworks, it seems that portlet support is an afterthought. This is obviously not Liferay specific, it's just a byproduct of working within the portlet environment.
In a webapp using Spring MVC, Struts, Faces, Wicket, whatever, you are going to have a lot more control over everything, but also be responsible for implementing more stuff.
In a portlet, you are going to be subject to the terms of JSR-168 and/or JSR-286. The portal container will provide some functionality for you, like user authentication, but IMO, an entire portal for user authentication is way too heavy. I see the power of the portal being allowing the user to customize their view of multiple applications, not presenting a single application.
You should review the portlet related specs and see if it fits your needs.
http://developers.sun.com/portalserver/reference/techart/jsr168/

Liferay is a extremely powerful system, there are many services and applications which are available ready made but the biggest drawback is the lack of documentation. It impossible to know everything just looking at the code, So in my opinion if you dont have the expertise dont go for Liferay.

Liferay and portlets in general are great for a very specific class of applications. If you are working for an IT department and need to combine apps for or by several departments then portlets would be the way to go. In theory you can drop in portlets from different venders and they will all live in harmony inside of the same environment.
However if you are building an application that is any of the following
1) created entirely by a single team
2) has a single source for the requirements
3) has requirements that aren't a subset of the features available in the portlet container.
4) has a graphic designer that isn't willing to live within the confines of portal style applications.
then sticking with something like Spring would be the way to go.
Spring and its many sub-projects provide a lot of the shared services and infrastructure offered by portlets but they are offered in an open and more flexible way. You can pick and choose what you want.
Portlets make a lot of the design decisions for your in terms of authentication and authorization, navigation and layout. If the plans you have for your application fall outside of those decisions you will spend a lot of time creating workarounds to try and get it to do what you want.

Everybody, please do not take this as trolling/flaming. This is something I feel Liferay community should address and everyone thinking of using Liferay should know.
Disadvantage: No documentation. Nothing even remotely like e.g., documentation of Hibernate. Just an empty javadock (no comments in code), some answered questions in forums and books for old versions (useless).

I've always thought that Portals such as Liferay should be considered as akin to a shared infrastructure. They provide a common way to access applications, shared services (eg. authentication) and a standard way of deployment, but at the cost of performance.
If you intend to deploy more than just this application into the Portal then, yes, it's probably appropriate as you'll get time/cost savings from not having to develop those shared services a second time. And subsequent applications will look and behave in a similar fashion to this one.
However, if this is the only app to be deployed then the overhead of the Portal is not really worth it and you're better off going with a normal web application.

Liferay has CMS functionality and can integrate with external CMS platforms such as Alfresco.

Man, check out this solution Netbeans IDE + PoralPack3.0 plugin + Liferay 5.2 bundle. The Portal Pack here helps you by providing a nice GUI editor for service.xml file where you can define the entities or database structures and from the same GUI you can generate the services code which can be used inside your portlet.
For more info check the below given link:
http://www.liferay.com/web/satyaranjan/blog/-/blogs/portal-pack-:-write-database-portlet-using-service-builder-plug-in