You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2013/03/21 11:57:36 UTC
Some ideas for the future of the OFBiz
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
Posted by Ashish Vijaywargiya <as...@hotwaxmedia.com>.
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.
Re: Some ideas for the future of the OFBiz
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ad...@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 <pp...@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
Posted by Adrian Crum <ad...@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 <pp...@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
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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 <pp...@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
Posted by hongs bill <bi...@gmail.com>.
jBPM or Activiti is licensed under the Apache License 2.0.
They are more popular than shark.
2013/3/25 Paul Foxworthy <pa...@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
Posted by Paul Foxworthy <pa...@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.
Re: Some ideas for the future of the OFBiz
Posted by Jacques Le Roux <ja...@les7arts.com>.
+1
Jacques
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> we could also add to the list:
>
> * Java 7
>
> Jacopo
>
>
> On Mar 22, 2013, at 3:43 AM, hongs bill <bi...@gmail.com> wrote:
>
>> +1
>>
>> add workflow engine,such as jBPM or Activiti .
>>
>>
>> --
>> I am hongs
>
Re: Some ideas for the future of the OFBiz
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
we could also add to the list:
* Java 7
Jacopo
On Mar 22, 2013, at 3:43 AM, hongs bill <bi...@gmail.com> wrote:
> +1
>
> add workflow engine,such as jBPM or Activiti .
>
>
> --
> I am hongs
Re: Some ideas for the future of the OFBiz
Posted by hongs bill <bi...@gmail.com>.
+1
add workflow engine,such as jBPM or Activiti .
--
I am hongs
Re: Some ideas for the future of the OFBiz
Posted by Paul Piper <pp...@ilscipio.com>.
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
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
Posted by Erwan de FERRIERES <er...@gmail.com>.
Hi Jacopo,
looks nice !
Cheers,
2013/3/21 Jacopo Cappellato <ja...@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
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
+1
On Mar 28, 2013, at 6:22 PM, Adrian Crum <ad...@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
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
Posted by Nicolas Malin <ma...@librenberry.net>.
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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <ja...@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
Posted by Medhat <me...@gmail.com>.
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
Posted by Erwan de FERRIERES <er...@gmail.com>.
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 <ea...@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
> ean@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
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
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
Posted by Ean Schuessler <ea...@brainfood.com>.
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@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com
Re: Some ideas for the future of the OFBiz
Posted by Paul Foxworthy <pa...@cohsoft.com.au>.
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
Posted by Ean Schuessler <ea...@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
ean@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com