I am using ui-grid.
We are migrating our project from angular 1 to 2, but ui-grid doesn't have angular 2 support.
please suggest free (MIT) license grid alternative for ui-grid.
I was researching this recently, since I have an application that I used ui-grid on, and may be upgrading to angular 2 soon.
I've found...
Angular Datatables
https://l-lin.github.io/angular-datatables/#/getting-started
ag-Grid which has a free version https://www.ag-grid.com/
I have implemented UI grid(AngularJS) into angular 2 using UpgradeModule and it is working fine, and I have also done some modification into that for gridOption which we can sent gridOption from typescript to UI grid.
Please find demo application : https://github.com/Umesh-Markande/Angular-4-Ui-grid
I know this is an old question but in case some people are still looking for alternatives...
I'm the author of Angular-Slickgrid, which is a wrapper on top of SlickGrid but specific for Angular, it is most probably the closest you can get to UI-Grid. There's over 300 stars for the project and it's very well maintained with lots of Wikis and samples, I have constantly added new features for the past 3 years since its creation and most UI-Grid features, and more, exists in Angular-Slickgrid. It also has 100% unit test coverage with Jest and also multiple E2E tests with Cypress.
Ag-Grid is another good alternatives but their best features are simply not free (quite expensive too) which is the biggest reason that I've built Angular-Slickgrid for our multiple projects.
See for yourself, here's a Live Demo with 30 different examples
Check out the Table component in Angular Material. Check out this example to see how it supports filtering, pagination, and more.
Related
preamble: I'm an advanced Vaadin developer (I've used 6, 7, and now all my project are migrated to Vaadin 8).
I'm starting to study Vaadin 10 / Flow, but I find myself in some hot waters.
What I'm actually struggling with is the "project" itself.
The more I deep into, the more I feel like this framework is moving into a css / html based framework, which requires more css/html knowledge than java.
What I mean is that if you don't perfectly know how css and html works, you can't use this framework easly anymore.
The problem is that I don't know if I'm totally missing the point here and I'm losing into a glass of water, or if that's if really a totally different framework.
Here is where I'm asking an opinion from you, and some confrontations.
I'm finding some very good stuff like #Router and all new navigation paradigms and new Mobile First components, but in example I really can't find a rapid way to build a nice look and feel layout without working with css and html.
Easy stuff done with Vaadin 8 looks now for me very hard to understand... like Templates: working with Vaadin 10 Designer is really, really weird.
I hope I'm simply missing the point, and some of you can help me clearing my thoughts.
I share your concerns about Vaadin Flow. Here are some impressions I have gathered in learning about Vaadin 6-14, studying the doc, reading the forums, watching the Vaadin Ltd YouTube videos. While I do not cite technical proof for every point below, this might help you orient to the purpose and new reality of Vaadin Flow.
Web browsers have matured
The years in developing HTML5 are paying off with huge rewards now.
One of the major goals of the leaders of WHATWG was to rewrite the specs from the practical viewpoint of programmers trying to actually build real browsers. As a result, the modern browsers have far more behavior in common than ever before, with far less “quirks”. Web apps nowadays behave much more predictably across the major browsers.
Also, note that the web browser makers have consolidated in their use of engines. Every major browser has abandoned their own engine to use either Apple WebCore/WebKit or its spin-off Blink/Chromium. Even Microsoft has given up on its own browser engine Trident/EdgeHTML, and has switched to Chromium for their line of Microsoft Edge browsers. So Safari, Edge, Chrome, Opera, Brave, Vivaldi, and so on are all using much the same engine now, for much closer behaviors. Only Mozilla Firefox continues to use its own web browser engine, Gecko (except for Firefox for iOS which uses WebKit per Apple policy). So, we are down to two main browser engines: WebKit/Chromium & Gecko.
This means a major burden on the previous versions 6, 7, and 7 of Vaadin, making up for behavior differences between browsers, has greatly eased. Vaadin’s internal design can now work more directly with the web's own HTML/CSS/DOM model without having to create it's own intervening layer of behavior.
CSS
CSS has improved radically in recent years with CSS3 finally getting fleshed-out and widely adopted.
For decades the experts said “don’t use HTML table for layout” yet offered no page layout in CSS except for the anemic float feature. Finally, CSS 3 offers real layout, feature-rich and robust. And more amazingly, apparently the browsers have broadly supported these features with very compatible implementations. These new layout technologies are Flex-box and Grid-layout.
By the way, there will be no “CSS 4”. Each of the functionality areas comprising CSS 3 is now its own project with its own development and versioning. This is explained well in one of the excellent videos by Jen Simmons on YouTube channel LayoutLand though I cannot locate it at the moment.
Flexbox
Arrange items in a 1-dimensional horizontal row or vertical column. Control stretching-shrinking, inbetween-spacing, left-centering-right positioning, and relative aligning including baseline.
See this excellent visual guide and tutorial.
Sound familiar? CSS flex-box provides the same kind of functionality as the Vaadin HorizontalLayout and VerticalLayout classes. Indeed, in Vaadin Flow those classes have been rebuilt to directly use this CSS functionality rather than recreating that behavior within Vaadin. Vaadin Flow has changed its terminology to match that of the CSS standard, such as setExpandRatio becoming setFlexGrow.
See what versions of what browsers support Flexbox.
Grid Layout
Arrange items in a 2-dimensional grid of rows and columns. Features are similar to to arranging data in cells in an HTML table. Contents can be aligned up-down or left-right within the cell. Contents can optionally span across multiple cells. You can control gap-spacing and justification.
See an excellent tutorial by the same CSS-Tricks.com site as mentioned above.
Sound familiar? CSS grid layout provides the same kind of functionality as the GridLayout in previous versions of Vaadin. The GridLayout class in no longer built for Vaadin Flow, but you can get much the same behavior using a Vaadin Div object combined with direct CSS commands.
See what versions of what browsers support CSS Grid.
Roll-your-own AbsoluteLayout
On a related note, CSS now provides for on-the-fly pixel-oriented layout. Again, this seems to be well-supported across browsers in a consistent matter. So in Vaadin Flow, they decided to drop the AbsoluteLayoutwhich provided this ability to layout widgets in a x-y coordinate system.
In place of AbsoluteLayout, you can make your own simple little layout class by extending the new Div component. In that subclass, for any given widget, you can extract the Element object that represents the HTML element for that widget within the rendered web page. With that Element in hand, you can specify the left & top (x-y) coordinates to be respected.
CSS can be updated dynamically now, so you can change positioning around, or add/drop widgets, within this layout dynamically during runtime.
For an example of such a CSS layout subclass of Div, see Replacement for AbsoluteLayout from Vaadin 8 Framework in Vaadin 10 Flow?.
Web Components
The emerging Web Components technologies are a game changer, having replaced GWT. They allow web pages, and web apps, to be assembled as a collection of chunks each with their own little world of HTML, CSS, and DOM. This encapsulated scope lets a chunk be added without affecting the rest of the chunks. For example, no namespace collisions in naming of CSS classes and identifiers.
This has meant a huge re-write of the Vaadin internals. And so we must be patient (or just keep using Vaadin 8), as some parts we rely on in previous Vaadin are gradually added to Flow. See the page in the manual on Components in Vaadin 10 for a comparison of v8 versus v10/11/12 components. This page has been kept up to date. For example MenuBar changed from being unplanned to now being expected in Vaadin 14.
On the downside, some features of previous Vaadin may not appear. But read that page carefully and research. Some parts that Vaadin previously created on its own are now directly represented as now-reliable HTML or CSS features.
Conclusion
Like you, I have mixed feelings about Vaadin Flow.
The recent talk from Vaadin Ltd about “mobile first” is worrisome. That seems tangential from their legacy of building serious business apps, enterprise-style invoice/purchase-order/accruals kinds of apps, “boring” software as I call it (and make my living from), as opposed to startup-of-the-week web app with severe design and wacky interfaces.
Some parts important for enterprise business apps such as menu bars are currently missing with no good workaround. The Web Components technologies are relatively new in the industry, and will likely have some rough edges and problems in these next few years. The nice safe Vaadin-only bubble I enjoyed is now porous, with app development likely to have some need to involve a bit more CSS or other web tech.
On the other hand, it looks like the enterprise/business features may come, either from within Vaadin or from outside as web-components wrapped as Vaadin objects. The Web Components technologies and their various polyfills are not new, and have been worked on seriously for some years by many people, and seem to be workable now. As for CSS or other web tech leaking into Vaadin, I do not minding learning a bit more about these given how robust and well-designed they are now and how that means much more documentation and stability may come with them, with Vaadin not having to re-create features across squirrelly browsers.
And some of that porousness of CSS/HTML leaking-in may be closed where it makes sense and provides convenience to the Vaadin programmer. For example, I noticed in the Vaadin-12 Releases page, there is a new Java API for choosing an alternative built-in component style from Lumo or Material theme for any of the components that have a variant, along with convenient Java constants defined for naming those variants. Ex: primaryButton.addThemeVariants( ButtonVariant.LUMO_PRIMARY ) ;. This alleviates the need to access the inner Element and manipulate CSS.
I believe in the long run, the future for Vaadin is bright. As a server-side stateful application server able to auto-generate web app clients from (for the most part) non-web programming leaves it as an amazing tool in a position with no direct competition (save Xojo Web Edition, using a similar architecture).
Resources
Should you upgrade to Vaadin 14?by Marcus Hellberg 2019-08-21 on Vaadin.com blog
V8 vs. V10 - two maintained Vaadin versions, which one to choose?by Matti Tahvonen 2018-06-13 on Vaadin.com blog
Vaadin 10 keeps the same philosophy of previous versions: Implement the UI with Java. No need to use HTML or JavaScript at all. Vaadin 10 added some support for HTML templates, but it's an optional feature.
This video can help you to understand Vaadin 10: https://www.youtube.com/watch?v=Un8zKzw6twM
The Wikipedia page for Vaadin is also useful: https://en.wikipedia.org/wiki/Vaadin
Read the documentation chapter on migrating from Vaadin 8 to Vaadin 10.
I'd like to start developing a new project using sproutcore. Since 2.0 seems quite different to 1.6 and there are already three betas out (and so I expect and RC soon?) I wonder if it'd be a good decision to start directly with sproutcore 2.0 intead of 1.6.
The sproutcore app will be backed by a rails app which exposes a rest json api.
Sproutcore 1.x and 2.x are indeed targeting different types of applications. So, the decision to choose 1.x or 2.x mainly boils down to the question which application type you are going to develop.
Choose 1.x if you need a set of predefined components, e.g. if you plan to develop an internal CRUD-like application. You might use the new template-based approach in some places but your main application will be composed with predefined components. SC 1.x clearly targets desktop-like applications.
On the other hand if you plan to build the next twitter or github or stackoverflow, you should use SC 2. It's easier to embed into webpages and you are in control over the complete layout, html and css but it is clearly more work to do in regards to html/css. If you've to implement your own design it's probably easier with SC2 because you are in full control. If you've already profund jQuery knowledge you can use this with SC2, it's no problem to combine the two, in fact since SC2 fully builds upon jQuery it's already included ... where SC 1.x only uses a special stripped down embedded jQuery version. If you plan to use certain plugins this might be a problem.
The programming model for your model and controller parts is nearly the same and it is very easy to transfer those parts from SC 1.x to 2 (and vice versa), the main difference is the view part.
I have to partially disagree with the above comment. The goal of the SproutCore framework is to help create near native user experiences using the web technology stack. That goal has not changed from 1.x to 2.x. What has changed is that SC 2 was built from the ground up to be modular (and thus lighter weight... important for mobile apps) and to allow developers to more easily integrate with other frameworks and tools they've already invested in or may want to use in the future.
Yes designing the view layer of a 1.x and 2.x app are in most ways completely different but implying that you shouldn't or couldn't use SC 2 to create desktop-style applications or that SC 2 is only for creating web-style apps like Twitter and Stack Overflow is just not a correct assumption to make. Just about all of the apps we create at my company are desktop-style apps and we've been using SC 2 with builds of either jQuery UI or Twitter-Bootstrap for controls, theming, and layout support for months now. We've actually found that the apps we create in SC 2 are more feature rich with less development effort than with 1.x since the amount of already built controls that can easily integrate with SC 2 is massive (we haven't found a jQuery plugin that couldn't work with SC 2 yet).
My recommendation, just use SC 2. Don't even bother with 1.x.
Ok, seems Sproutcore 2.0 is now called Amber.js because of all the confusion:
http://yehudakatz.com/2011/12/08/announcing-amber-js
I am starting out a new project that involves the use of JSF 2.0.
From my initial reading, the Mojarra and Apache Implementation of the
project covers the basic components that you will need.
But I know that user's would seek gui with better presentation such as
panel tab, accordion, slider etc... Currently, there are other implementation that I am seeing, the Primefaces, RichFaces and Icefaces.
But I cant find a good article that discusses which among the three are the best.
I have used Spring MVC before but I use JqueryUI for those widget.
Now that I am into component based framework, I would like to use the best JSF Implementation.
I would like to know metrics such as performance/interoperability/ease of use/support.
Sorry if my question might be vague but I would like to hear comments before I select my JSF Vendor Implementation.
Thanks.
I happily use Primefaces as it is by far the most rich set of open source JSF2 controls out there, but they can be infuriatingly buggy at times. It is best to operate under the assumption that component X will not work correctly in a dialog without heavy tinkering.
I would avoid Primefaces if you operate in a development environment with strict UI design requirements as getting everything exactly the way you would like it to look and operate may not be a possibility.
Further I would avoid Primefaces if you are not comfortable with JSF, HTML, JQuery, JavaScript and CSS as you will need a good bit of JQuery trickery to work around the bugs that crop up.
But on that note, I haven't run into a problem yet that a couple lines of custom Javascript haven't fixed for me, and I have one of the most feature rich applications I have ever wrote in the shortest amount of time.
The speed of development is very fast in this area, and any article gets outdated quickly. I used Primefaces for a new project almost a year ago, because at that time it was the only one that was fully compatible with JSF 2 (both Icefacves and Richfaces have had JSF 2 compatible releases in the meantime).
Primefaces has a lot of powerful components that automatically use AJAX, and even more were added in version 3. Unfortunately this focus on new features led to a lot of bugs, but the developers said they would focus on bugfixing after release 3; I can't say anything about the current status since I left the project after 3 months.
There is one thing against Icefaces: a lot of components and functionality are only available in the Enterprise version, which is commercial, not free (but that might as well be a good thing since you get support etc. if your project can afford it).
Why not play with all three libs for a short time, build a simple project and see how you are getting along with either of them. My personal taste prefers Primefaces, but I haven't tried Richfaces since it turned JSF 2 ready.
I have successfully used JBoss RichFaces on a large online B2B store. RichFaces is a quite good framework for building webapps Web 2.0 style, and have easy to use tags that help you develop features faster.
I do not have any metrics regarding performance between RichFaces and IceFaces/Primefaces, but the ease of development should be approximately the same. All three frameworks have similar components, and they are all working towards more and more logic on the client via JavaScript.
At the current state of the JSF libraries, I am fairly sure that you will be happy with whichever framework your choose. IMO RichFaces and IceFaces are the two frameworks that have been around the longest, and i would put my bet on one of these two. IIRC both frameworks have key developers in the JSF design group as well.
As a general rule of thumb, these framework should work interoperably, but I wouldn't mix and match between them. The frameworks are really ment to be used on their own.
After reading RichFaces Vs PrimeFaces (for performance), I was tempted to use both in my web application to get the maximum benefit from both.
Do you think that is possible? What are the advantages and disadvantages?
Both are great component libraries. You can definitely combine them. But it is not true that it's 1+1=2 here. It's more 1*1=1. You should really investigate the both component libraries more closely. What exactly do you need from RichFaces which PrimeFaces doesn't offer? What exactly do you need from PrimeFaces which RichFaces doesn't offer? You need to find the right balance yourself. The one webapp isn't the other.
As to advantages/disadvantages, that's pretty subjective. Go play with them yourself. First each separately and then together. Own experience is the best experience. I myself had good experiences with PF 2.1. PF 2.2 had some serious issues in among others the datatable component. I didn't try PF 3.0 yet. I am currently working on a project which uses some RF 3.3 components and we are in a progress to upgrade it to RF 4.0. All I can say is that it's a pretty decent component library with good documentation. The full PF documentation isn't freely available anymore.
My answer is "no". It's better for you choose one of them. There are a lot of compatibility issues. For example, I've spent two days fixing a bug with rich:fileUpload. Finally, I've commented primefaces in my pom.xml (only a few components from primefaces were used) and all works fine then.
The answer is 'no' as of RF 4.5.7 and PF 5.2. There are jQuery conflicts which mean that some of the PF controls don't work. They've been talking together about sorting this out for five years but nothing appears to have been resolved.
I looked at both and ended up with PrimeFaces. The documentation for V 2.2 is now paid-for (I think about $9US) and gets you going very quickly.
Actually I did try this once when I was evaluating. I had PrimeFaces and RichFaces on the same page. It worked, but I was mostly looking at how the components were styled and how they looked. I did not try, for example, using AJAX requests from components from both packages on the same page. Since they are both based on the "native" JSF implementation, it should work but I wouldn't count on it.
Pick one of the other, and stick with it. Save yourself some grief.
Which is better for UI development. Are there any differences between the two UI toolkits?
I currently use Prototype/Scriptaculous, but I'm looking to migrate to jQuery. My main reason is that the developers and community behind Prototype/Scriptaculous seem to have disappeared; there haven't been any new releases in a long time, and several features are still a little buggy. The jQuery & jQuery UI teams seem to be very engaged, more open (see this, for example), and have a larger and more active community.
jQuery is better,
it has noConflict method that allows you to easy migrate, having both prototype/scriptaculous and jquery library included
jQuery is light weight especially in compare with scriptaculous
jQuery produce very simple code that easy to test/review
jQuery support CSS 2/3 selectors even browser doesn't
For ROR there is a plugin jRails
Regards,
Pavel
JQuery will be supported in Visual Studio 2010 making it a good choice for .NET developers.
Check this link - jQuery and Microsoft
See comparison of features: http://wiki.freaks-unidos.net/javascript-libraries
jQuery is very popular and well integrated in many frameworks, while the only framework in which scriptaculous is integrated is Ruby on Rails.
I just migrated all my client side scripting from Prototype / Scriptaculous to jQuery. The result is better performance (less coding + smaller footprint) and the application as a whole seems much richer. There is something really satisfying about jQuery development.
Prototype is a great library, but I got a little frustrated that, as DNS pointed out, the developers & community seem to have gone to sleep.
hmmm I find that scriptaculous is easier to use then JQ because it looks more like javascript and it has more core effects...I like that about it however yes it is a bit buggy and the comunity has started to move to JQuery...However I realy don't like JQ because it is like learning a new lanuage from scratch...it looks nothing like javascript
I've been using jQuery whenever I can. When using scriptaculous, I've found it hard to find suitable plugins that just work. Most of them have bugs or lack good documentation. For example, I went through 3 slideshows including writing my own in Scriptaculous before settling in and modifying one to suit my needs. With jQuery, I just had to go through 1 slideshow plugin because there are so many of them that one was bound to suit my needs.