[Discussion] Introduction of Bootstrap and Vue.js
Locked
12
12
 
|
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 <[hidden email]> 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 <[hidden email]> wrote: > >> +1. >> >> Excellent. >> >> -----邮件原件----- >> 发件人: Taher Alkhateeb [mailto:[hidden email]] >> 发送时间: 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 >> <[hidden email]> 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 <[hidden email]> >> 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 < >> >> [hidden email]> 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 >> >>>> <[hidden email]> 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, < >> [hidden email]> >> >>>>> 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 < >> [hidden email]> >> >>>>>> wrote: >> >>>>>> >> >>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, < >> [hidden email] >> >>>>>>>> >> >>>>>>> wrote: >> >>>>>>> >> >>>>>>> Hello Scott, thank you for your thoughts, inline ... >> >>>>>>>> >> >>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray >> >>>>>>>> <[hidden email]> 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, < >> >>>>>>>>> >> >>>>>>>> [hidden email]> >> >>>>>>> >> >>>>>>>> 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 >> >>>>>>>>>> >> >>>>>>>>>> >> >>> >> > >> |
Re: [Discussion] Introduction of Bootstrap and Vue.js
|
On Mon, May 21, 2018 at 8:03 PM, Taher Alkhateeb <[hidden email]
> 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 <[hidden email]> 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 <[hidden email]> > wrote: > > > >> +1. > >> > >> Excellent. > >> > >> -----邮件原件----- > >> 发件人: Taher Alkhateeb [mailto:[hidden email]] > >> 发送时间: 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 > >> <[hidden email]> 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 <[hidden email]> > >> 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 < > >> >> [hidden email]> 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 > >> >>>> <[hidden email]> 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, < > >> [hidden email]> > >> >>>>> 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 < > >> [hidden email]> > >> >>>>>> wrote: > >> >>>>>> > >> >>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, < > >> [hidden email] > >> >>>>>>>> > >> >>>>>>> wrote: > >> >>>>>>> > >> >>>>>>> Hello Scott, thank you for your thoughts, inline ... > >> >>>>>>>> > >> >>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray > >> >>>>>>>> <[hidden email]> 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, < > >> >>>>>>>>> > >> >>>>>>>> [hidden email]> > >> >>>>>>> > >> >>>>>>>> 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 > >> >>>>>>>>>> > >> >>>>>>>>>> > >> >>> > >> > > >> > |
Re: [Discussion] Introduction of Bootstrap and Vue.js
|
|
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 <[hidden email]> wrote: > On Mon, May 21, 2018 at 8:03 PM, Taher Alkhateeb <[hidden email] > > 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 <[hidden email]> 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 <[hidden email]> > > wrote: > > > > > >> +1. > > >> > > >> Excellent. > > >> > > >> -----邮件原件----- > > >> 发件人: Taher Alkhateeb [mailto:[hidden email]] > > >> 发送时间: 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 > > >> <[hidden email]> 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 <[hidden email]> > > >> 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 < > > >> >> [hidden email]> 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 > > >> >>>> <[hidden email]> 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, < > > >> [hidden email]> > > >> >>>>> 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 < > > >> [hidden email]> > > >> >>>>>> wrote: > > >> >>>>>> > > >> >>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, < > > >> [hidden email] > > >> >>>>>>>> > > >> >>>>>>> wrote: > > >> >>>>>>> > > >> >>>>>>> Hello Scott, thank you for your thoughts, inline ... > > >> >>>>>>>> > > >> >>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray > > >> >>>>>>>> <[hidden email]> 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, < > > >> >>>>>>>>> > > >> >>>>>>>> [hidden email]> > > >> >>>>>>> > > >> >>>>>>>> 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 > > >> >>>>>>>>>> > > >> >>>>>>>>>> > > >> >>> > > >> > > > >> > > > |
|
|
In reply to this post by Gavin Mabie-2
Very interesting perspective Gavin, thank you for sharing your experiences.
Frankly your jQuery suggestion makes sense. We keep what we already use. It just makes sense! Yeah bootstrap is bigger and has more support, but jQuery is already there in the code base ready to be improved. On the other hand, I don't like at all the idea of building a grid with my own hands using @media. I'd much rather have something constructed and battle tested. But this needs some further thinking. So how about this approach then: - Construct a grid by hand or (more likely) use an existing minimal library for that. - Enhance the user interface with modern widgets using jQuery UI This makes the solution more pragmatic, simpler and cleaner. If everyone is in agreement then I will start a small PoC? WDYT? On Mon, May 21, 2018 at 11:09 PM, Gavin Mabie <[hidden email]> wrote: > On Mon, May 21, 2018 at 8:03 PM, Taher Alkhateeb <[hidden email] >> 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 <[hidden email]> 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 <[hidden email]> >> wrote: >> > >> >> +1. >> >> >> >> Excellent. >> >> >> >> -----邮件原件----- >> >> 发件人: Taher Alkhateeb [mailto:[hidden email]] >> >> 发送时间: 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 >> >> <[hidden email]> 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 <[hidden email]> >> >> 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 < >> >> >> [hidden email]> 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 >> >> >>>> <[hidden email]> 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, < >> >> [hidden email]> >> >> >>>>> 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 < >> >> [hidden email]> >> >> >>>>>> wrote: >> >> >>>>>> >> >> >>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, < >> >> [hidden email] >> >> >>>>>>>> >> >> >>>>>>> wrote: >> >> >>>>>>> >> >> >>>>>>> Hello Scott, thank you for your thoughts, inline ... >> >> >>>>>>>> >> >> >>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray >> >> >>>>>>>> <[hidden email]> 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, < >> >> >>>>>>>>> >> >> >>>>>>>> [hidden email]> >> >> >>>>>>> >> >> >>>>>>>> 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 >> >> >>>>>>>>>> >> >> >>>>>>>>>> >> >> >>> >> >> > >> >> >> |
|
|
In reply to this post by James Yong-2
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 <[hidden email]> 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 <[hidden email]> wrote: >> On Mon, May 21, 2018 at 8:03 PM, Taher Alkhateeb <[hidden email] >> > 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 <[hidden email]> 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 <[hidden email]> >> > wrote: >> > > >> > >> +1. >> > >> >> > >> Excellent. >> > >> >> > >> -----邮件原件----- >> > >> 发件人: Taher Alkhateeb [mailto:[hidden email]] >> > >> 发送时间: 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 >> > >> <[hidden email]> 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 <[hidden email]> >> > >> 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 < >> > >> >> [hidden email]> 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 >> > >> >>>> <[hidden email]> 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, < >> > >> [hidden email]> >> > >> >>>>> 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 < >> > >> [hidden email]> >> > >> >>>>>> wrote: >> > >> >>>>>> >> > >> >>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, < >> > >> [hidden email] >> > >> >>>>>>>> >> > >> >>>>>>> wrote: >> > >> >>>>>>> >> > >> >>>>>>> Hello Scott, thank you for your thoughts, inline ... >> > >> >>>>>>>> >> > >> >>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray >> > >> >>>>>>>> <[hidden email]> 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, < >> > >> >>>>>>>>> >> > >> >>>>>>>> [hidden email]> >> > >> >>>>>>> >> > >> >>>>>>>> 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 >> > >> >>>>>>>>>> >> > >> >>>>>>>>>> >> > >> >>> >> > >> > >> > >> >> > >> |
Re: [Discussion] Introduction of Bootstrap and Vue.js
Administrator
|
In reply to this post by Jacques Le Roux
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 >> <[hidden email]> 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 <[hidden email]> 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 < >>>> [hidden email]> 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 >>>>>> <[hidden email]> 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, <[hidden email]> >>>>>>> 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 <[hidden email]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, <[hidden email] >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello Scott, thank you for your thoughts, inline ... >>>>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray >>>>>>>>>> <[hidden email]> 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, < >>>>>>>>>>> >>>>>>>>>> [hidden email]> >>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> > > |
Re: [Discussion] Introduction of Bootstrap and Vue.js
|
Administrator
|
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 >>> <[hidden email]> 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 <[hidden email]> 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 < >>>>> [hidden email]> 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 >>>>>>> <[hidden email]> 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, <[hidden email]> >>>>>>>> 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 <[hidden email]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, <[hidden email] >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hello Scott, thank you for your thoughts, inline ... >>>>>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray >>>>>>>>>>> <[hidden email]> 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, < >>>>>>>>>>>> >>>>>>>>>>> [hidden email]> >>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >> >> > > |
Re: [Discussion] Introduction of Bootstrap and Vue.js
|
Administrator
|
In reply to this post by taher
Le 14/05/2018 à 10:38, Taher Alkhateeb a écrit :
> I'm very attracted to > GraphQL for example because of the reduced visits to the backend. That's quite interesting Taher, I just read https://blog.graphql.guide/introducing-the-graphql-guide-11a5ae48628a Thanks Jacques |
Re: [Discussion] Introduction of Bootstrap and Vue.js
|
Administrator
|
Le 13/06/2018 à 19:52, Jacques Le Roux a écrit :
> Le 14/05/2018 à 10:38, Taher Alkhateeb a écrit : >> I'm very attracted to >> GraphQL for example because of the reduced visits to the backend. > That's quite interesting Taher, I just read https://blog.graphql.guide/introducing-the-graphql-guide-11a5ae48628a Mmm, I mean the article, not the book ;) Jacques |
Re: [Discussion] Introduction of Bootstrap and Vue.js
|
|
In reply to this post by Deepak Dixit-3
Hi,
I am trying to evaluate and learn to develop with Apache OFBiz. I am completely new to all of this! I just started looking at this today. As I was exploring the default e-commerce plugin, I found that it is very dated and they have not released themes for it other than the default. Then, I found https://github.com/ORRTIZ/ecbootstrap. This appears to be modern plugin I could use instead, which I was quite excited to see. But, when I try to use it, I'm encountering bugs. For some reason, gradlew blows up with errors about reading XML data in that project. I'm using the latest OFBiz source, and Java JDK. This plugin is a couple of years old, so I figure there is some incompatibility. Since you are in this OFBiz mailing list, and discussing bootstrap, I thought perhaps you could be of help, and this repo I found might be of use to you as well. On 2018/05/14 06:25:20, Deepak Dixit <[hidden email]> wrote: > Hi Taher,> > > I like your proposal, adding bootstrap as common theme looks good idea,> > > Just as note:> > While transforming macros to bootstrap pattern we need to avoid use> > bootstrap classes like pullright, pullLeft, etc.> > instead we will write css rule based on element hierarchy. It will help> > designer to theme as per need.> > > > I am not familier with vue.js so I can;t say anything about vue.js, I'll> > explore it.> > > +1 for POC, we can do POC on branch.> > > Thanks & Regards> > --> > Deepak Dixit> > www.hotwax.co> > > On Sun, May 13, 2018 at 4:55 PM, Jacques Le Roux <> > [hidden email]> wrote:> > > > HI Taher,> > >> > > I agree about doing it directly in the trunk. Else we will get conflict> > > issues, because it will be a long task.> > >> > > +1 for a POC> > >> > > Jacques> > >> > >> > >> > > Le 12/05/2018 à 20:02, Taher Alkhateeb a écrit :> > >> > >> 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> > >>> > >>> > >> > |
Re: [Discussion] Introduction of Bootstrap and Vue.js
|
Administrator
|
In reply to this post by Jacques Le Roux
Le 13/06/2018 à 19:48, Jacques Le Roux a écrit :
> 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... I created OFBIZ-10444 to continue Jacques |
|
|
Sigh, where in this thread do you find agreement on the direction?
On Tue, Jun 26, 2018 at 11:43 AM, Jacques Le Roux <[hidden email]> wrote: > Le 13/06/2018 à 19:48, Jacques Le Roux a écrit : >> >> 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... > > I created OFBIZ-10444 to continue > > Jacques > |
Re: [Discussion] Introduction of Bootstrap and Vue.js
|
Administrator
|
For now it's just for me to investigate
Jacques Le 26/06/2018 à 11:00, Taher Alkhateeb a écrit : > Sigh, where in this thread do you find agreement on the direction? > > On Tue, Jun 26, 2018 at 11:43 AM, Jacques Le Roux > <[hidden email]> wrote: >> Le 13/06/2018 à 19:48, Jacques Le Roux a écrit : >>> 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... >> I created OFBIZ-10444 to continue >> >> Jacques >> |
|
|
In reply to this post by taher
Hi everyone,
I consider to use Apache Ofbiz because it seems very good solution but I agree that the UI of the project is not modern. I think that the proposed features like REST API and modern UI based on Bootstrap and Vue.js are great things and it is sensible way to improve Ofbiz. I'm looking forward to the above features and I would like to ask when it will be done? Tomek |
Re: [Discussion] Introduction of Bootstrap and Vue.js
|
|
Hi Tomek,
Nobody in a community base project can answers to "when it will be done". Some people in the community work on implementing all that is needed to have a complete REST API but for all of them, most of time, customer priority is not the same as community priority, so it will be done when it will be done, but be sure it's one of the OFBiz community priority. Currently we (me and others colleges in company I am working for) are working on a POC for using Vue.js as GUI generated from the current screens/forms/menu xml ofbiz files. The customer goals is to be able to migrate a lot of existing Portal / portlet developed with ofbiz R13.07 on trunk and on a modern GUI. I will present this POC in a few days to the community, and it's a POC, the choices for realizing it are maybe no the corrects ones, but it's possible to discuss about real demonstration, not only concept. As it's a POC, it's clearly not an answer to "does the community will create a GUI with Vue.js and when". For the POC we have used example component to demonstrate a rendering of most of classical ofbiz form field / menu. One week ago, in the POC presentation with the customer, he asked us to have a more "modern UI" and so developers have changed the template from "ofbiz - html" to using vuetify lib. It's really better. This POC consist of three ofbiz plugins : * vusjsportal : all vuejs components and new handler and new renderers * examplefjs : specifics files for the ofbiz example component using vue.js * flatgreyfjs : dedicated theme for vue.js with vuetify In the next mail I will detail major principles used and will give access to a demo. Olivier Le 21/10/2019 à 12:48, Tomek a écrit : > Hi everyone, > > I consider to use Apache Ofbiz because it seems very good solution but I > agree that the UI of the project is not modern. I think that the > proposed features like REST API and modern UI based on Bootstrap and > Vue.js are great things and it is sensible way to improve Ofbiz. I'm > looking forward to the above features and I would like to ask when it > will be done? > > Tomek > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |