Hello Gavin, Your timing is pretty good actually and we can gain from your experience. Comments and questions inline ...
On Mon, May 21, 2018 at 1:03 PM, Gavin Mabie <kwikst...@gmail.com> wrote: > 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. Perhaps this is a point in favor of Bootstrap. The less JavaScript the less messy things are. > 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! What would we need? And why would we need it? Why _must_ it be a plugin? > 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. Can you elaborate please? Do you have an example of a problem that we will would face should we adopt Bootstrap? > > If your only criteria for Bootstrap is grid-layout capabilities, consider > that grid is quite easily attainable with pure CSS through the @media That's a lot of work! That's like saying let's write a desktop app in Assembly. I mean you can do it, but why! The "@media" is just a building block. > 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. Well, naturally, if you implement bootstrap then you get all the goodies with it, not just the grid, otherwise you can choose a simple Grid library (many out there) > > 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 >> >>>>>>>>>> >> >>>>>>>>>> >> >>> >> > >>
