You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2018/06/11 14:49:39 UTC
Re: [Discussion] Introduction of Bootstrap and Vue.js
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
>> <in...@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 <ma...@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.roux@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
>>>>>> <sc...@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, <sl...@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 <sc...@hotwaxsystems.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, <slidingfilaments@gmail.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hello Scott, thank you for your thoughts, inline ...
>>>>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray
>>>>>>>>>> <sc...@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, <
>>>>>>>>>>>
>>>>>>>>>> slidingfilaments@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
>>>>>>>>>>>>
>>>>>>>>>>>>
>
>
Re: [Discussion] Introduction of Bootstrap and Vue.js
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
> <ja...@les7arts.com> 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
Posted by Taher Alkhateeb <sl...@gmail.com>.
Sigh, where in this thread do you find agreement on the direction?
On Tue, Jun 26, 2018 at 11:43 AM, Jacques Le Roux
<ja...@les7arts.com> 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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
>>> <in...@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 <ma...@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.roux@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
>>>>>>> <sc...@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, <sl...@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 <sc...@hotwaxsystems.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On Mon, 14 May 2018, 20:38 Taher Alkhateeb, <slidingfilaments@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello Scott, thank you for your thoughts, inline ...
>>>>>>>>>>> On Mon, May 14, 2018 at 10:45 AM, Scott Gray
>>>>>>>>>>> <sc...@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, <
>>>>>>>>>>>>
>>>>>>>>>>> slidingfilaments@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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>
>>
>
>