Disclaimer: I have zero experience with Telerik products, but see Kendo UI as something that's definitely interesting to work with. I have worked with Angular2 and other component-based frameworks before.
I recently received an existing code base that makes use of Kendo UI for jQuery (specifically the 2016 Q1 SP1 version), and got tasked with migrating to a component-based design. Search results gave me Kendo UI for Angular2, which seems like an excellent choice. An interesting thing to note for me, is that it's still a release candidate -- it has been released less than a month ago, as of time of writing, but according to the text on the web page it's production-ready.
At first glance they seem partially compatible (as in same components, and similar APIs), and I have some ideas on how to migrate, but would appreciate input of others (that are more experienced with the previous and current Kendo UI types) on this matter.
Some ideas I have:
Run both versions simultaneously, and migrate entire pages. This way they won't interfere with each other, and anything encountered that can be turned into a component or service can be converted.
Put the entire thing into a Angular2 application, and use both Kendo UI for jQuery and Kendo UI for Angular2 on the same pages until everything is migrated. I'm uncertain whether there will be any conflicts here, but I think this is possible with proper encapsulation.
I'm definitely interested in other views regarding this, as more experienced people have probably already solved this issue.
Related
I have a question, i am recently investigating asp.net boilerplate as I would like to implement it in the application I am currently developing, my application is mvc5 and I am using kendo widgets throughout the application, I manage to migrate to asp.net core boilerplate template and successfully included all the libraries and references, however i came to realize that ABP formats json responses that kendo widgets no longer accepts. Thinking about this makes it complicated and maybe the combination is not that easy.
Did anyone ever encounter similar situation and if so how did you go about it, thx.
I'm not a developer myself, but my company develops and supports a large web application for insurance brokers.
Since way back we've been using ExtJS 3.x and as we went further the harder it got to migrate from 3.x to 4 and now to ExtJS 5. Due to the structure of the application and demands from out customers we cannot afford to freeze development and focus on refactoring our interfaces.
But we still want to use the benefits and functionality of the ExtJS 5.
My question is - is it possible to use both versions of the framework in the same application? For example, developing new grids and modules with ExtJS 5 and gradually migrating existing forms.
Did anybody have this sort of experience? Or is it plain nonsense and will never work?
Thanks to everyone in advance.
I find this question very interesting. I had a similar challenge, when I had to migrate our in house app from legacy Jxlib to ExtJs4. Putting my experience together with #Lolo's answer here is what I can advice:
Build on a new solid foundation. You could be tempted to keep your app in ExtJs 3.0 and start grafting new ExtJs 5.0 components on it. If you really want to take advantage of all the new features of ExtJs 5.0, you should start off with a clean, simple MVC app in ExtJs 5.0, that could be as little as the main window and the main menu. You could then bind all existing menu entries to the existing ExtJs 3.0 code. This will allow you to start with a really clean thing, keeping all the old functionality, without rewriting the code, and allow you to develop all new features with clean ExtJs 5.0 code that follows current best practice recommendations.
You will face two stumbling blocks:
You have to separate the namespaces in Javascript and CSS. Here also, I would advice to change the prefixes for ExtJs 3.0, and not for Ext 5.0 (I ignore if ExtJs 5.0 includes a sandbox file). The reason behind is that all your new ExtJs 5.0 code will be standard compatible, while only the old legacy code becomes incompatible (what it is anyway already). This will represent some code refactoring though, because you would need to replace all Ext. occurrencies in all your code with Ext3. or similar (the same applies to CSS, but will be much less work). I hope for you, that ExtJs 3.0 has a sandbox version, because I think refactoring their code would be a lot of work (but not impossible).
A major feature of ExtJs 5.0 (as already for version 4.x) is the automatic building and compiling of an MVC application using Sencha Cmd. This didn't exist yet for ExtJs 3.0. I think it is crucial that you start straight away using this tool. I will allow you to really take advantage of all the enhancements (declarative programming instead of imperative, advanced MVC and MVVM features). It will radically change your coding style.
To get this work, you compile in a first step you old code in one Javascript file. Sencha Cmd must not recognize this as an Ext app. Then you simply add requires: 'Oldapp' in Application.js and ExtJs will include a file called Oldapp.js. That file should define a class Oldapp and include all the rest of your application code:
Ext.define('Oldapp', {
// Just what ever you need
})
// All the rest of the code of you old app
Then layout all the folders and files of your new code according to the MVC or MVVM specification (whatever you prefer) in the Ext doc, and Sencha Cmd will build you the whole app correctly.
I think this all allows you to take advantage of all the new features immediately, building on a clean, standard foundation with only minor code refactoring. It sounds like eat the cake and have it too, but it is possible.
But this will take a huge mental step: You must learn ExtJs 5.0 like something new and try to forget all you know already about ExtJs. You won't use Ext.ready anymore, Ext.Loader will handle this under the hood. Nor will you instantiate Ext objects from declarations (ban panel = Ext.create({xtype: 'panel', ... stuff), stick to Ext.define('Myapp.view.Mypanel' .... There are many other points where everything changed since Ext 3.0 ...
This last point is in my opinion the biggest stumbling block, much more important than the two technical points explained before: It is difficult, but crucial to reeducate yourself.
You can use sandbox version of Ext Js 5.0 and "normal" 3.0 (I don't remember if 3.0 is also available as sandbox).
Then you can change prefix for all 5.0 classes and css rules. By default it is Ext4 (not Ext5) for JS, and x4- for CSS.
To use sandbox include ext-all-sandbox.js file from build directory.
It won't work. The javascript files will clash with each other.
I was looking at the playEditor app to learn and the app loads up but the validator does not work after the first time.Do you have an updated version?
If you mean my little (intentionally unpolished) example from this post: GWT 2.1 Editors framework - no, I don't have an updated version.
The problem was, that once the validation passes, it stops working. I believe, the way the Editor framework is/was meant to be used (at least with GWT 2.1) is that you close the editor Dialog/Panel/..., as soon as the validation is correct. When you want to use it again after that, you'd have to create a new Dialog (where validation works once again).
This is actually one of the main reasons, why I'm currently not using the framework. I often prefer re-usable forms over closing dialogs, so it didn't seem ideal for me.
Note that I haven't made a new attempt for GWT 2.2 - and maybe I didn't try hard enough even for GWT 2.1 - so I would be glad, if someone finds a solution!
basically, my question is pretty much similar and has been asked numerous times. Which WYSIWYG editor is better now that Telerik has released their MVC editor, would it be wise to purchase the entire suite instead?
Selections:
TinyMCE
CKEditor
Telerik MVC Editor
Disclaimer: As part of the Telerik MVC team (and one of the editor developers), my opinion is quite biased, yet I can shed some light on the differences between the editors.
All of them are open source
Despite Todd's answer, the Telerik MVC editor is open-source, under GPLv2 license (with a commercial license available). Our support is well known, so I guess this is where we stand out (though it is paid). On the other hand, both TinyMCE and CKEditor have huge communities, which may help quickly, too.
Different feature set
This has been the first release of the Telerik MVC editor, while CK and TinyMCE have been around the block for a very long time. We have mixed feelings about this -- while we are missing out on quite a few tools/features, we have invested a lot of time in polishing the existing ones (converting list items to headings, pasting from MS Word). Our bet is on cleaner, more robust code (4k LoC vs 14k LoC in TinyMCE without plug-ins).
It depends on your requirements
After all, with the Telerik suite, you get... well... a suite of components with common code and themes. So if you need the dedicated support and the other components and the limited feature set does not make a difference, Telerik would be a nice choice. If you need a full-scale editor and want to bet on more feature-complete products, TinyMCE and CKEditor are the wiser choice.
I hope this helps and does not contain much happy talk.
Some Background:
While there are some very good third-party components for ASP.NET I tend to stay away from them for the open source alternative. The reason goes back to an issue I has with a chart component a few years ago. It had a bug that the company would not fix in the current version and instead wanted us to purchase an upgrade while not guaranteeing that would fix the problem.
They did offer a demo that we could not use in production (which was the only place we were getting the problem) so the problem continued until the component was replaced.
My Answer
From My experience I would recommend going with the open source alternative. I have used CKEditor and TinyMCE with success in PHP projects. CKEditor can be styled nicely and TinyMCE has tons of documentation from the millions of people who use it daily.
The greatest benefit to open source is being able to change the code to meet your needs or fix a problem specific to your environment.
My last ASP.NET MVC app required all components to be open source for the same reason as mentioned above with the end result being more stable than the previous that included some purchased components.
Hope this helps.
Wordpress uses TinyMCE, so I am very familiar with using it (though getting it to look like wordpress is a little bit of an undertaking).
I have successfully implemented TinyMCE into 2 of my Asp.Net MVC websites with very little effort.
As with any, there is a ramp up time, but TinyMCE has never disappointed me.
We are using CKEditor_3.x in our MVC 2 app.
It works great.
On save:
Just 1 important note, in your CKEditor config file be sure to set:
config.htmlEncodeOutput = true;
Or you will get an error message.
Later on display
You will need to decode is like:
<%=HttpUtility.HtmlDecode(Html.TextAreaFor(model => model.Description).ToHtmlString())%>
Good luck!
I am currently using the JBoss RichFaces JSF component library for the project I am working on. It works quite well in general, especially the AJAX support provided by ajax4jsf (A4J), but I find the usually very inflexible table-markup used for almost every component and all this "skin" stuff of RichFaces quite annoying. It would be nice if there were some components which just provided the functionality and only minimal markup/style. Originally I had planned to use ICEfaces, but that didn't work too well either and also brings a lot of predefined styles with it, so for now RichFaces seems to be the best option.
Now I thought it would be nice to develop a clean tag library which provides some useful components found in RichFaces, ICEfaces or Tomahawk (not all of course!), which don't use any predefined style and generate markup which can be styled easily with CSS.
I wanted to use the ajax4jsf library for AJAX support, because I think it works quite nicely, and integrates seamlessly into standard JSF with facelets. But it seems that since it has moved over to JBoss, it isn't available as a standalone library anymore. You can only download the whole RichFaces package, which I don't want.
Is the ajax4jsf (A4J) project dead? If it is, what alternatives are there?
You can find many alternatives here:
JSF AJAX Component Library Feature Matrix
If you read the ajax4jsf forum you'll see that it's been merged with Richfaces.
You don't have to use the Richfaces components on your page, so do you have an issue with having the JARs in your project?
I agree that many JSF components (not just Richfaces) are based on tables (eg. h:selectManyCheckbox). Don't forget that it's easy to write a new renderer for many of these. I've done this for the h:selectManyCheckbox so that the checkboxes are rendered inside divs instead of a table. I would think that you should be able to do the same for Richfaces components...but if that's the case, then why use them?
You may find it easier/nicer using jQuery UI elements and tie them back to your Beans with a4j:jsFunction (or similar).
Just a comment. I started using icefaces. I'm a web designer also and im very particular on look and feel of the icefaces components in relation to my web application. I was highly frustrated at the time it took me to override the look and feel of icefaces components using css. The components had a lot of nested table markup that annoyed me.
When i moved to richfaces. I discovered it was alot easier to override the look n feel because richfaces have an integrated system of overriding the look n feel in css. The css given to the components had similar and sensible class names that made it easier to predict and override.
If you are feeling adventurous, take a look at JSF 2. It features a shift in view technologies from JSP to Facelets and built in AJAX support. David Geary has been running a series of JSF 2 fu articles on developerWorks (though you'll have to wait for part 3 for the AJAX stuff). Ed Burns and Jim Driscoll have been demoing various features during the development of the new API, so you might want to check out their blogs too.