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!
Related
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.
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've got my plugins converted, or so I think, and registered in Cordova.plist. The method signatures are correct, according to this guide. Nothing has changed on the js side, yet they don't load and just fail silently. Cordova itself is working, onDeviceReady is firing, but my plugins just never get executed. Everything worked fine with 1.7...
I'd like some help to get started on figuring out where they are supposed to be loaded and/or called from js on the obj-c side. Where can I set a breakpoint in the Cordova source to see why it's not executing my plugin?
Where should I begin to look?
I just did exactly this migration. All I can say is that it worked for me if you follow the steps. You also need to follow the steps from the 1.9>2.0 migration.
Since Cordova 2.0, the framework had big changes.
Maybe is better you implements again using the 2.0 rules and, after, only override selector signature. Thus you learn how do plugin in new versions, updating your Cordova skills. :)
Single big change between 2.0 and 2.1 (for plugins)
Support a new plugin method signature (old signature is deprecated):
The new signature is:
- (void) myMethod:(CDVInvokedUrlCommand*)command;
The old (deprecated) signature is:
- (void) myMethod:(NSMutableArray*)arguments withDict:(NSMutableDictionary*)options;
I'm looking for nice and fast way for validating forms in GWT, that can display errors one by one, focusing on the offending field. I've found gwt-validator and gwt-validation, but their documentation lack of examples.
Thanks for help
Try the Hupa source code, If I remember well they use a GWT validation framework. Hupa is an open source project from Apache.
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.