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
>>>>>>>>>
>>>>>>>>>
>>
