Hi All, My humble opinion is to switch to using JSON object to submit/retrieve form/table data to the server. With this change, it will be easier to introduce VUE later. Also try not to introduce any further jQuery dependency.
Regards, James On 2018/05/21 20:09:43, Gavin Mabie <kwikst...@gmail.com> wrote: > On Mon, May 21, 2018 at 8:03 PM, Taher Alkhateeb <slidingfilame...@gmail.com > > wrote: > > > Hello Gavin, Your timing is pretty good actually and we can gain from > > your experience. Comments and questions inline ... > > > > On Mon, May 21, 2018 at 1:03 PM, Gavin Mabie <kwikst...@gmail.com> wrote: > > > Hi guys > > > > > > I've been away for a while so my input maybe a bit behind the curve. > > > Having said that, I have some useful Bootstrap-with-Ofbiz experience > > under > > > the belt which may be relevant to this discussion: > > > 1. Bootstrap is mainly CSS. It's pretty, but with limited JavaScript > > > functionality. In-fact JS in Bootstrap is entirely optional because it > > > doesn't pretend to be a JS Framework. > > > > Perhaps this is a point in favor of Bootstrap. The less JavaScript the > > less messy things are. > > > > That's true - and it really looks good. But the real good stuff that users > expect from a modern UI needs the power provided by JS. > So Bootstrap without JS is good until you need to expand or collapse a > panel, or you need a modal (crucial in UI design), or a tab, > accordion,popover etc. > Then you'll need Bootstrap JS. These are called components (widgets) in the > Bootstrap universe and they are really common across most JS frameworks. > It is important to note that in Bootstrap JS components are limited (about > 10 in total) and it excludes some which are critical for Ofbiz (see below). > > > > > > > 2. You will be required to mine 3rd party plugins/widgets to cover > > > functionalities absent from Bootstrap - and those may not be > > > well-maintained. Risky! > > > > What would we need? And why would we need it? Why _must_ it be a plugin? > > > > We need a datepicker and we already have a robust one in Ofbiz (jQuery Ui > Datepicker). It's used all over the place. > Bootstrap doesn't come with a datepicker functionality - you can use > something like bootstrap-datepicker from eternicode (a 3rd party). I guess > that's the plugin. > Of course this means more dependencies, more maintenance management. > Besides, implementing i18N with bootstrap datepicker is a tricky > proposition. Alternatively you could choose to use the jQuery UI > Datepicker with bootstrap. But that means more libraries to manage. > > > > > > 3. Autocomplete and Date Picking functions specifically - frequently used > > > in Ofbiz, but not "native" in Bootstrap. This sometimes leads to all > > manner > > > of conflicts and complicates manageability. > > > > Can you elaborate please? Do you have an example of a problem that we > > will would face should we adopt Bootstrap? > > > I've alluded to the multiple library problem above at the hand of the date > picking functionality. Another big gap is the fact that bootstrap doesn't > have a "native" autocomplete/autosuggest functionality. > You'll probably find one if you search around and you could probably write > your own. This functionality already exists in jQuery UI. You could try to > dress the jQury UI functionalities with bootstrap CSS to > achieve a consistent look-and-feel. My experience is that this approach > would soon bloat your CSS to unmanageable proportions. In summary - using > jQuery UI along-side bootstrap or visa-versa is a no-no. > There can be only ONE. > > > > > > > > > > > If your only criteria for Bootstrap is grid-layout capabilities, consider > > > that grid is quite easily attainable with pure CSS through the @media > > > > That's a lot of work! That's like saying let's write a desktop app in > > Assembly. I mean you can do it, but why! The "@media" is just a > > building block. > > > > Actually, it is not a lot work at all. For your responsive design you > decide on screen sizes, define breakpoints and write the CSS. see( > https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries) > . > > > > > > selector used with break points. Secondly, "Grid" will become a standard > > in > > > CSS (see https://www.w3.org/TR/css-grid-2/). The investment in a > > > "framework" for "Grid" only - that's an overkill. > > > > Well, naturally, if you implement bootstrap then you get all the > > goodies with it, not just the grid, otherwise you can choose a simple > > Grid library (many out there) > > > > If you list the "goodies", you'll see that its really not that impressive: > Bootstrap component List (I count ten) > > - Modal > - Dropdown > - Scrollspy > - Tab > - Tooltip > - Popover > - Alert > - Button > - Collapse (Accordion) > - Carousel > > jQuery UI goodies: > > - Accordion > - Autocomplete > - Button > - Checkboxradio > - Controlgroup > - Datepicker > - Dialog > - Menu > - Progressbar > - Selectmenu > - Slider > - Spinner > - Tabs > - Tooltip > > Pound for pound I'll pick jQuery UI over bootstrap. > > Now throw in jQuery Mobile and you get even more functionality - including > SPA. Note there is not conflict between jQuery UI and jQuery Mobile - the > work together well. > > > > > > > > > My 2 Cents: > > > 1. How about jQuery Mobile(JQM)? It's part of the jQuery family. We > > > already use jQuery as JavaScript framework, to use JQM would be a logical > > > extension. > > > 2. JQM covers SPA - an important functionality identified by some in this > > > thread. > > > 3. JQM fits in nicely with jQuery UI - something which we are already > > using > > > in Ofbiz with autocomplete/suggest, date picking and modals. > > > > > > Final thoughts - Cleaner separation between JS and Freemarker using HTML > > > elements: > > > 1. We are not using new outlining and sectioning elements like <section>, > > > <article>, <nav>, <header>, <footer>, or <aside> in our templates. They > > > hold obvious advantages. > > > 2. Global data-* attributes. We're not using this at all. It can help > > us > > > to reduce JS in Freemarker templates. > > > > > > Regards > > > > > > Gavin > > > > > > > > > > > > > > > > > > On Mon, May 21, 2018 at 5:17 AM, Shi Jinghai <huaru...@hotmail.com> > > wrote: > > > > > >> +1. > > >> > > >> Excellent. > > >> > > >> -----邮件原件----- > > >> 发件人: Taher Alkhateeb [mailto:slidingfilame...@gmail.com] > > >> 发送时间: 2018年5月20日 2:31 > > >> 收件人: OFBIZ Development Mailing List > > >> 主题: Re: [Discussion] Introduction of Bootstrap and Vue.js > > >> > > >> This was a thought provoking and interesting discussion and I learned > > >> new stuff from it, so thank you all for your valuable input. > > >> > > >> On further reflection and after thinking about your comments, I think > > >> Vue.js would be influenced in its design if we have a REST API in > > >> place, however, something like Bootstrap is not relevant because it is > > >> just a pure CSS / Javascript library to offer a grid system and some > > >> user interface widgets. It has no model to bind to nor does it require > > >> any back-end traffic (SPA stuff). > > >> > > >> So I recommend proceeding with Bootstrap, and we can delay something > > >> like Vue.js while we proceed in implementing the Web Services API. > > >> I'll start or find another thread for that discussion. > > >> > > >> WDYT? > > >> > > >> On Fri, May 18, 2018 at 10:43 AM, innate Genius > > >> <innate.pass...@gmail.com> wrote: > > >> > Hi, > > >> > > > >> > +1 For Jacques, Scot & Rajesh’s View Point. > > >> > > > >> >> "I feel most of the modern UI frameworks consume JSON and > > >> >> if we have yet another adapter to the rich catalog of WebServices > > >> >> ( in addition to XML/RPC and SOAP) it shall benefit both UI > > developers > > >> >> and > > >> >> system integrators / framework users." > > >> > > > >> > This is been discussed in few other threads but this is a issue that > > is > > >> long due. And would love to see the community to finally address this. > > >> > > > >> > @Taher: Webservice to consume JSON would be the most beneficial and > > >> desired enhancement to the framework. > > >> > > > >> > Thx & Rgds, > > >> > > > >> > Pratiek > > >> > > > >> >> On 17-May-2018, at 9:27 PM, Rajesh Mallah <mallah.raj...@gmail.com> > > >> wrote: > > >> >> > > >> >> Hi List , > > >> >> > > >> >> The default UI of OFBiz does look aged but I feel it does a great job > > >> >> of being productive. As discussed before also ERP being a serious > > >> >> backroom software and mostly operated by staff to whom all the bells > > >> >> and whistles of modern frameworks may not make any difference. > > >> >> > > >> >> But since adoption of OFBiz to enterprises is dependent on decision > > >> makers/ > > >> >> influencer who may not even know the nuances of UI and its relation > > to > > >> >> productivity it is important to look modern and shiny and which is > > the > > >> >> reason of > > >> >> this thread by Mr. Taher. > > >> >> > > >> >> > > >> >> Hence IMHO its good and required for OFBiz. > > >> >> > > >> >> At the same time we need to increase the comfort level of system > > >> integrators > > >> >> and people who use ofbiz as a framework. > > >> >> > > >> >> I feel most of the modern UI frameworks consume JSON and > > >> >> if we have yet another adapter to the rich catalog of WebServices > > >> >> ( in addition to XML/RPC and SOAP) it shall benefit both UI > > developers > > >> >> and > > >> >> system integrators / framework users. > > >> >> > > >> >> I also humbly feel while this modernization is done, the existing > > >> interface > > >> >> should > > >> >> not be done away with as people develop very strange and innovative > > >> comfort > > >> >> zones with software UIs which are difficult to anticipate by > > developers. > > >> >> > > >> >> my 2cents. > > >> >> > > >> >> > > >> >> regds > > >> >> mallah. > > >> >> > > >> >> > > >> >> On Wed, May 16, 2018 at 5:30 PM, Jacques Le Roux < > > >> >> jacques.le.r...@les7arts.com> wrote: > > >> >> > > >> >>> Hi Scott, Taher, > > >> >>> > > >> >>> I think you are both right, and maybe because you are mostly working > > >> for 2 > > >> >>> different markets or have different types of clients. > > >> >>> > > >> >>> Anyway, what I mean is: > > >> >>> > > >> >>> 1. Form widgets are not of much use when you have to deploy a new UI > > >> for > > >> >>> an ecommerce or alike project (frontend). > > >> >>> 2. They are very useful when you are working on a backend project > > (ie > > >> ERP > > >> >>> part) where people don't care much about bells and whistle (even if > > >> that's > > >> >>> less and less happening) but want a fast ROI ("time-to-market > > >> reasons" > > >> >>> as said Taher) > > >> >>> > > >> >>> I don't know if Mathieu will get enough time to succeed on his > > project. > > >> >>> But obviously if we had the possibility to generate RESTful web > > >> services > > >> >>> from OFBiz services, with the export attribute like for SOAP and > > RMI, > > >> then > > >> >>> Scott's idea would be fulfilled and that would help much, not only > > in > > >> the > > >> >>> UI area of course. > > >> >>> > > >> >>> Now for widgets, the form part could maybe slowly replaced by using > > >> tools > > >> >>> like Bootstrap and Vue.js. Or the new flavor in some years and that > > >> must be > > >> >>> very seriously taken into account to not have to redo it again, in > > few > > >> >>> years... > > >> >>> > > >> >>> Jacques > > >> >>> > > >> >>> > > >> >>> > > >> >>> Le 15/05/2018 à 12:18, Taher Alkhateeb a écrit : > > >> >>> > > >> >>>> Ahhh, I understand clearly now. Thank you! > > >> >>>> > > >> >>>> So more or less, the heart of your message as I understand it is > > that > > >> >>>> we should decouple the rendering of the user interface from data > > >> >>>> fetching and manipulation. This makes perfect sense and is a good > > >> >>>> strategy. > > >> >>>> > > >> >>>> A bit contrary to your experience though, most of our work relies > > >> >>>> heavily on the widget system for time-to-market reasons. It has > > been > > >> >>>> immensely beneficial to get something out the door quickly. > > However, > > >> >>>> of course the system falls short when it comes to heavy > > customizations > > >> >>>> or the need to integrate with other systems. > > >> >>>> > > >> >>>> So I would suggest that perhaps your comment in this thread that > > >> >>>> "having prebuilt APIs would have reduced the workload" is > > applicable > > >> >>>> in case of custom work. Otherwise, perhaps the faster route is > > through > > >> >>>> the widget system. Therefore I think it is reasonable to apply both > > >> >>>> strategies: 1) use good modern UI tools 2) build powerful flexible > > web > > >> >>>> APIs. But for standard screens, I see no reason to use web service > > >> >>>> calls instead of <action>...</action> tags to do quick and obvious > > >> >>>> things unless perhaps you make the web API call part of the widget > > >> >>>> system itself (also a good idea!) > > >> >>>> > > >> >>>> Anyway, you're making me think more seriously of pushing forward > > the > > >> >>>> implementation of web services, but I think introducing these > > >> >>>> frameworks is going to be beneficial either way. > > >> >>>> > > >> >>>> On Tue, May 15, 2018 at 12:44 PM, Scott Gray > > >> >>>> <scott.g...@hotwaxsystems.com> wrote: > > >> >>>> > > >> >>>>> Hi Taher, > > >> >>>>> > > >> >>>>> I'm simply saying that if we were to provide a complete suite web > > >> APIs to > > >> >>>>> access the full functionality of ofbiz, then the project's choice > > of > > >> UI > > >> >>>>> technology no longer matters so much in the grand scheme of > > things. > > >> No > > >> >>>>> one > > >> >>>>> would be forced to live by our choice of UI frameworks because > > they > > >> could > > >> >>>>> build anything they liked using the APIs without ever touching the > > >> >>>>> server-side code. > > >> >>>>> > > >> >>>>> Right now our data gathering logic is tightly coupled to our UI, > > >> >>>>> inaccessible to other servers and apps, the vast majority of our > > >> services > > >> >>>>> are built to be run internally by ofbiz. Without heavy > > modification > > >> of > > >> >>>>> the > > >> >>>>> server side code, I can't build a custom SPA, I can't send orders > > to > > >> >>>>> ofbiz > > >> >>>>> from another application, I can't really do anything without > > >> interacting > > >> >>>>> with the OFBiz UI. > > >> >>>>> > > >> >>>>> The majority of the client projects I've worked on always involve > > a > > >> >>>>> completely custom UI and with web APIs I could pick up any flavor > > of > > >> the > > >> >>>>> month UI framework to build it with. > > >> >>>>> > > >> >>>>> All I'm trying to add to this conversation is that it would be > > nice > > >> if > > >> >>>>> any > > >> >>>>> UI overhaul started with making APIs available that could be used > > >> both by > > >> >>>>> our framework of choice and be externally accessible to anyone > > else's > > >> >>>>> framework of choice. > > >> >>>>> > > >> >>>>> Regards > > >> >>>>> Scott > > >> >>>>> > > >> >>>>> > > >> >>>>> On Tue, 15 May 2018, 20:27 Taher Alkhateeb, < > > >> slidingfilame...@gmail.com> > > >> >>>>> wrote: > > >> >>>>> > > >> >>>>> Hi Scott, > > >> >>>>>> > > >> >>>>>> Again thank you for the input, intriguing. I'm not sure if I > > fully > > >> >>>>>> understand though. Are you saying we can introduce web services > > >> that can > > >> >>>>>> sort of do away with the widget system to code directly in html > > and > > >> >>>>>> weaving > > >> >>>>>> in web service calls? How does that make coding faster? What is > > >> >>>>>> inefficient > > >> >>>>>> in the widget system? What kind of architecture should we have in > > >> place? > > >> >>>>>> What is the routing workflow that you're suggesting? > > >> >>>>>> > > >> >>>>>> I would appreciate a bit more elaboration to get a better > > >> understanding > > >> >>>>>> of > > >> >>>>>> your point of view since this seems to be a critical > > architectural > > >> >>>>>> decision. > > >> >>>>>> > > >> >>>>>> > > >> >>>>>> On Mon, May 14, 2018, 9:39 PM Scott Gray < > > >> scott.g...@hotwaxsystems.com> > > >> >>>>>> wrote: > > >> >>>>>> > > >> >>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, < > > >> slidingfilame...@gmail.com > > >> >>>>>>>> > > >> >>>>>>> wrote: > > >> >>>>>>> > > >> >>>>>>> Hello Scott, thank you for your thoughts, inline ... > > >> >>>>>>>> > > >> >>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray > > >> >>>>>>>> <scott.g...@hotwaxsystems.com> wrote: > > >> >>>>>>>> > > >> >>>>>>>>> I think no matter what we use someone will always want > > something > > >> >>>>>>>>> > > >> >>>>>>>> different. > > >> >>>>>>>> > > >> >>>>>>>>> I'm beginning to lose count of the number of custom APIs I've > > >> written > > >> >>>>>>>>> > > >> >>>>>>>> over > > >> >>>>>>>> > > >> >>>>>>>>> the years to support custom UIs. > > >> >>>>>>>>> > > >> >>>>>>>>> I think the bigger win would be to start providing APIs and > > >> rewriting > > >> >>>>>>>>> > > >> >>>>>>>> our > > >> >>>>>>> > > >> >>>>>>>> existing screens to use them. From there we could start > > looking at > > >> >>>>>>>>> > > >> >>>>>>>> new > > >> >>>>>> > > >> >>>>>>> UI > > >> >>>>>>> > > >> >>>>>>>> frameworks. > > >> >>>>>>>>> > > >> >>>>>>>> Do you mean by APIs rewriting our XSD files and model objects? > > Why > > >> >>>>>>>> rewrite? Why not just enhance them for new / missing > > >> functionality? > > >> >>>>>>>> What are the flaws you'd like to redesign? > > >> >>>>>>>> > > >> >>>>>>>> No, I'm talking about web services. With well designed web > > >> services > > >> >>>>>>> > > >> >>>>>> custom > > >> >>>>>> > > >> >>>>>>> projects would be able to build out new user interfaces in a lot > > >> less > > >> >>>>>>> > > >> >>>>>> time > > >> >>>>>> > > >> >>>>>>> and we'd be able to poc new interfaces for the community project > > >> >>>>>>> without > > >> >>>>>>> even touching the existing codebase. > > >> >>>>>>> > > >> >>>>>>> > > >> >>>>>>> Most of the projects I've worked on have needed huge amounts of > > UI > > >> >>>>>>>>> customization and having prebuilt APIs would have reduced the > > >> >>>>>>>>> > > >> >>>>>>>> workload > > >> >>>>>> > > >> >>>>>>> much > > >> >>>>>>>> > > >> >>>>>>>>> more than having a shinier UI that still needs to be > > completely > > >> >>>>>>>>> > > >> >>>>>>>> rewritten, > > >> >>>>>>>> > > >> >>>>>>>>> although I'll admit the latter would probably help the sales > > >> process. > > >> >>>>>>>>> > > >> >>>>>>>> The "shiny" part is a plus, but not the core of my suggestion. > > The > > >> >>>>>>>> reasons I suggested these libraries are: > > >> >>>>>>>> - bootstrap: the grid system, this is the cake for me. You > > have a > > >> >>>>>>>> powerful responsive grid system for better layouts. The > > buttons, > > >> >>>>>>>> tables and other bling bling are icing on the cake. > > >> >>>>>>>> - Vue: The core of this technology is to allow binding of your > > >> context > > >> >>>>>>>> model to the DOM so that you don't write oodles of JavaScript > > and > > >> >>>>>>>> Jquery to create dynamic behavior. It's really old school in > > 2018 > > >> to > > >> >>>>>>>> keep jumping between many pages to get something done. > > >> >>>>>>>> > > >> >>>>>>>> Does it not worry anyone else that our service engine still > > only > > >> >>>>>>>>> > > >> >>>>>>>> defines > > >> >>>>>>> > > >> >>>>>>>> a > > >> >>>>>>>> > > >> >>>>>>>>> basic map for in/out parameters when the rest of the world is > > >> using > > >> >>>>>>>>> > > >> >>>>>>>> the > > >> >>>>>> > > >> >>>>>>> likes of swagger and restful APIs? > > >> >>>>>>>>> > > >> >>>>>>>> Of course it worries me, and if you start an initiative I will > > be > > >> the > > >> >>>>>>>> first to jump in and volunteer. In fact it's on my todo list, > > and > > >> I > > >> >>>>>>>> was looking at multiple options lately and I'm very attracted > > to > > >> >>>>>>>> GraphQL for example because of the reduced visits to the > > backend. > > >> >>>>>>>> However, I don't see this as being related to my proposal here, > > >> I'm > > >> >>>>>>>> just setting my own priorities of what to work on next. What's > > >> wrong > > >> >>>>>>>> with starting _both_ initiatives for that matter? > > >> >>>>>>>> > > >> >>>>>>>> Nothing is wrong with both, but as you pointed out many > > >> discussions > > >> >>>>>>> and > > >> >>>>>>> efforts have begun and then floundered. I'm simply offering some > > >> >>>>>>> thoughts > > >> >>>>>>> on where I see the most potential benefit from a large scale > > >> effort. > > >> >>>>>>> > > >> >>>>>>> > > >> >>>>>>> Regards > > >> >>>>>>>>> Scott > > >> >>>>>>>>> > > >> >>>>>>>>> On Sun, 13 May 2018, 06:03 Taher Alkhateeb, < > > >> >>>>>>>>> > > >> >>>>>>>> slidingfilame...@gmail.com> > > >> >>>>>>> > > >> >>>>>>>> wrote: > > >> >>>>>>>>> > > >> >>>>>>>>> Hello Everyone, > > >> >>>>>>>>>> > > >> >>>>>>>>>> Recently, we at Pythys had some interactions with clients, > > and > > >> the > > >> >>>>>>>>>> user interface proved to be a sour point. It is functioning > > >> well, > > >> >>>>>>>>>> > > >> >>>>>>>>> but > > >> >>>>>> > > >> >>>>>>> looks too classic, too rigid, too 2000s really :) We had many > > >> >>>>>>>>>> discussion and attempts in the past like [1] [2] [3] [4] [5] > > >> [6] [7] > > >> >>>>>>>>>> [8] [9] [10] just to name a few all of which seemed not to > > >> follow > > >> >>>>>>>>>> through. > > >> >>>>>>>>>> > > >> >>>>>>>>>> So what is the problem? Why is this hard to get right? I'm > > not > > >> sure > > >> >>>>>>>>>> > > >> >>>>>>>>> I > > >> >>>>>> > > >> >>>>>>> have the magic answer, but it seems to me like part of the > > problem > > >> >>>>>>>>>> > > >> >>>>>>>>> is > > >> >>>>>> > > >> >>>>>>> simply .. TOO BIG > > >> >>>>>>>>>> > > >> >>>>>>>>>> So I was thinking about a possible solution, and after some > > >> initial > > >> >>>>>>>>>> research, I think maybe the solution (like everything else) > > >> needs to > > >> >>>>>>>>>> be slow, incremental and evolutionary rather than > > >> revolutionary. So > > >> >>>>>>>>>> > > >> >>>>>>>>> I > > >> >>>>>> > > >> >>>>>>> am suggesting the following ideas to try and move forward: > > >> >>>>>>>>>> > > >> >>>>>>>>>> - We include the assets for Bootstrap in the common theme. > > >> Bootstrap > > >> >>>>>>>>>> will give us the Grid system which allows for a responsive > > >> website > > >> >>>>>>>>>> that works on all devices, it will also give us beautiful > > >> widgets to > > >> >>>>>>>>>> work with. > > >> >>>>>>>>>> - We include Vue.js assets in the common theme. Vue.js is an > > >> >>>>>>>>>> > > >> >>>>>>>>> excellent > > >> >>>>>> > > >> >>>>>>> framework for creating Single Page Applications (SPAs) to give > > >> >>>>>>>>>> > > >> >>>>>>>>> dynamic > > >> >>>>>> > > >> >>>>>>> behavior to our pages and create ajax-heavy pages > > >> >>>>>>>>>> - We slowly migrate our old CSS to bootstrap constructs. We > > can > > >> >>>>>>>>>> > > >> >>>>>>>>> begin > > >> >>>>>> > > >> >>>>>>> for example by replacing our menus, then tables, then headers, > > then > > >> >>>>>>>>>> buttons etc .. > > >> >>>>>>>>>> - We slowly introduce dynamic screens using controller logic > > in > > >> >>>>>>>>>> > > >> >>>>>>>>> Vue.js > > >> >>>>>> > > >> >>>>>>> - We slowly update our macro library to migrate to the above > > >> >>>>>>>>>> > > >> >>>>>>>>> mentioned > > >> >>>>>> > > >> >>>>>>> libraries and widgets > > >> >>>>>>>>>> - We do all of this live in Trunk, without branching. This > > means > > >> >>>>>>>>>> > > >> >>>>>>>>> that > > >> >>>>>> > > >> >>>>>>> for some period of time, there will be transitional code (a > > little > > >> >>>>>>>>>> > > >> >>>>>>>>> bit > > >> >>>>>> > > >> >>>>>>> of bootstrap and a little bit of our current code) > > >> >>>>>>>>>> > > >> >>>>>>>>>> We can start with an initial proof of concept skeleton, and > > if > > >> that > > >> >>>>>>>>>> gets consensus, then we can move forward with a full > > >> implementation > > >> >>>>>>>>>> > > >> >>>>>>>>> in > > >> >>>>>> > > >> >>>>>>> trunk. I think this issue is many years over due. Our interface > > >> >>>>>>>>>> > > >> >>>>>>>>> looks > > >> >>>>>> > > >> >>>>>>> oooooooooooooold and really needs a face lift. > > >> >>>>>>>>>> > > >> >>>>>>>>>> What do you think? Ideas? Suggestions? > > >> >>>>>>>>>> > > >> >>>>>>>>>> [1] https://s.apache.org/rf94 > > >> >>>>>>>>>> [2] https://s.apache.org/g5zr > > >> >>>>>>>>>> [3] https://s.apache.org/XpBO > > >> >>>>>>>>>> [4] https://s.apache.org/YIL1 > > >> >>>>>>>>>> [5] https://s.apache.org/836D > > >> >>>>>>>>>> [6] https://s.apache.org/DhyB > > >> >>>>>>>>>> [7] https://s.apache.org/Lv9E > > >> >>>>>>>>>> [8] https://s.apache.org/zKIo > > >> >>>>>>>>>> [9] https://s.apache.org/D6jx > > >> >>>>>>>>>> [10] https://issues.apache.org/jira/browse/OFBIZ-5840 > > >> >>>>>>>>>> > > >> >>>>>>>>>> > > >> >>> > > >> > > > >> > > >
