Hi guys I've been away for a while so my input maybe a bit behind the curve. Having said that, I have some useful Bootstrap-with-Ofbiz experience under the belt which may be relevant to this discussion: 1. Bootstrap is mainly CSS. It's pretty, but with limited JavaScript functionality. In-fact JS in Bootstrap is entirely optional because it doesn't pretend to be a JS Framework. 2. You will be required to mine 3rd party plugins/widgets to cover functionalities absent from Bootstrap - and those may not be well-maintained. Risky! 3. Autocomplete and Date Picking functions specifically - frequently used in Ofbiz, but not "native" in Bootstrap. This sometimes leads to all manner of conflicts and complicates manageability.
If your only criteria for Bootstrap is grid-layout capabilities, consider that grid is quite easily attainable with pure CSS through the @media selector used with break points. Secondly, "Grid" will become a standard in CSS (see https://www.w3.org/TR/css-grid-2/). The investment in a "framework" for "Grid" only - that's an overkill. My 2 Cents: 1. How about jQuery Mobile(JQM)? It's part of the jQuery family. We already use jQuery as JavaScript framework, to use JQM would be a logical extension. 2. JQM covers SPA - an important functionality identified by some in this thread. 3. JQM fits in nicely with jQuery UI - something which we are already using in Ofbiz with autocomplete/suggest, date picking and modals. Final thoughts - Cleaner separation between JS and Freemarker using HTML elements: 1. We are not using new outlining and sectioning elements like <section>, <article>, <nav>, <header>, <footer>, or <aside> in our templates. They hold obvious advantages. 2. Global data-* attributes. We're not using this at all. It can help us to reduce JS in Freemarker templates. Regards Gavin On Mon, May 21, 2018 at 5:17 AM, Shi Jinghai <huaru...@hotmail.com> wrote: > +1. > > Excellent. > > -----邮件原件----- > 发件人: Taher Alkhateeb [mailto:slidingfilame...@gmail.com] > 发送时间: 2018年5月20日 2:31 > 收件人: OFBIZ Development Mailing List > 主题: Re: [Discussion] Introduction of Bootstrap and Vue.js > > 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, > > > > Pratiek > > > >> On 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.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 > >>>>>>>>>> > >>>>>>>>>> > >>> > > >
