Hi, I hope I got your attention :)
Else it's easy to start: https://www.google.fr/search?q=compare+Bootstrap+to+%22CSS+Grid+Layout%22&ie=UTF-8 Jacques Le 11/06/2018 à 16:49, Jacques Le Roux a écrit :
Hi, Sorry to be late, but after reading https://alistapart.com/article/cult-of-the-complex I wonder if we should not compare Bootstrap to "CSS Grid Layout" Depending the less possible on frameworks seems a good idea to me, and the "CSS Grid Layout" seems simple enough to be viable replacement. Who knows when Bootstrap will be out of date... Jacques Le 20/05/2018 à 21:20, Jacques Le Roux a écrit :That sounds realistic, pragmatic and to the point +1 Jacques Le 19/05/2018 à 20:31, Taher Alkhateeb a écrit :This was a thought provoking and interesting discussion and I learned new stuff from it, so thank you all for your valuable input. On further reflection and after thinking about your comments, I think Vue.js would be influenced in its design if we have a REST API in place, however, something like Bootstrap is not relevant because it is just a pure CSS / Javascript library to offer a grid system and some user interface widgets. It has no model to bind to nor does it require any back-end traffic (SPA stuff). So I recommend proceeding with Bootstrap, and we can delay something like Vue.js while we proceed in implementing the Web Services API. I'll start or find another thread for that discussion. WDYT? On Fri, May 18, 2018 at 10:43 AM, innate Genius <innate.pass...@gmail.com> wrote:Hi, +1 For Jacques, Scot & Rajesh’s View Point."I feel most of the modern UI frameworks consume JSON and if we have yet another adapter to the rich catalog of WebServices ( in addition to XML/RPC and SOAP) it shall benefit both UI developers and system integrators / framework users."This is been discussed in few other threads but this is a issue that is long due. And would love to see the community to finally address this. @Taher: Webservice to consume JSON would be the most beneficial and desired enhancement to the framework. Thx & Rgds, PratiekOn 17-May-2018, at 9:27 PM, Rajesh Mallah <mallah.raj...@gmail.com> wrote: Hi List , The default UI of OFBiz does look aged but I feel it does a great job of being productive. As discussed before also ERP being a serious backroom software and mostly operated by staff to whom all the bells and whistles of modern frameworks may not make any difference. But since adoption of OFBiz to enterprises is dependent on decision makers/ influencer who may not even know the nuances of UI and its relation to productivity it is important to look modern and shiny and which is the reason of this thread by Mr. Taher. Hence IMHO its good and required for OFBiz. At the same time we need to increase the comfort level of system integrators and people who use ofbiz as a framework. I feel most of the modern UI frameworks consume JSON and if we have yet another adapter to the rich catalog of WebServices ( in addition to XML/RPC and SOAP) it shall benefit both UI developers and system integrators / framework users. I also humbly feel while this modernization is done, the existing interface should not be done away with as people develop very strange and innovative comfort zones with software UIs which are difficult to anticipate by developers. my 2cents. regds mallah. On Wed, May 16, 2018 at 5:30 PM, Jacques Le Roux < jacques.le.r...@les7arts.com> wrote:Hi Scott, Taher, I think you are both right, and maybe because you are mostly working for 2 different markets or have different types of clients. Anyway, what I mean is: 1. Form widgets are not of much use when you have to deploy a new UI for an ecommerce or alike project (frontend). 2. They are very useful when you are working on a backend project (ie ERP part) where people don't care much about bells and whistle (even if that's less and less happening) but want a fast ROI ("time-to-market reasons" as said Taher) I don't know if Mathieu will get enough time to succeed on his project. But obviously if we had the possibility to generate RESTful web services from OFBiz services, with the export attribute like for SOAP and RMI, then Scott's idea would be fulfilled and that would help much, not only in the UI area of course. Now for widgets, the form part could maybe slowly replaced by using tools like Bootstrap and Vue.js. Or the new flavor in some years and that must be very seriously taken into account to not have to redo it again, in few years... Jacques Le 15/05/2018 à 12:18, Taher Alkhateeb a écrit :Ahhh, I understand clearly now. Thank you! So more or less, the heart of your message as I understand it is that we should decouple the rendering of the user interface from data fetching and manipulation. This makes perfect sense and is a good strategy. A bit contrary to your experience though, most of our work relies heavily on the widget system for time-to-market reasons. It has been immensely beneficial to get something out the door quickly. However, of course the system falls short when it comes to heavy customizations or the need to integrate with other systems. So I would suggest that perhaps your comment in this thread that "having prebuilt APIs would have reduced the workload" is applicable in case of custom work. Otherwise, perhaps the faster route is through the widget system. Therefore I think it is reasonable to apply both strategies: 1) use good modern UI tools 2) build powerful flexible web APIs. But for standard screens, I see no reason to use web service calls instead of <action>...</action> tags to do quick and obvious things unless perhaps you make the web API call part of the widget system itself (also a good idea!) Anyway, you're making me think more seriously of pushing forward the implementation of web services, but I think introducing these frameworks is going to be beneficial either way. On Tue, May 15, 2018 at 12:44 PM, Scott Gray <scott.g...@hotwaxsystems.com> wrote:Hi Taher, I'm simply saying that if we were to provide a complete suite web APIs to access the full functionality of ofbiz, then the project's choice of UI technology no longer matters so much in the grand scheme of things. No one would be forced to live by our choice of UI frameworks because they could build anything they liked using the APIs without ever touching the server-side code. Right now our data gathering logic is tightly coupled to our UI, inaccessible to other servers and apps, the vast majority of our services are built to be run internally by ofbiz. Without heavy modification of the server side code, I can't build a custom SPA, I can't send orders to ofbiz from another application, I can't really do anything without interacting with the OFBiz UI. The majority of the client projects I've worked on always involve a completely custom UI and with web APIs I could pick up any flavor of the month UI framework to build it with. All I'm trying to add to this conversation is that it would be nice if any UI overhaul started with making APIs available that could be used both by our framework of choice and be externally accessible to anyone else's framework of choice. Regards Scott On Tue, 15 May 2018, 20:27 Taher Alkhateeb, <slidingfilame...@gmail.com> wrote: 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.comwrote: 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 somethingdifferent.I'm beginning to lose count of the number of custom APIs I've writtenoverthe years to support custom UIs. I think the bigger win would be to start providing APIs and rewritingour existing screens to use them. From there we could start looking at newUIframeworks. 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 servicescustomprojects would be able to build out new user interfaces in a lot lesstimeand 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 UIcustomization and having prebuilt APIs would have reduced theworkloadmuchmore than having a shinier UI that still needs to be completelyrewritten,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 abasic map for in/out parameters when the rest of the world is usingthelikes 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 discussionsand 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. RegardsScott 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,butlooks too classic, too rigid, too 2000s really :) We had manydiscussion 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 sureIhave the magic answer, but it seems to me like part of the problemissimply .. TOO BIGSo 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. SoIam 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 anexcellentframework for creating Single Page Applications (SPAs) to givedynamicbehavior to our pages and create ajax-heavy pages- We slowly migrate our old CSS to bootstrap constructs. We canbeginfor example by replacing our menus, then tables, then headers, thenbuttons etc .. - We slowly introduce dynamic screens using controller logic inVue.js- We slowly update our macro library to migrate to the abovementionedlibraries and widgets- We do all of this live in Trunk, without branching. This meansthatfor some period of time, there will be transitional code (a littlebitof 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 implementationintrunk. I think this issue is many years over due. Our interfacelooksoooooooooooooold 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
