Fórum

Vaadin Vs Primefaces Vs Alloy UI?

thumbnail
Carlos Adolfo Ortiz Quirós, modificado 11 Anos atrás.

Vaadin Vs Primefaces Vs Alloy UI?

Junior Member Postagens: 40 Data de Entrada: 22/05/10 Postagens Recentes
Hi everyone

I recently came across with the following dilemma: I'd want to use Vaadin 6.8.1 but I'd also want to use Primefaces 3.x? The same is for the inner Alloy UI that is used with Liferay 6.x.

Question here is: Knowing that each of them has its pros and cons, which one do you recommend me? I am so inclined to use Vaadin because it is a very responsive. But I want your opinion as well, in a very important way.

Thanks in advance and looking forward for a clue on this regard.

Atte.
thumbnail
David H Nebinger, modificado 11 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI? (Resposta)

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
We're using vaadin almost exclusively. Creating vaadin-based apps is like building Swing applications, and our devs don't have to know the java side, javascript, plus whatever other technology for rendering views.

That said, some things in Vaadin portlets just takes time getting used to, and there are some inherent concerns:

1. Resource usage - I haven't gathered any metrics on this yet, but I need to know more about the impact of a lot of Vaadin portlets and the class loader. Normally you'd move frequently used jars to the global class loader so each portlet doesn't have a duplicate instance of the jar loaded into memory. I'm not sure how Vaadin would work in the global class loader, if such a move really saves much, ...

2. Adapters for Liferay SB entities and paging. SB interfaces support paging through lists (i.e. by passing starting and ending info), but the Vaadin containers only have adapters for JDBC paging. Since one doesn't do JDBC in portlets, you're left to your own devices for handling the paging.

3. Upgrades are somewhat of a pain. We do the vaadin.jar update via an EXT plugin, the /html/VAADIN updates using a hook (themes only, no widgetsets because we use the Vaadin controlpanel for liferay to handle that). For awhile there were regular and frequent updates to Vaadin (the 6.6 and 6.7 versions went through many iterations), and we kept current because the bugs fixed per release typically touched on things we were using.

4. Theming is a pain. Vaadin themes live outside of the Liferay theme, so rather than managing a single theme for your Liferay pages, you're now managing two themes.

5. Some things are just plain hard to do in vaadin. For example, we needed to show/hide a div depending upon whether the mouse was hovering over a gear icon. After numerous attempts at trying to do it correctly in Vaadin & CSS, we eventually had to use plain old Javascript to get it to work correctly (and it is not so easy getting Javascript control of Vaadin elements).

That said, we love the Vaadin visual editor. It's easy to construct a basic page using the visual editor, then flipping over to the code editor to wire up the event handlers. Since it's fully AJAX, page refreshes do not affect values user has entered in our Vaadin-based apps (server side has the info the user was in the process of entering).

It's a great little framework that we've had a lot of success with.

We don't use Vaadin for everything, though. Anything that requires a lot of visual appeal, we do in something with a little less weight (typically just JSP/Liferay MVC).
thumbnail
Carlos Adolfo Ortiz Quirós, modificado 11 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Junior Member Postagens: 40 Data de Entrada: 22/05/10 Postagens Recentes
@David

Thank you very much for your time.
I have read and will take that into account.
I am precisely deciding on Vaadin.
One more thing, I am a newbie in Vaadin, would you help me on issues about it? I am trying to configure latest version in Portal and trying to make a portlet out of the Address book example (Vaadin example) but get no results.

Thanks.
thumbnail
David H Nebinger, modificado 11 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI? (Resposta)

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
I think I'm going to put together a wiki page on this, but here's the key info:

1. To use the latest vaadin, download the jar and replace the ROOT/WEB-INF/lib/vaadin.jar with the newer version (always name it vaadin.jar).
2. You should also download the vaadin liferay upgrade zip file. The contents of this file should be unzipped to ROOT/html/VAADIN as it contains the theme updates/bugfixes.
3. You should have the vaadin controlpanel for liferay installed in your system. After making any change (such as this), you must always go to the control panel and compile the widget set.
4. When adding new widgets, drop their jar files into ROOT/WEB-INF/lib, then use vaadin control panel (check the box for the widget to include) and compile the widgetset.
5. Your portlet should never have it's own copy of vaadin.jar, you should always use liferay-plugin-package.properties to pull in Liferay's version of the vaadin.jar (same w/ all of the plugins), and never have them in your own WEB-INF/lib directory.

Note that placing vaadin portlets on a page initially never seems to work out too well (at least for me, anyway). Do a page refresh and it will be there, though.
thumbnail
Carlos Adolfo Ortiz Quirós, modificado 11 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Junior Member Postagens: 40 Data de Entrada: 22/05/10 Postagens Recentes
Thank you very much for this tips. BTW, do you have some example portlets using Vaadin and any other view technology so I can learn a little more about how to build Portlets at hand. I am researching (that is, newbie) porlet development, and as I advocate for Spring framework I lack knowledge in Spring Porlet MVC as I would like to use it.

I harness this opportunity to ask you other facts:

Why don't you recommend JDBC in porlet development?
Liferay Service Builder is useful, in my opinion, only if tables are stored in the same database as the portal, but what about tables stored outside Liferay database, i.e., suppose one table is for products and it cannot be stored in the same portal database, it has to be in another schema, thus to gather that information Liferay Service Builder cannot be used (in what I know), thus a service strategy must be implemented to access that table data, is it feasible, or what do you advice?
thumbnail
David H Nebinger, modificado 11 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
Carlos Adolfo Ortiz Quirós:
Thank you very much for this tips. BTW, do you have some example portlets using Vaadin and any other view technology so I can learn a little more about how to build Portlets at hand. I am researching (that is, newbie) porlet development, and as I advocate for Spring framework I lack knowledge in Spring Porlet MVC as I would like to use it.

I harness this opportunity to ask you other facts:

Why don't you recommend JDBC in porlet development?
Liferay Service Builder is useful, in my opinion, only if tables are stored in the same database as the portal, but what about tables stored outside Liferay database, i.e., suppose one table is for products and it cannot be stored in the same portal database, it has to be in another schema, thus to gather that information Liferay Service Builder cannot be used (in what I know), thus a service strategy must be implemented to access that table data, is it feasible, or what do you advice?


I don't have anything that I can share, although I am hoping to get some stuff into the marketplace so maybe I should get to work on it...

Spring and Vaadin are separate entities. Integrating them is fun. There are some addons from Vaadin which can help with the integration, but you really should know something about both for them to make some sense.

Well, separate questions should be posted as separate threads...

That said, a portal is a cooperative environment. Portlets typically are not islands, they usually are combined visually and interact with each other. Therefore they will also typically need to share entities, DAO layers, etc. If you do not use SB, you risk using many more resources than necessary and have to be concerned with deadlocks and/or update collisions...

Say, for example, you create 5 portlets that you are going to drop onto a single Liferay page. These 5 portlets are related to your bookstore business, and although they are related you have them deployed as 5 separate plugin projects. Each one is going to have to look at your inventory, your customer database, purchase history, etc. in some form or another, either combined or separately.

Now with this scenario, if you're going to use JDBC that means since the 5 projects are deployed separately, they must each have a database connection (or pool of connections) so they can retrieve the data they need to display. This is where the resource consumption increases, because they cannot share the connection pool. Deadlocks and update collisions come into play when you have multiple updators to the data; two portlets updating the same table/data at the same time (likely since the portal page would have all portlets synced up on the same information), each is trying to update the same info at the same time and could be a potential point of collision and/or deadlock.

Now if instead you did things the Liferay way using Service Builder, all of these issues go away. SB code can be used on all 5 of the portlets, so there's no code duplication. The service providing portlet (the one with the service.xml) is the only one with the database connection (pool), so your resource usage is manageable. With only one piece doing the adds/updates/deletes, your collisions and deadlocks are greatly reduced. Finally, since SB enables EhCache (or whatever caching mechanism you're using) for entities, calls to retrieve data might not have to go to the database at all.

SB has it's problems, certainly, but the benefits you garner from using SB from the beginning make it well worth it.
thumbnail
Brian Kim, modificado 11 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Expert Postagens: 311 Data de Entrada: 17/08/04 Postagens Recentes
That's a really great explanation of the benefits of our ServiceBuilder. Thanks David.
thumbnail
David H Nebinger, modificado 11 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
Brian Kim:
That's a really great explanation of the benefits of our ServiceBuilder. Thanks David.


No problem. I try to encourage everyone coming to Liferay to use SB. It is lacking some functionality I'd really like to have personally (i.e. a non-DB entity so I can define the entity, get the whole XxxLocalServiceImpl and XxxServiceImpl support for defining methods, yet still have the whole CLP mechanism so it is available in other plugins). But in the end you just can't beat the functionality of being able to centralize your data services yet have the code accessible both to local plugins and web services too!

The difficulty, of course, is convincing folks it's the way to go. When you come from a servlet-type framework where you have to manage your own connections, generate your own hibernate framework, and wire it all up with spring, you automatically start down the same path just replacing "servlet" with "portlet". Unfortunately the impact of that decision is not apparent until you get a lot farther down the development cycle, then it becomes clear that the old way just doesn't work with the new way...
thumbnail
Carlos Adolfo Ortiz Quirós, modificado 10 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Junior Member Postagens: 40 Data de Entrada: 22/05/10 Postagens Recentes
This is a follow up to this post I made.

Today (Oct.10/2013) I read it again, I noticed that the post has 10152 views,

Now I am changing my view about Vaadin and Alloy UI.
I have not studied any of them.
I said a way back time to be inclined by Vaadin, no I changed my mind.

I considered Vaadin because it is pure Java to JavaScript and other goodies. But as someone in the commentaries has stated some difficulty and had to use pure Javascript.
As today, many mature Javascript exists and also it is a matter of using the 'Responsive Web Development' trend which is in Liferay 6.2 that has attracted me quite much to consider Alloy UI and Boostrap, thus, I am still now and again evaluating what is the best tool.

About Primefaces, I discard it as I don't like JSF. A matter of taste, maybe I consider it again or I am forced to .

Alloy UI is based in YUI 3, and is heavily used in Liferay (and is a sponsored Liferay project) thus it is fair to use it.

The only way to consider a tool is by building a proof-of-concept? Any ideas. Hope someone has some opinion to refute my current state of thinking.
thumbnail
David H Nebinger, modificado 10 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
Alloy may be new, but if you're left to building jsp and struts in order to get the pieces working, I don't know I'd consider that to be any better.

Vaadin (one of my favs) is an easy way to get a business portlet created; you code everything in java and you get an ajaxy portlet that works really well. Not always the best tool for every job, but certainly makes business portlets easy. And, if you use the right layouts, it can be pretty responsive on it's own.

Primefaces is JSF; if your team knows JSF, then you can't lose with Primefaces.

Just my own opinion, but w/ Alloy I think you end up having to manage so much of the code on your own. I mean seriously, most of us have given up coding native javascript in yui, jquery, etc. when we don't need to. In some cases yes, it will be necessary, but it's not going to be the case most of the time.
thumbnail
Carlos Adolfo Ortiz Quirós, modificado 10 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Junior Member Postagens: 40 Data de Entrada: 22/05/10 Postagens Recentes
David H Nebinger:
Alloy may be new, but if you're left to building jsp and struts in order to get the pieces working, I don't know I'd consider that to be any better.

Vaadin (one of my favs) is an easy way to get a business portlet created; you code everything in java and you get an ajaxy portlet that works really well. Not always the best tool for every job, but certainly makes business portlets easy. And, if you use the right layouts, it can be pretty responsive on it's own.

Primefaces is JSF; if your team knows JSF, then you can't lose with Primefaces.

Just my own opinion, but w/ Alloy I think you end up having to manage so much of the code on your own. I mean seriously, most of us have given up coding native javascript in yui, jquery, etc. when we don't need to. In some cases yes, it will be necessary, but it's not going to be the case most of the time.


mmm. Why it always has to be so hard to choose the proper technology to use, I mean, I am considering a new Liferay project from scratch and it needs to use the proper tools.

In my personal position. I don't like JSF and unless someone makes me change my mind, it is not an option.
I read about the YUI/ALLOY UI stuff and it states that it is for scalabe web sites, but jQuery UI or just jQury plugins for the sake are easier to learn and use, not so for YUI/ALLOY, and of course it is part of it to handle so much code.

Vaadin is a pure Java solution but in some cases you resort to Javascript/CSS anyways....


This left me to wander a little more in the subject or start making Proof of Concepts.
thumbnail
M J, modificado 10 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Regular Member Postagens: 184 Data de Entrada: 01/03/13 Postagens Recentes
Carlos,

I am using Liferay 6.1, Bootstrap 3 (responsive), jQuery, jqGrid, svg, and d3.js for my Liferay project. You don't have to touch AlloyUI for any of your development in Liferay. Liferay has to support AlloyUI because they made the wrong choice over jQuery. Bootstrap is based on jQuery, so, I think, Liferay team had to modify AlloyUI for Bootstrap for Liferay 6.2 version. What a wrong choice they made (AlloyUI)! Are there anyone in the world using AlloyUI other than Liferay? I hope not.

Let's admit, Javascript is here to stay. If you want to do any DOM manipulations in the browser, you have to know Javascript. It's not that hard to learn! It always puzzles me why do you have to use java (Vaadin) in order to generate javascript? Why can't you write it in Javascript using libraries like jQuery? If you are a Java programmer, I am pretty sure you can learn Javascript in a month.
thumbnail
David H Nebinger, modificado 10 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
M J:
Liferay has to support AlloyUI because they made the wrong choice over jQuery.


Are there any other clueless folks that want to chime in? Seriously, Liferay presented their reasoning for abandoning jQuery. You can find the wiki page here, but basically it is a better framework for portlets. And another good explanation is found on Nate's blog.

You're welcome to your opinion, but you're hardly in a position to judge Liferay's decision.

It always puzzles me why do you have to use java (Vaadin) in order to generate javascript?


Again, this is due to what you don't understand (Vaadin) rather than delivering some educated viewpoint.

We use Vaadin for our portlets primarily because we have Java developers. While you may think that Java and Javascript are the same or similar, but in reality they are two different things. Experienced Java developers are not instantly experienced Javascript developers, and it takes time to become an experienced Javascript developer.

The biggest benefit that we got using Vaadin was a complete transparency between client and server code. In my Vaadin code, I can bind a ClickListener on a button to react to button clicks. Inside of that ClickListener's buttonClick() method, I can (for example) call SB code to insert a record into the database.

With the total code transparency, I have no idea that the button is actually going to be added to the page in the client-side DOM via javascript, that there's an onClick handler on the button that, in turn, will submit not only the button click but all form data through to the server side, that the server side will update the server-side representation and invoke the Java event handling code, and that everything (including session details and run time context stuff) is prepared for me.

I just write a few lines of Java code and I have a speedy portlet running in the browser (because it is all ajax/javascript based) that has transparent integration w/ server side code (I'm not writing any special receiving code on the server to set up context, etc.), but setting it all up so when my code runs I have the full context for what is available in the browser.

Sure, you can argue that javascript is easy to learn, but for you to handle the javascript stuff, the server side development (including the partial ajax form submit stuff, etc.), it is going to be a large undertaking to create a working app. Meanwhile I've deployed my portlet and moved onto the next project...
thumbnail
M J, modificado 10 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Regular Member Postagens: 184 Data de Entrada: 01/03/13 Postagens Recentes
David,

I started developing in Liferay only few months back (version 6.1). Yes, I had seen those AlloyUI articles you mentioned and I initially thought AlloyUI was a better choice than jQuery. So, I decided to use AlloyUI. I developed a test page with Autocomplete component in AlloyUI. There was no way I could put the dropdown automatically drops as you type. I googled, posted here, no help, nothing. It just wouldn't work. Then I changed to jQuery and use jQuery Autocomplete, viola, worked like a charm! Then I wanted to use some javascript grid components that can be used to edit the data in the backend database. No components available for AlloyUI (I couldn't find one yet). Searched for the same thing for jQuery and I found jqGrid, Slickgrid, datatable, flexgrid etc and I chose jqGrid. These are couple of reasons that I decided to stick with jQuery over AlloyUI.
thumbnail
David H Nebinger, modificado 10 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Liferay Legend Postagens: 14914 Data de Entrada: 02/09/06 Postagens Recentes
I get it, and I can't fault you for choosing jQuery. Alloy has suffered from a lack of documentation, lack of examples, and lack of experienced devs in the forums (for question handling).

All of that is true. But what is not true is to say "Liferay made a mistake in choosing AlloyUI". They had valid reasons for choosing Alloy, and until we are portal architecture experts, I don't think either one of us can sit in judgement of their decision. As with most internals, Liferay understands them better than we on the outside would and make choices based upon their understanding. I wouldn't believe for a second that Liferay chose Alloy out of spite or malice or anything other than it was the best decision to solve specific problems within the Portal sphere.

And just because you and I might not understand how to do the autocomplete or grid stuff in Alloy doesn't mean they can't be done emoticon
thumbnail
Carlos Adolfo Ortiz Quirós, modificado 10 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Junior Member Postagens: 40 Data de Entrada: 22/05/10 Postagens Recentes
Whew. A lot of material has been written lately in this forum, I appreciate all you guys who have written valuable information.
Hope to watch more comments until I got a clue and understanding as to which technology to use.

Thanks to David H Nebinger and M J (see posts) for your unremarkable comments.
Hope soon to close this entry.
thumbnail
Carlos Adolfo Ortiz Quirós, modificado 10 Anos atrás.

RE: Vaadin Vs Primefaces Vs Alloy UI?

Junior Member Postagens: 40 Data de Entrada: 22/05/10 Postagens Recentes
A very tough topic indeed?