Any effort to reduce the amount of code is worthwhile.
-Adrian
On 3/28/2013 5:14 PM, Nicolas Malin wrote:
Sound good,
it was mentioned on the last thread to replace mini-lang CRUD by
entity-auto service, I have been started an issue. Is this still valid ?
Nicolas
Le 21/03/2013 11:57, Jacopo Cappellato a écrit :
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
