Re: Some ideas for the future of the OFBiz
Hi Ean, Thanks for expanding on this. For most functions, I think I'm in agreement. If the user wants to do something but the function is invisible or greyed, it can be frustrating. Sometimes it can be better to leave a function visible, because when the user tries to use it, you can communicate why it is that they can't use the function at the moment. You can also say what they would need to change to gain access to the function. I think most things can simply be hidden from a user that doesn't have access, but we need to watch this. For things a user might reasonably want to do, we need to consider how we can communicate what's needed to achieve their goal. Cheers Paul Foxworthy Ean Schuessler wrote I'm not so much suggesting a beginner mode as I am suggesting that controls be scoped to the role of the logged in user. It just doesn't make sense to show controls that link to screens that the user does not have access to. A side-effect of this would be that an order entry user would have greatly simplified screens. - Paul Foxworthy wrote: Hi Ean, I am absolutely 100% in agreement that the user experience is a big barrier to entry for OFBiz. I am comfortable with Javascript being part of the primary user interface, provided there is architectural provision for alternatives. I do not think that a limited beginner mode is the answer. See the thread at http://ofbiz.135035.n4.nabble.com/hiding-functionality-in-ofbiz-td3473417.html for some discussion on this. Cheers Paul Foxworthy -- Ean Schuessler, CTO ean@ 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com - -- Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4640297.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas for the future of the OFBiz
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/
Re: Some ideas for the future of the OFBiz
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
Re: Some ideas for the future of the OFBiz
+1 On Mar 28, 2013, at 6:22 PM, Adrian Crum adrian.c...@sandglass-software.com wrote: 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
Re: Some ideas for the future of the OFBiz
I'm not so much suggesting a beginner mode as I am suggesting that controls be scoped to the role of the logged in user. It just doesn't make sense to show controls that link to screens that the user does not have access to. A side-effect of this would be that an order entry user would have greatly simplified screens. - Paul Foxworthy wrote: Hi Ean, I am absolutely 100% in agreement that the user experience is a big barrier to entry for OFBiz. I am comfortable with Javascript being part of the primary user interface, provided there is architectural provision for alternatives. I do not think that a limited beginner mode is the answer. See the thread at http://ofbiz.135035.n4.nabble.com/hiding-functionality-in-ofbiz-td3473417.html for some discussion on this. Cheers Paul Foxworthy -- Ean Schuessler, CTO e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Some ideas for the future of the OFBiz
Hi Jacopo, +1 I hope there is a vote for prioritizing the implementation sequence of these amazing Ideas. Regards, Medhat -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4640208.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas for the future of the OFBiz
GSoC is coming, and ideas are listed in Jira. https://issues.apache.org/jira/issues/?jql=labels%20%3D%20gsoc2013%20ORDER%20BY%20key%20ASC Maybe we could create an issue on this point and have a student make a POC based on some framework like bootstrap ? Cheers 2013/3/22 Ean Schuessler e...@brainfood.com 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 e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com -- Erwan de FERRIERES
Re: Some ideas for the future of the OFBiz
Hi Ean, I am absolutely 100% in agreement that the user experience is a big barrier to entry for OFBiz. I am comfortable with Javascript being part of the primary user interface, provided there is architectural provision for alternatives. I do not think that a limited beginner mode is the answer. See the thread at http://ofbiz.135035.n4.nabble.com/hiding-functionality-in-ofbiz-td3473417.html for some discussion on this. Cheers Paul Foxworthy Ean Schuessler wrote 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 ean@ 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com - -- Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4640057.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas for the future of the OFBiz
Hi Hongs, OFBiz *had* some workflow features using Shark, but there was not a lot of use of it and it has been removed, see https://issues.apache.org/jira/browse/OFBIZ-4795. Are jBPM or Activiti significantly different and better? Cheers Paul Foxworthy hongs bill wrote +1 add workflow engine,such as jBPM or Activiti . -- I am hongs - -- Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4640058.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas for the future of the OFBiz
jBPM or Activiti is licensed under the Apache License 2.0. They are more popular than shark. 2013/3/25 Paul Foxworthy p...@cohsoft.com.au Hi Hongs, OFBiz *had* some workflow features using Shark, but there was not a lot of use of it and it has been removed, see https://issues.apache.org/jira/browse/OFBIZ-4795. Are jBPM or Activiti significantly different and better? Cheers Paul Foxworthy hongs bill wrote +1 add workflow engine,such as jBPM or Activiti . -- I am hongs - -- Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4640058.html Sent from the OFBiz - Dev mailing list archive at Nabble.com. -- I am hongs
Re: Some ideas for the future of the OFBiz
Hi Paul, and thank you for your feedback on Quartz. As regards the current job scheduler, there are a few issues that I often have to cope with in production, when the number of records in the JobSandbox grows over a certain limit (due to high load or to some failing job that is executed over and over); you can end up with db lock errors on the JobSandbox and the implementation of the service that cleans the old job (purgeOldJobs) is not ideal; that service also makes use of the ServiceSemaphore entity in order to guarantee that no more than one job at the time is run and I have some concerns about the reliability of this approach (race conditions, stale data); some interesting threads are: http://ofbiz.135035.n4.nabble.com/Replace-JobManager-with-Quartz-Scheduler-td2999416.html http://ofbiz.135035.n4.nabble.com/Job-Manager-td4635496.html http://permalink.gmane.org/gmane.comp.java.ofbiz.user/34131 On the other hand, the OFBiz job scheduler is used a lot and so it is tested every day in many production instances and, despite of some problems (some of them mentioned above), as you said, it just works. For this reason I agree that we should evaluate this (and similar other proposed in my first email) changes carefully before taking a decision. Kind regards, Jacopo On Mar 22, 2013, at 12:26 AM, Paul Piper p...@ilscipio.com wrote: I have worked with Quartz before - it is a fantastic solution, so I'd also second that opinion of implementing Quartz as a replacement for the job scheduler. The only point that would speak against it, is that I haven't really had any issues with the current scheduler, so a replacement may not be necessary and should be discussed whether it is a worthwhile venture. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4639968.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas for the future of the OFBiz
we could also add to the list: * Java 7 Jacopo On Mar 22, 2013, at 3:43 AM, hongs bill billho...@gmail.com wrote: +1 add workflow engine,such as jBPM or Activiti . -- I am hongs
Re: Some ideas for the future of the OFBiz
I overhauled the Job Scheduler, so many of the problems you listed don't exist anymore. -Adrian On 3/22/2013 6:32 AM, Jacopo Cappellato wrote: Hi Paul, and thank you for your feedback on Quartz. As regards the current job scheduler, there are a few issues that I often have to cope with in production, when the number of records in the JobSandbox grows over a certain limit (due to high load or to some failing job that is executed over and over); you can end up with db lock errors on the JobSandbox and the implementation of the service that cleans the old job (purgeOldJobs) is not ideal; that service also makes use of the ServiceSemaphore entity in order to guarantee that no more than one job at the time is run and I have some concerns about the reliability of this approach (race conditions, stale data); some interesting threads are: http://ofbiz.135035.n4.nabble.com/Replace-JobManager-with-Quartz-Scheduler-td2999416.html http://ofbiz.135035.n4.nabble.com/Job-Manager-td4635496.html http://permalink.gmane.org/gmane.comp.java.ofbiz.user/34131 On the other hand, the OFBiz job scheduler is used a lot and so it is tested every day in many production instances and, despite of some problems (some of them mentioned above), as you said, it just works. For this reason I agree that we should evaluate this (and similar other proposed in my first email) changes carefully before taking a decision. Kind regards, Jacopo On Mar 22, 2013, at 12:26 AM, Paul Piper p...@ilscipio.com wrote: I have worked with Quartz before - it is a fantastic solution, so I'd also second that opinion of implementing Quartz as a replacement for the job scheduler. The only point that would speak against it, is that I haven't really had any issues with the current scheduler, so a replacement may not be necessary and should be discussed whether it is a worthwhile venture. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4639968.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas for the future of the OFBiz
I also crossed issues but using something near R11.04. I believe it's better now, but did not use it in production Jacques From: Adrian Crum adrian.c...@sandglass-software.com I overhauled the Job Scheduler, so many of the problems you listed don't exist anymore. -Adrian On 3/22/2013 6:32 AM, Jacopo Cappellato wrote: Hi Paul, and thank you for your feedback on Quartz. As regards the current job scheduler, there are a few issues that I often have to cope with in production, when the number of records in the JobSandbox grows over a certain limit (due to high load or to some failing job that is executed over and over); you can end up with db lock errors on the JobSandbox and the implementation of the service that cleans the old job (purgeOldJobs) is not ideal; that service also makes use of the ServiceSemaphore entity in order to guarantee that no more than one job at the time is run and I have some concerns about the reliability of this approach (race conditions, stale data); some interesting threads are: http://ofbiz.135035.n4.nabble.com/Replace-JobManager-with-Quartz-Scheduler-td2999416.html http://ofbiz.135035.n4.nabble.com/Job-Manager-td4635496.html http://permalink.gmane.org/gmane.comp.java.ofbiz.user/34131 On the other hand, the OFBiz job scheduler is used a lot and so it is tested every day in many production instances and, despite of some problems (some of them mentioned above), as you said, it just works. For this reason I agree that we should evaluate this (and similar other proposed in my first email) changes carefully before taking a decision. Kind regards, Jacopo On Mar 22, 2013, at 12:26 AM, Paul Piper p...@ilscipio.com wrote: I have worked with Quartz before - it is a fantastic solution, so I'd also second that opinion of implementing Quartz as a replacement for the job scheduler. The only point that would speak against it, is that I haven't really had any issues with the current scheduler, so a replacement may not be necessary and should be discussed whether it is a worthwhile venture. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4639968.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas for the future of the OFBiz
+1 Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com we could also add to the list: * Java 7 Jacopo On Mar 22, 2013, at 3:43 AM, hongs bill billho...@gmail.com wrote: +1 add workflow engine,such as jBPM or Activiti . -- I am hongs
Re: Some ideas for the future of the OFBiz
Hi Jacopo, I plenty agree on all, but the last point, where I have to review and check As you suggested for DBCP, having both for each point (ie DBCP or Atomikos, OFBiz Security or Shiro, etc.) at hand for a while would be a wise solution. I mean having both of them ready to use, not to have to get your hand dirty... Cheers Jacques From: Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com 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
Re: Some ideas for the future of the OFBiz
OFBiz Job scheduler is performing very well on Release 11.04. Last year we have faced problem in two production system due to too much traffic and most of the scheduled service were running at MID_NIGHT. This was keeping server too much busy at that time and then we were seeing downtime once or twice in a week. To fix this problem we have rescheduled most of the service times so now all the services runs at the interval of 15 minutes. Today I did get a chance to read details available on Quartz and I think it can be better option then the existing Job Scheduler. Thanks! -- Kind Regards Ashish Vijaywargiya HotWax Media - est. 1997 ApacheCon US 2013 Gold Sponsor http://na.apachecon.com/sponsors/ On Friday 22 March 2013 12:02 PM, Jacopo Cappellato wrote: On the other hand, the OFBiz job scheduler is used a lot and so it is tested every day in many production instances and, despite of some problems (some of them mentioned above), as you said, it just works. For this reason I agree that we should evaluate this (and similar other proposed in my first email) changes carefully before taking a decision. smime.p7s Description: S/MIME Cryptographic Signature
Re: Some ideas for the future of the OFBiz
Hi Jacopo, looks nice ! Cheers, 2013/3/21 Jacopo Cappellato jacopo.cappell...@hotwaxmedia.com 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
Re: Some ideas for the future of the OFBiz
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 e...@brainfood.com 214-720-0700 x 315 Brainfood, Inc. http://www.brainfood.com
Re: Some ideas for the future of the OFBiz
On 3/21/2013 10:57 AM, 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 +1 This was suggested years ago. See https://cwiki.apache.org/confluence/display/OFBTECH/OFBiz+Security+Redesign * Replace Javolution (this has been already discussed in the past) +1 * Replace the OFBiz cache system with: http://ehcache.org +1 * 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
Re: Some ideas for the future of the OFBiz
I have worked with Quartz before - it is a fantastic solution, so I'd also second that opinion of implementing Quartz as a replacement for the job scheduler. The only point that would speak against it, is that I haven't really had any issues with the current scheduler, so a replacement may not be necessary and should be discussed whether it is a worthwhile venture. -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4639968.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
Re: Some ideas for the future of the OFBiz
+1 add workflow engine,such as jBPM or Activiti . -- I am hongs
