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
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
