Hi Jacopo,
looks nice !

Cheers,


2013/3/21 Jacopo Cappellato <[email protected]>

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


-- 
Erwan de FERRIERES

Reply via email to