Good points and I agree with almost all you said ;-) We did not notice any performance degradation by using meta approach comparing to manual or UIBinder way, but that is something that we will try to demonstrate in the following weeks. Well, we do not have to support IE6/IE7 so this would be a good test, thanks for mentioning this! I will let you know when we create such a demo so you can take a look if you like.
Let's see what will happen with Elemental2 in the following couple of weeks, I think Julien is working on it and if I remember well he said somewhere that he will have something in the following month or two. Anyway, I hope your fears will not come true. Cheers. On Mon, Nov 23, 2015 at 9:58 AM, David <david.no...@gmail.com> wrote: > Good points and in most cases we are covered: > - Using a Command Processor over GWT-RPC, but I will move it to a REST > implementation. > - GUI is split up in MVP and the important code is not depending on any > GWT widgets or anything else. > > We are using UiBinder in our current application, but switching to > something else is not something that I am afraid off. When I use UiBinder I > try to avoid using widgets as much as possible. So if this needs to move to > Angular or some other HTML based template mechanism, I don't expect a lot > of difficulties since it is already close to pure HTML anyway. > > Abstracting behind a meta description language for the UI that part we did > not do. One of the main reasons is that you lose a lot of the performance > benefits that GWT is offering. This optimisations mattered because we > needed to support older browser (IE6/IE7). > > One important component we have does this, but that one is very much tuned > for one specific task (editing financial messages defined through > XSchema's). It can not handle writing entire GUI's with rich tables, tabs, > splitter panels etc. But has some domain specific optimisations that are > not that easy to do when you need to write a complete abstraction of the UI. > > We alse have dependencies on the CellTables because they offer quite good > performance and we enhanced the capabilities of those cell tables to add > missing functionality. But the CellTables are hidden behind a factory and > the interactions happens against interfaces, so the client code will not > too much impacted either. > > What I am mostly afraid of with losing Element or Widget classes is that > every widget vendor will start declaring their own base classes and > interfaces for common functionality. This will make it hard to mix > components from different vendors. > > Web Components are interesting, but as usual it is too soon to go down > that trail. Chrome is not the most used browser in banking and enterprise > environments and web components on IE11 is still a mess. I tried polymer > but it is way too slow to scale to large GUI's at this point. > > > On Sun, Nov 22, 2015 at 12:19 PM, CodeLess Solutions < > codelessoluti...@gmail.com> wrote: > >> This is very good question and actually one of the biggest problem not >> only in this particular situation but also in general software development. >> >> >> Imagine you decide to build something large like ERP or Banking >> Information system for an example (with hundreds even thousands of tables >> and forms) You didn’t even finish it because of its complexity and one day >> you find out that Swing or Angular1 or Flex or “something else” come to its >> end of living and you are not able to switch easily to anything else? >> >> >> I happened to me once long time ago with some other widget library, so I >> am talking from the personal experience :-( >> >> >> I will try to explain our strategy how to solve this problem: >> >> >> We are using GWT and we are really enjoying to use it but: >> >> >> We are not using WindowBuilder (it’s not supported anymore since version >> GWT 2.6 and it’s also useless when you are creating large application >> because it’s to slow), not using UIBinder because it generates to much >> boilerplate that we do not need at all, not using Request Factory that >> generates who knows what, not using MVP… nothing that is too specific or >> bound too much for the platform. The only thing that we use and is specific >> is Code Splitting but it’s totally hidden from developers and done >> automatically for each controller. We are not using any external library to >> do this. It’s simple to implement and it would be probably easy to replace >> it with something else tomorrow. Everything is done with a single >> annotation. >> >> >> GWT-RPC may also disappear? We are using JPA classes (with Hibernate) but >> we don’t use DTOs because there is simply no need to pack and unpack >> everything. We do not write code for every document we need to save >> (create, update, delete), there is only ONE class that is doing the job via >> GWT-RPC. Exceptions are rare (less than 10%) that you have to do something >> special while persisting the document and you are able to do that as a >> custom business logic that executes in the same transaction. Current >> implementation is GWT-RPC based, but when we decide to change this, it can >> be done in a single day (probably in couple of hours) because its’ ONE >> class and not hundreds/thousands of classes that we have to change. We are >> not afraid of changes when someone decide to stop supporting GWT-RPC or >> it’s suddenly surprisingly proven that it is prone to vulnerabilities. We >> have less than 10 services to change and note that we are dealing with >650 >> forms/JPA classes in this moment. All custom actions go via ONE custom >> action service, we do not create 100 services because it is used in 100 >> controllers. >> >> >> About UI: We are using something that I call “meta description approach” >> for UI. Describe you fields, views and forms on technology agnostic way >> including events. Your views should only describe the view, you should >> never see any TextBox or any other concrete widget in your code. Use >> interfaces in your controller and never use concrete GWT/GXT/GwtBootstrap >> widget. Current implementation is GXT 3 based but there is also ongoing >> GwtBootstrap 3 version that works equally well but it looks (much) better >> but that is personal opinion. You can even mix this libraries. In >> GwtBootstrap version you can create fields as widgets or you can use >> Bootstrap HTML and CSS, even jQuery JavaScript that sometimes comes with >> it, from any source and bind existing tag like this one: >> >> >> <input class="form-control" type="text" placeholder="User name" id="name"> >> >> >> to your meta field named “name”. The beauty of this is that you can do it >> even without any compile, it will simply work instantly. You do not need to >> add any annotations or even write any controller code if there is no need >> for it. We have a youtube movie that proves this: >> https://www.youtube.com/watch?v=ROZ5Oa6DoUg >> >> >> No widgets anymore? Ok, let’s rework engine not to use widgets and >> implement new version of your metafields that is using Elemental2, >> JsInetrop2 or whatever it is called today/tomorrow. You do this on engine >> level and nothing changes in your views, controllers or model. You like >> GXT, and they decide to do this? Great, make your new implementation in the >> meta platform engine to use GXT5(?) and you are ready to go. You like >> Vaadin webcomponent gwtpolymer ? GwtMaterial ? … Add this to the >> engine/platform. You do not need to change your controller, model, or view >> code because of this. Don’t want to use Bootstrap templates any more, and >> you want to use some other templates instead? When all mappings, field >> properties and events are in meta descriptions it would be much easier to >> replace it comparing to dealing with concrete widgets. When you think >> “meta way”, you are not bound to concrete technology and that is the way we >> decide to go. >> >> I am not concerned about the future, I am prepared for the changes this >> time. >> >> >> Hope this helps. >> >> >> >> >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "GWT Contributors" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/google-web-toolkit-contributors/72e2237e-12b7-4e3f-8537-7536212089a9%40googlegroups.com >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/72e2237e-12b7-4e3f-8537-7536212089a9%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABrJHW0f1Zr9toH9ZGpmU7FiAYuHZM89yn_z1wWqB5j4%3D62%3DBg%40mail.gmail.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABrJHW0f1Zr9toH9ZGpmU7FiAYuHZM89yn_z1wWqB5j4%3D62%3DBg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFHJR8Wpeq1HqUG8OsGfxgcLqnnXwtgAmNh-ig5bm%2BwYkv4q1Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
