I would like to see a deep refactoring of the UI. Ideally, it should be separated into two distinct components, a view renderer and a series of authenticated services that support it. It is about time for us to step into the modern world where the UI is an application, written in Javascript, that communicates with the application using JSON or XML RPC calls. If rendering for javascriptless clients is really still a priority then we might want to look at using rhino or nashorn in the server to do the same rendering there but, fundamentally, move to a javascript based view rendering solution. The interactivity and fluidity of a properly AJAX based interface is part of what makes us look so dated compared to solutions like OpenERP.
We also need to completely reconsider the UI experience. The interface is overwhelming to new users. If we could have a role based method for hiding controls then we could have a "beginner" user mode that greatly simplified core screens. A basic drop-ship ecommerce user doesn't need to see billing accounts, facilities and a lot of the other complexity on the product screens. Our order entry process is also rather clunky, even in comparison to older systems like SQL-Ledger. ----- "Jacopo Cappellato" wrote: > Hi all, > this is just intended to brainstorm some ideas for the future OFBiz (let's > say for the 14.04 branch) and to get the community feedback... I don't have > concrete plans at the moment for most of them > Some of the ideas below are intended to renew some core parts of the OFBiz > Framework, replacing custom code (some of getting old) with Open Source > alternatives; some of them are just cleanups. > * Replace the OFBiz TX Manager and the Database Connection Pool (Geronimo TX > and DBCP, well... they actually can stay as optional components) with: > http://www.atomikos.com/Main/TransactionsEssentials > (see initial work on https://issues.apache.org/jira/browse/OFBIZ-5129 ) > * Refactor the OFBiz Security (authentication/authorization/cryptography) > with (a session I attended during ApacheCon@Portland inspired me for this): > http://shiro.apache.org > * Replace Javolution (this has been already discussed in the past) > * Replace the OFBiz cache system with: > http://ehcache.org > * Replace the OFBiz job scheduler with: > http://quartz-scheduler.org > * Reorganize the screen data preparation Groovy scripts into bigger files > with methods (they are now individual files); for example, instead of having: > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductAssoc.groovy > > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContent.groovy > > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContentContent.groovy > > applications/product/webapp/catalog/WEB-INF/actions/product/EditProductFeatures.groovy > > ... > we could have one file: > applications/product/webapp/catalog/WEB-INF/actions/EditProduct.groovy > with methods: > editProductAssoc, editProductContent, editProductContentContent, > editProductFeatures... > (note: this switch is possible since the enhancements we did one year ago); > this could make our code more readable and organized without loosing the > ability to override individual scripts from hot-deploy components; in the > process, we could also review the scripts and clean them or improve (some of > them are pretty old) > * (in the process) we could also refactor the code of the Groovy scripts to > use the (now experimental and to be tested/expanded) DSL methods we > implemented one year ago > Kind regards, > Jacopo -- Ean Schuessler, CTO [email protected] 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
