Hi James, Any reason for the concerns regarding further jQuery dependencies? Is there something we need to be careful about or aware of?
On Tue, May 22, 2018 at 5:12 PM, James Yong <jamesy...@apache.org> wrote: > Hi All, > > My humble opinion is to switch to using JSON object to submit/retrieve > form/table data to the server. > With this change, it will be easier to introduce VUE later. > Also try not to introduce any further jQuery dependency. > > Regards, > James > > > On 2018/05/21 20:09:43, Gavin Mabie <kwikst...@gmail.com> wrote: >> On Mon, May 21, 2018 at 8:03 PM, Taher Alkhateeb <slidingfilame...@gmail.com >> > wrote: >> >> > 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. >> > >> >> That's true - and it really looks good. But the real good stuff that users >> expect from a modern UI needs the power provided by JS. >> So Bootstrap without JS is good until you need to expand or collapse a >> panel, or you need a modal (crucial in UI design), or a tab, >> accordion,popover etc. >> Then you'll need Bootstrap JS. These are called components (widgets) in the >> Bootstrap universe and they are really common across most JS frameworks. >> It is important to note that in Bootstrap JS components are limited (about >> 10 in total) and it excludes some which are critical for Ofbiz (see below). >> >> >> > >> > > 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? >> > >> >> We need a datepicker and we already have a robust one in Ofbiz (jQuery Ui >> Datepicker). It's used all over the place. >> Bootstrap doesn't come with a datepicker functionality - you can use >> something like bootstrap-datepicker from eternicode (a 3rd party). I guess >> that's the plugin. >> Of course this means more dependencies, more maintenance management. >> Besides, implementing i18N with bootstrap datepicker is a tricky >> proposition. Alternatively you could choose to use the jQuery UI >> Datepicker with bootstrap. But that means more libraries to manage. >> >> > >> > > 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? >> > >> I've alluded to the multiple library problem above at the hand of the date >> picking functionality. Another big gap is the fact that bootstrap doesn't >> have a "native" autocomplete/autosuggest functionality. >> You'll probably find one if you search around and you could probably write >> your own. This functionality already exists in jQuery UI. You could try to >> dress the jQury UI functionalities with bootstrap CSS to >> achieve a consistent look-and-feel. My experience is that this approach >> would soon bloat your CSS to unmanageable proportions. In summary - using >> jQuery UI along-side bootstrap or visa-versa is a no-no. >> There can be only ONE. >> >> >> >> > >> > > >> > > 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. >> > >> >> Actually, it is not a lot work at all. For your responsive design you >> decide on screen sizes, define breakpoints and write the CSS. see( >> https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries) >> . >> >> > >> > > 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) >> > >> >> If you list the "goodies", you'll see that its really not that impressive: >> Bootstrap component List (I count ten) >> >> - Modal >> - Dropdown >> - Scrollspy >> - Tab >> - Tooltip >> - Popover >> - Alert >> - Button >> - Collapse (Accordion) >> - Carousel >> >> jQuery UI goodies: >> >> - Accordion >> - Autocomplete >> - Button >> - Checkboxradio >> - Controlgroup >> - Datepicker >> - Dialog >> - Menu >> - Progressbar >> - Selectmenu >> - Slider >> - Spinner >> - Tabs >> - Tooltip >> >> Pound for pound I'll pick jQuery UI over bootstrap. >> >> Now throw in jQuery Mobile and you get even more functionality - including >> SPA. Note there is not conflict between jQuery UI and jQuery Mobile - the >> work together well. >> >> > >> > > >> > > 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 >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>> >> > >> > >> > >> >> > >>
