did you post any articles about the design of your meta approach - I'm very interested in reading a bit about it to see if I can learn from it ? I've seen similar approaches where an XML representation was used (looking a lot like XUL syntax), but I had to help in improving the performance and factoring out GXT widgets with custom made ones.
On Mon, Nov 23, 2015 at 11:32 AM, CodeLess <[email protected]> wrote: > 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 <[email protected]> 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 < >> [email protected]> 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 [email protected] >>> . >>> 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 [email protected]. >> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFHJR8Wpeq1HqUG8OsGfxgcLqnnXwtgAmNh-ig5bm%2BwYkv4q1Q%40mail.gmail.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAFHJR8Wpeq1HqUG8OsGfxgcLqnnXwtgAmNh-ig5bm%2BwYkv4q1Q%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CABrJHW1P12ubWYPWKAVoupmycS26aO%3DiOj3DCssOvu-ibHKuRw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
