I don't think it's really our UI that inhibits adoption. With any reasonably sized project there is going to be a large amount of UI customization where the front-end will be almost completely written from scratch and the back-end at least partially so. This has been my experience at least over the past 9 years.
It's also been my experience that form widgets don't play a large role in this effort with most development being done using Freemarker. Increasingly common in the last few years there has been a desire to use SPA frameworks such as AngularJS for the admin apps and smaller front-end apps. It's my opinion that while a custom UI framework is a "nice to have", it is by no means offers much of a selling point when you compare it to things like the domain model and the extensive business logic supported in OFBiz. Telling non-OFBiz front-end developers that they must now use the widget framework to build their AJAX intensive screens isn't much fun to be honest. A good majority of the data gathering logic is tightly coupled to the OOTB UI and isn't particularly re-usable. Writing a JSON-RPC or REST based API for custom screens is usually quite a bit of work because there isn't any inherent support for it in the framework and you tend to just hack something together on the fly due to time/budget constraints. We have thousands of services in OFBiz with very little documentation and often overlapping responsibilities. For example, cancelling an order, should I use "updateOrderHeader"? "changeOrderStatus"? Maybe "massCancelOrders"? Not to mention a large number of the services are intended to be ECAs only and not called directly, but there's generally no way of knowing that. Virtually every time you go to use a service you have to go and look at the implementation and see if it's actually going to do what you expect it to and what the side-effects might be. And then even with these thousands of services, there's virtually no services for gathering and returning data. That's all done in the data prep for screens and isn't particularly re-usable and even if it were, how would you know without sifting through the implementation because there's no documentation for these scripts. Sometimes it's a mix of a few widget actions gathering data in different ways (XML lookups in the actions, service calls and groovy scripts). So while I see our web layer as a nice to have, I strongly believe that were OFBiz needs the most enhancement is in the business logic API. Modern UI frameworks take a lot of the legwork out building a good UI these days, but we don't stand to benefit from any of that while we continue to try and build our own solution that will never be any where near as good. The strength of OFBiz is in the business logic and I think we do ourselves a disservice by considering our web framework to be the primary means of accessing it. I'm increasingly leaning towards wanting to find a way to deeply incorporate RESTfulness deeply into our framework. Primarily because of the API simplification it would entail. For example, instead of 10s if not 100s of services relating to creating/updating an order, you would simply have get/put/post that works against a full order resource. We'd then use something similar to our ECAs and service engine to validate the document and execute related operations against the modified resource. In this manner you'd reduce our main API down from thousands of services to less than one hundred resource models. That's just an idea though, the main point here is that I think our UI matters less than providing a means for implementers to access the business logic using any means they deem necessary through a simple comprehensive well-documented API. Regards Scott On 28/11/2016 23:08, "Sharan Foga" <sha...@apache.org> wrote: > Hi Everyone > > One of the topics that came up during the brainstorming in Seville was > that the project desperately needs a clear strategy and roadmap. > > Benefits: > - A strategy will provide a clear path for people to follow > - A strategy will allow us to set goals / milestones and metrics about > progress > > In past maybe we have tried to do too much (tried to do it all at once - > which is why we find it h ard to focus). > > - One suggestion was to set a maximum of 3 goals and then work only on > these. To define these goals we need to look at what is the most important > thing that we want to achieve - and base them on that. > - Another suggestion was that the most important thing for the project is > driving adoption. If this is true then what are the key blockers that stop > user adoption of OFBiz? (the UI!) > - Suggestion to organise / setup teams from the community that focus on > specific areas (e.g. workgroups) - this could really help progress > > So to get the discussion started: > > 1. Do people agree that the project needs to focus on driving adoption? > 2. Do people think that the UI is one of the key things that stops this ? > (If, not then please include what do you think is) > 3. What goals could we set? > 4. Are people interested in working in workgroups, to focus on specific > areas (or goals)? > > (I know there are some ideas/work around the UI going on, but I will post > the Seville details and notes about that in separate discussion thread.) > > Thanks > Sharan > >
