Hi Scott, Again thank you for the input, intriguing. I'm not sure if I fully understand though. Are you saying we can introduce web services that can sort of do away with the widget system to code directly in html and weaving in web service calls? How does that make coding faster? What is inefficient in the widget system? What kind of architecture should we have in place? What is the routing workflow that you're suggesting?
I would appreciate a bit more elaboration to get a better understanding of your point of view since this seems to be a critical architectural decision. On Mon, May 14, 2018, 9:39 PM Scott Gray <scott.g...@hotwaxsystems.com> wrote: > On Mon, 14 May 2018, 20:38 Taher Alkhateeb, <slidingfilame...@gmail.com> > wrote: > > > Hello Scott, thank you for your thoughts, inline ... > > > > On Mon, May 14, 2018 at 10:45 AM, Scott Gray > > <scott.g...@hotwaxsystems.com> wrote: > > > I think no matter what we use someone will always want something > > different. > > > I'm beginning to lose count of the number of custom APIs I've written > > over > > > the years to support custom UIs. > > > > > > I think the bigger win would be to start providing APIs and rewriting > our > > > existing screens to use them. From there we could start looking at new > UI > > > frameworks. > > > > Do you mean by APIs rewriting our XSD files and model objects? Why > > rewrite? Why not just enhance them for new / missing functionality? > > What are the flaws you'd like to redesign? > > > > No, I'm talking about web services. With well designed web services custom > projects would be able to build out new user interfaces in a lot less time > and we'd be able to poc new interfaces for the community project without > even touching the existing codebase. > > > > > > > > > > Most of the projects I've worked on have needed huge amounts of UI > > > customization and having prebuilt APIs would have reduced the workload > > much > > > more than having a shinier UI that still needs to be completely > > rewritten, > > > although I'll admit the latter would probably help the sales process. > > > > The "shiny" part is a plus, but not the core of my suggestion. The > > reasons I suggested these libraries are: > > - bootstrap: the grid system, this is the cake for me. You have a > > powerful responsive grid system for better layouts. The buttons, > > tables and other bling bling are icing on the cake. > > - Vue: The core of this technology is to allow binding of your context > > model to the DOM so that you don't write oodles of JavaScript and > > Jquery to create dynamic behavior. It's really old school in 2018 to > > keep jumping between many pages to get something done. > > > > > > > > Does it not worry anyone else that our service engine still only > defines > > a > > > basic map for in/out parameters when the rest of the world is using the > > > likes of swagger and restful APIs? > > > > Of course it worries me, and if you start an initiative I will be the > > first to jump in and volunteer. In fact it's on my todo list, and I > > was looking at multiple options lately and I'm very attracted to > > GraphQL for example because of the reduced visits to the backend. > > However, I don't see this as being related to my proposal here, I'm > > just setting my own priorities of what to work on next. What's wrong > > with starting _both_ initiatives for that matter? > > > > Nothing is wrong with both, but as you pointed out many discussions and > efforts have begun and then floundered. I'm simply offering some thoughts > on where I see the most potential benefit from a large scale effort. > > > > > > > > > > Regards > > > Scott > > > > > > On Sun, 13 May 2018, 06:03 Taher Alkhateeb, < > slidingfilame...@gmail.com> > > > wrote: > > > > > >> Hello Everyone, > > >> > > >> Recently, we at Pythys had some interactions with clients, and the > > >> user interface proved to be a sour point. It is functioning well, but > > >> looks too classic, too rigid, too 2000s really :) We had many > > >> discussion and attempts in the past like [1] [2] [3] [4] [5] [6] [7] > > >> [8] [9] [10] just to name a few all of which seemed not to follow > > >> through. > > >> > > >> So what is the problem? Why is this hard to get right? I'm not sure I > > >> have the magic answer, but it seems to me like part of the problem is > > >> simply .. TOO BIG > > >> > > >> So I was thinking about a possible solution, and after some initial > > >> research, I think maybe the solution (like everything else) needs to > > >> be slow, incremental and evolutionary rather than revolutionary. So I > > >> am suggesting the following ideas to try and move forward: > > >> > > >> - We include the assets for Bootstrap in the common theme. Bootstrap > > >> will give us the Grid system which allows for a responsive website > > >> that works on all devices, it will also give us beautiful widgets to > > >> work with. > > >> - We include Vue.js assets in the common theme. Vue.js is an excellent > > >> framework for creating Single Page Applications (SPAs) to give dynamic > > >> behavior to our pages and create ajax-heavy pages > > >> - We slowly migrate our old CSS to bootstrap constructs. We can begin > > >> for example by replacing our menus, then tables, then headers, then > > >> buttons etc .. > > >> - We slowly introduce dynamic screens using controller logic in Vue.js > > >> - We slowly update our macro library to migrate to the above mentioned > > >> libraries and widgets > > >> - We do all of this live in Trunk, without branching. This means that > > >> for some period of time, there will be transitional code (a little bit > > >> of bootstrap and a little bit of our current code) > > >> > > >> We can start with an initial proof of concept skeleton, and if that > > >> gets consensus, then we can move forward with a full implementation in > > >> trunk. I think this issue is many years over due. Our interface looks > > >> oooooooooooooold and really needs a face lift. > > >> > > >> What do you think? Ideas? Suggestions? > > >> > > >> [1] https://s.apache.org/rf94 > > >> [2] https://s.apache.org/g5zr > > >> [3] https://s.apache.org/XpBO > > >> [4] https://s.apache.org/YIL1 > > >> [5] https://s.apache.org/836D > > >> [6] https://s.apache.org/DhyB > > >> [7] https://s.apache.org/Lv9E > > >> [8] https://s.apache.org/zKIo > > >> [9] https://s.apache.org/D6jx > > >> [10] https://issues.apache.org/jira/browse/OFBIZ-5840 > > >> > > >
