My vision for the OFBiz Framework

[David E. Jones-2]

I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today):

http://www.moqui.org/

The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0.

At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more).

Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project.

However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far.

Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it.

On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such.

-David

[hans_bakker]

Hi David,

woow what an achievement, I am always interested in further developments
of the ofbiz project and see this as a further step. You can count me in
for the applications side of things.

Regards,
Hans

On Sat, 2011-04-02 at 00:09 -0600, David E Jones wrote:

> I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today):
>
> http://www.moqui.org/
>
> The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0.
>
> At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more).
>
> Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project.
>
> However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far.
>
> Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it.
>
> On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such.
>
> -David
>
>

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Myself on twitter: http://twitter.com/hansbak
Antwebsystems.com: Quality services for competitive rates.

[Adrian Crum-3]

Based on the previous discussion we had on this subject, I would suggest
we create an 11.x branch, and then start discussing a road map for
porting the changes from Moqui to OFBiz. I hope to be available to help
in November.

-Adrian


On 4/1/2011 11:09 PM, David E Jones wrote:

> I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today):
>
> http://www.moqui.org/
>
> The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0.
>
> At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more).
>
> Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project.
>
> However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far.
>
> Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it.
>
> On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such.
>
> -David
>
>

[Brett]

David,

We are interested in this project.  Let us know the best way to start
playing with the framework and see how we could use it.  We do a lot of
custom applications and moqui sounds like a framework that could be used for
this.


Thanks again for your efforts.


Brett

On Sat, Apr 2, 2011 at 12:09 AM, David E Jones <[hidden email]> wrote:

>
> I still don't know if or how all of this will turn out, but here is the
> latest on the changes I've been wanting to make in the OFBiz Framework, but
> gave up on doing directly in OFBiz about a year and a half ago. The
> redesigned framework is a separate project that is now in beta (I just did
> the release today):
>
> http://www.moqui.org/
>
> The Moqui Framework is now feature-complete for the planned feature set of
> the 1.0 version. There are details about this in the release notes,
> including everything in this release and the previous 3 releases, plus a
> list of features not to be included in 1.0.
>
> At this point the framework is far enough along that it is a clear
> demonstration of the changes that I would like to see in OFBiz, but that are
> difficult to do in a project with such a mature community and a large set of
> software that depends on it. Some of the main things are how the security
> and authorization are done, how the API is organized, the separation between
> framework and non-framework runtime artifacts, the deployment model
> (described in detail in the RunDeploy.txt file in the project), the way
> templates are used for simple-methods (XML Actions in Moqui) and the
> form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web
> "controller" in OFBiz could be combined with screens and made hierarchical
> to introduce a lot of flexibility and far better organization of
> applications (less files open, easier to find things, automatic menu
> creation, per-used menu items/subscreens, and much more).
>
> Now that the beta is out the next step is to start building more real-world
> applications with it (so far the framework just has an example app and some
> basic tools built on it), and those will act as test cases as well. I don't
> have any intention to create another project like OFBiz that is a
> comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will
> be separate project.
>
> However, I am working on a project to act as a basis for various
> applications that will share the same data model, common services, and
> derive from a common set of stories too. This project is called "Mantle". To
> see how this all fits together, check out the home page on the moqui.orgsite which has a diagram that includes these things. There is also a link to
> the github repository that has the Mantle UDM (Universal Data Model)
> progress so far.
>
> Back to the first comment: I don't know all of this will turn out. In a way
> it would be interesting to have OFBiz migrate to use these things, but that
> may not be of interest to very many in the community, so I won't be too
> surprised if that never happens. I've already heard from a couple of people
> who have proposed this idea, and I know some others would probably be very
> against it.
>
> On the other hand, if anyone is curious about such a thing, now it's
> possible to get an idea of what it might look like by look at the Moqui
> Framework and the example application and such.
>
> -David
>
>
>

[David E. Jones-2]

That is a good question. The best way to get an idea of how things would look is to look at the example component (in runtime/component/example), the configuration files (default: framework/api/conf-default/MoquiDefaultConf.xml, environment-specific: runtime/conf/...), and the interface definitions for the API (framework/api/src/org/moqui/...).

I'm working on a document now that describes the different parts of the framework and how the API is organized ("Introduction to Moqui Framework") and hopefully I'll have that posted this weekend.

-David


On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote:

> David,
>
> We are interested in this project.  Let us know the best way to start
> playing with the framework and see how we could use it.  We do a lot of
> custom applications and moqui sounds like a framework that could be used for
> this.
>
>
> Thanks again for your efforts.
>
>
> Brett
>
> On Sat, Apr 2, 2011 at 12:09 AM, David E Jones <[hidden email]> wrote:
>
>>
>> I still don't know if or how all of this will turn out, but here is the
>> latest on the changes I've been wanting to make in the OFBiz Framework, but
>> gave up on doing directly in OFBiz about a year and a half ago. The
>> redesigned framework is a separate project that is now in beta (I just did
>> the release today):
>>
>> http://www.moqui.org/
>>
>> The Moqui Framework is now feature-complete for the planned feature set of
>> the 1.0 version. There are details about this in the release notes,
>> including everything in this release and the previous 3 releases, plus a
>> list of features not to be included in 1.0.
>>
>> At this point the framework is far enough along that it is a clear
>> demonstration of the changes that I would like to see in OFBiz, but that are
>> difficult to do in a project with such a mature community and a large set of
>> software that depends on it. Some of the main things are how the security
>> and authorization are done, how the API is organized, the separation between
>> framework and non-framework runtime artifacts, the deployment model
>> (described in detail in the RunDeploy.txt file in the project), the way
>> templates are used for simple-methods (XML Actions in Moqui) and the
>> form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web
>> "controller" in OFBiz could be combined with screens and made hierarchical
>> to introduce a lot of flexibility and far better organization of
>> applications (less files open, easier to find things, automatic menu
>> creation, per-used menu items/subscreens, and much more).
>>
>> Now that the beta is out the next step is to start building more real-world
>> applications with it (so far the framework just has an example app and some
>> basic tools built on it), and those will act as test cases as well. I don't
>> have any intention to create another project like OFBiz that is a
>> comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will
>> be separate project.
>>
>> However, I am working on a project to act as a basis for various
>> applications that will share the same data model, common services, and
>> derive from a common set of stories too. This project is called "Mantle". To
>> see how this all fits together, check out the home page on the moqui.orgsite which has a diagram that includes these things. There is also a link to
>> the github repository that has the Mantle UDM (Universal Data Model)
>> progress so far.
>>
>> Back to the first comment: I don't know all of this will turn out. In a way
>> it would be interesting to have OFBiz migrate to use these things, but that
>> may not be of interest to very many in the community, so I won't be too
>> surprised if that never happens. I've already heard from a couple of people
>> who have proposed this idea, and I know some others would probably be very
>> against it.
>>
>> On the other hand, if anyone is curious about such a thing, now it's
>> possible to get an idea of what it might look like by look at the Moqui
>> Framework and the example application and such.
>>
>> -David
>>
>>
>>

[David E. Jones-2]

Adrian,

Just to see if I understand correctly what you wrote: are you proposing to make changes to the OFBiz Framework using code and ideas from the Moqui Framework?

If so, why not just migrate to use Moqui Framework?

-David


On Apr 2, 2011, at 10:15 AM, Adrian Crum wrote:

> Based on the previous discussion we had on this subject, I would suggest we create an 11.x branch, and then start discussing a road map for porting the changes from Moqui to OFBiz. I hope to be available to help in November.
>
> -Adrian
>
>
> On 4/1/2011 11:09 PM, David E Jones wrote:
>> I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today):
>>
>> http://www.moqui.org/
>>
>> The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0.
>>
>> At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more).
>>
>> Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project.
>>
>> However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far.
>>
>> Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it.
>>
>> On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such.
>>
>> -David
>>
>>
>

[Adrian Crum-3]

What does "migrate to use Moqui Framework" mean? Maybe I'm not
understanding what you're proposing.

-Adrian

On 4/2/2011 11:18 AM, David E Jones wrote:

> Adrian,
>
> Just to see if I understand correctly what you wrote: are you proposing to make changes to the OFBiz Framework using code and ideas from the Moqui Framework?
>
> If so, why not just migrate to use Moqui Framework?
>
> -David
>
>
> On Apr 2, 2011, at 10:15 AM, Adrian Crum wrote:
>
>> Based on the previous discussion we had on this subject, I would suggest we create an 11.x branch, and then start discussing a road map for porting the changes from Moqui to OFBiz. I hope to be available to help in November.
>>
>> -Adrian
>>
>>
>> On 4/1/2011 11:09 PM, David E Jones wrote:
>>> I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today):
>>>
>>> http://www.moqui.org/
>>>
>>> The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0.
>>>
>>> At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more).
>>>
>>> Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project.
>>>
>>> However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far.
>>>
>>> Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it.
>>>
>>> On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such.
>>>
>>> -David
>>>
>>>

[David E. Jones-2]

What I mean is throw out the OFBiz Framework and migrate the applications and specialpurpose components to run on Moqui Framework, and perhaps even incorporate the Mantle stuff too (mostly UDM, USL).

After that OFBiz would be the applications project it was meant to be originally, as opposed to the framework + applications that is became out of necessity.

-David


On Apr 2, 2011, at 12:21 PM, Adrian Crum wrote:

> What does "migrate to use Moqui Framework" mean? Maybe I'm not understanding what you're proposing.
>
> -Adrian
>
> On 4/2/2011 11:18 AM, David E Jones wrote:
>> Adrian,
>>
>> Just to see if I understand correctly what you wrote: are you proposing to make changes to the OFBiz Framework using code and ideas from the Moqui Framework?
>>
>> If so, why not just migrate to use Moqui Framework?
>>
>> -David
>>
>>
>> On Apr 2, 2011, at 10:15 AM, Adrian Crum wrote:
>>
>>> Based on the previous discussion we had on this subject, I would suggest we create an 11.x branch, and then start discussing a road map for porting the changes from Moqui to OFBiz. I hope to be available to help in November.
>>>
>>> -Adrian
>>>
>>>
>>> On 4/1/2011 11:09 PM, David E Jones wrote:
>>>> I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today):
>>>>
>>>> http://www.moqui.org/
>>>>
>>>> The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0.
>>>>
>>>> At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more).
>>>>
>>>> Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project.
>>>>
>>>> However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far.
>>>>
>>>> Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it.
>>>>
>>>> On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such.
>>>>
>>>> -David
>>>>
>>>>
>

[Adrian Crum-3]

I agree 100% with the end result - OFBiz running on a separate
application framework. The question is: How do we get from here to
there? That is what my original reply was trying to address.

One other thing to keep in mind during this discussion: The Moqui
framework is under the control of a single person, and possibly in the
future, a small group of committers. Will the Moqui community have the
necessary resources to support OFBiz once a commitment is made to use it
instead of our own framework?

-Adrian

On 4/2/2011 11:28 AM, David E Jones wrote:

> What I mean is throw out the OFBiz Framework and migrate the applications and specialpurpose components to run on Moqui Framework, and perhaps even incorporate the Mantle stuff too (mostly UDM, USL).
>
> After that OFBiz would be the applications project it was meant to be originally, as opposed to the framework + applications that is became out of necessity.
>
> -David
>
>
> On Apr 2, 2011, at 12:21 PM, Adrian Crum wrote:
>
>> What does "migrate to use Moqui Framework" mean? Maybe I'm not understanding what you're proposing.
>>
>> -Adrian
>>
>> On 4/2/2011 11:18 AM, David E Jones wrote:
>>> Adrian,
>>>
>>> Just to see if I understand correctly what you wrote: are you proposing to make changes to the OFBiz Framework using code and ideas from the Moqui Framework?
>>>
>>> If so, why not just migrate to use Moqui Framework?
>>>
>>> -David
>>>
>>>
>>> On Apr 2, 2011, at 10:15 AM, Adrian Crum wrote:
>>>
>>>> Based on the previous discussion we had on this subject, I would suggest we create an 11.x branch, and then start discussing a road map for porting the changes from Moqui to OFBiz. I hope to be available to help in November.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 4/1/2011 11:09 PM, David E Jones wrote:
>>>>> I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today):
>>>>>
>>>>> http://www.moqui.org/
>>>>>
>>>>> The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0.
>>>>>
>>>>> At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more).
>>>>>
>>>>> Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project.
>>>>>
>>>>> However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far.
>>>>>
>>>>> Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it.
>>>>>
>>>>> On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such.
>>>>>
>>>>> -David
>>>>>
>>>>>

[David E. Jones-2]

On Apr 2, 2011, at 12:39 PM, Adrian Crum wrote:

> I agree 100% with the end result - OFBiz running on a separate application framework. The question is: How do we get from here to there? That is what my original reply was trying to address.

That is the real trick isn't it... The idea of creating release branch and then working in the trunk to start migrating to Moqui is an interesting one. The fastest route to the migration would involve basically allowing much of it to be broken rather than trying to juggle both frameworks as application artifacts are migrated from one to the other. However, if we do that then the trunk wouldn't be reliable at all and groups with more immediate needs would simply not be able to use it.

Maybe the project is mature enough now that a stable release branch would be adequate for many users and the community behind the framework migration could work independently of that.

Another option would be to create a "fork". That would allow the current OFBiz on the current OFBiz Framework to continue under development by those interested, and for those interested in a migrating to the Moqui Framework they could do it as a separate project without worrying about the legacy and backward compatibility issues, and ensuring proper functioning (which would allow for a more traditional develop and release model too, so it could go through normal alpha/beta/RC/etc cycles).

The better way, I don't know... I guess it depends on how many in the community fall into each camp (needing something continuable workable to base their efforts on, versus being able to work on something that won't be ready for at least a number of months).

> One other thing to keep in mind during this discussion: The Moqui framework is under the control of a single person, and possibly in the future, a small group of committers. Will the Moqui community have the necessary resources to support OFBiz once a commitment is made to use it instead of our own framework?

That is correct, it is a separate project with a different management and resource model. There are currently around 100 such libraries in OFBiz, and by size Moqui Framework wouldn't be the biggest. There would be dramatic dependencies on it of course, and I guess that's where your concern is based.

As fas as support goes, those involved with Moqui don't need to support OFBiz or the OFBiz community, they just need to support the Moqui Framework. It's functionality that needs to be supported in this case, not people. Because of the more traditional release cycle of Moqui Framework, and because it has a well-defined scope, it should be used as-is and upgraded periodically just like any other library.

Chances are OFBiz would benefit from a different build and deploy model than the default Moqui one, and probably different screen/form output templates (perhaps even a different XML Actions output template), and possibly even additional resource referencers, template renderers, script runners, etc. But, that is all external to the Moqui Framework.

Anyway, the point is that bug-fixing will be the primary need for the OFBiz Community, and that is the need for all other Moqui Framework users as well.

On a side note, there is a great benefit to OFBiz in using an external framework in that the development model changes from all sorts of random changes going into the framework as needed to a more defined and thought out change process to preserve a more generic and flexible set of tools. I don't think there is any way you can get that benefit without the clear segregation between both the projects and the communities behind them.

-David

>
> -Adrian
>
> On 4/2/2011 11:28 AM, David E Jones wrote:
>> What I mean is throw out the OFBiz Framework and migrate the applications and specialpurpose components to run on Moqui Framework, and perhaps even incorporate the Mantle stuff too (mostly UDM, USL).
>>
>> After that OFBiz would be the applications project it was meant to be originally, as opposed to the framework + applications that is became out of necessity.
>>
>> -David
>>
>>
>> On Apr 2, 2011, at 12:21 PM, Adrian Crum wrote:
>>
>>> What does "migrate to use Moqui Framework" mean? Maybe I'm not understanding what you're proposing.
>>>
>>> -Adrian
>>>
>>> On 4/2/2011 11:18 AM, David E Jones wrote:
>>>> Adrian,
>>>>
>>>> Just to see if I understand correctly what you wrote: are you proposing to make changes to the OFBiz Framework using code and ideas from the Moqui Framework?
>>>>
>>>> If so, why not just migrate to use Moqui Framework?
>>>>
>>>> -David
>>>>
>>>>
>>>> On Apr 2, 2011, at 10:15 AM, Adrian Crum wrote:
>>>>
>>>>> Based on the previous discussion we had on this subject, I would suggest we create an 11.x branch, and then start discussing a road map for porting the changes from Moqui to OFBiz. I hope to be available to help in November.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 4/1/2011 11:09 PM, David E Jones wrote:
>>>>>> I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today):
>>>>>>
>>>>>> http://www.moqui.org/
>>>>>>
>>>>>> The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0.
>>>>>>
>>>>>> At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more).
>>>>>>
>>>>>> Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project.
>>>>>>
>>>>>> However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far.
>>>>>>
>>>>>> Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it.
>>>>>>
>>>>>> On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>

[Adrian Crum-3]

I don't agree that a separate project is necessary to get a well defined
application framework in OFBiz. We could achieve that in OFBiz if we
could get everyone to agree on what an "application framework" is. Once
that is defined, then it can be enforced - the same as it is with Moqui.

-Adrian


On 4/2/2011 12:53 PM, David E Jones wrote:

> On Apr 2, 2011, at 12:39 PM, Adrian Crum wrote:
>
>> I agree 100% with the end result - OFBiz running on a separate application framework. The question is: How do we get from here to there? That is what my original reply was trying to address.
> That is the real trick isn't it... The idea of creating release branch and then working in the trunk to start migrating to Moqui is an interesting one. The fastest route to the migration would involve basically allowing much of it to be broken rather than trying to juggle both frameworks as application artifacts are migrated from one to the other. However, if we do that then the trunk wouldn't be reliable at all and groups with more immediate needs would simply not be able to use it.
>
> Maybe the project is mature enough now that a stable release branch would be adequate for many users and the community behind the framework migration could work independently of that.
>
> Another option would be to create a "fork". That would allow the current OFBiz on the current OFBiz Framework to continue under development by those interested, and for those interested in a migrating to the Moqui Framework they could do it as a separate project without worrying about the legacy and backward compatibility issues, and ensuring proper functioning (which would allow for a more traditional develop and release model too, so it could go through normal alpha/beta/RC/etc cycles).
>
> The better way, I don't know... I guess it depends on how many in the community fall into each camp (needing something continuable workable to base their efforts on, versus being able to work on something that won't be ready for at least a number of months).
>
>> One other thing to keep in mind during this discussion: The Moqui framework is under the control of a single person, and possibly in the future, a small group of committers. Will the Moqui community have the necessary resources to support OFBiz once a commitment is made to use it instead of our own framework?
> That is correct, it is a separate project with a different management and resource model. There are currently around 100 such libraries in OFBiz, and by size Moqui Framework wouldn't be the biggest. There would be dramatic dependencies on it of course, and I guess that's where your concern is based.
>
> As fas as support goes, those involved with Moqui don't need to support OFBiz or the OFBiz community, they just need to support the Moqui Framework. It's functionality that needs to be supported in this case, not people. Because of the more traditional release cycle of Moqui Framework, and because it has a well-defined scope, it should be used as-is and upgraded periodically just like any other library.
>
> Chances are OFBiz would benefit from a different build and deploy model than the default Moqui one, and probably different screen/form output templates (perhaps even a different XML Actions output template), and possibly even additional resource referencers, template renderers, script runners, etc. But, that is all external to the Moqui Framework.
>
> Anyway, the point is that bug-fixing will be the primary need for the OFBiz Community, and that is the need for all other Moqui Framework users as well.
>
> On a side note, there is a great benefit to OFBiz in using an external framework in that the development model changes from all sorts of random changes going into the framework as needed to a more defined and thought out change process to preserve a more generic and flexible set of tools. I don't think there is any way you can get that benefit without the clear segregation between both the projects and the communities behind them.
>
> -David
>
>
>> -Adrian
>>
>> On 4/2/2011 11:28 AM, David E Jones wrote:
>>> What I mean is throw out the OFBiz Framework and migrate the applications and specialpurpose components to run on Moqui Framework, and perhaps even incorporate the Mantle stuff too (mostly UDM, USL).
>>>
>>> After that OFBiz would be the applications project it was meant to be originally, as opposed to the framework + applications that is became out of necessity.
>>>
>>> -David
>>>
>>>
>>> On Apr 2, 2011, at 12:21 PM, Adrian Crum wrote:
>>>
>>>> What does "migrate to use Moqui Framework" mean? Maybe I'm not understanding what you're proposing.
>>>>
>>>> -Adrian
>>>>
>>>> On 4/2/2011 11:18 AM, David E Jones wrote:
>>>>> Adrian,
>>>>>
>>>>> Just to see if I understand correctly what you wrote: are you proposing to make changes to the OFBiz Framework using code and ideas from the Moqui Framework?
>>>>>
>>>>> If so, why not just migrate to use Moqui Framework?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Apr 2, 2011, at 10:15 AM, Adrian Crum wrote:
>>>>>
>>>>>> Based on the previous discussion we had on this subject, I would suggest we create an 11.x branch, and then start discussing a road map for porting the changes from Moqui to OFBiz. I hope to be available to help in November.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 4/1/2011 11:09 PM, David E Jones wrote:
>>>>>>> I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today):
>>>>>>>
>>>>>>> http://www.moqui.org/
>>>>>>>
>>>>>>> The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0.
>>>>>>>
>>>>>>> At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more).
>>>>>>>
>>>>>>> Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project.
>>>>>>>
>>>>>>> However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far.
>>>>>>>
>>>>>>> Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it.
>>>>>>>
>>>>>>> On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>

[David E. Jones-2]

The "Introduction to Moqui Framework" document is now ready and available do download through SourceForge:

https://sourceforge.net/projects/moqui/files/

This document is meant for application developers, ie for the same people who would use Moqui. It is 12 pages with 2 diagrams and should be a quick read, but describes where everything is in the framework and from a high level how to do various things.

BTW, feedback on this document and on the framework itself would both be most helpful...

-David


On Apr 2, 2011, at 12:17 PM, David E Jones wrote:

>
> That is a good question. The best way to get an idea of how things would look is to look at the example component (in runtime/component/example), the configuration files (default: framework/api/conf-default/MoquiDefaultConf.xml, environment-specific: runtime/conf/...), and the interface definitions for the API (framework/api/src/org/moqui/...).
>
> I'm working on a document now that describes the different parts of the framework and how the API is organized ("Introduction to Moqui Framework") and hopefully I'll have that posted this weekend.
>
> -David
>
>
> On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote:
>
>> David,
>>
>> We are interested in this project.  Let us know the best way to start
>> playing with the framework and see how we could use it.  We do a lot of
>> custom applications and moqui sounds like a framework that could be used for
>> this.
>>
>>
>> Thanks again for your efforts.
>>
>>
>> Brett
>>
>> On Sat, Apr 2, 2011 at 12:09 AM, David E Jones <[hidden email]> wrote:
>>
>>>
>>> I still don't know if or how all of this will turn out, but here is the
>>> latest on the changes I've been wanting to make in the OFBiz Framework, but
>>> gave up on doing directly in OFBiz about a year and a half ago. The
>>> redesigned framework is a separate project that is now in beta (I just did
>>> the release today):
>>>
>>> http://www.moqui.org/
>>>
>>> The Moqui Framework is now feature-complete for the planned feature set of
>>> the 1.0 version. There are details about this in the release notes,
>>> including everything in this release and the previous 3 releases, plus a
>>> list of features not to be included in 1.0.
>>>
>>> At this point the framework is far enough along that it is a clear
>>> demonstration of the changes that I would like to see in OFBiz, but that are
>>> difficult to do in a project with such a mature community and a large set of
>>> software that depends on it. Some of the main things are how the security
>>> and authorization are done, how the API is organized, the separation between
>>> framework and non-framework runtime artifacts, the deployment model
>>> (described in detail in the RunDeploy.txt file in the project), the way
>>> templates are used for simple-methods (XML Actions in Moqui) and the
>>> form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web
>>> "controller" in OFBiz could be combined with screens and made hierarchical
>>> to introduce a lot of flexibility and far better organization of
>>> applications (less files open, easier to find things, automatic menu
>>> creation, per-used menu items/subscreens, and much more).
>>>
>>> Now that the beta is out the next step is to start building more real-world
>>> applications with it (so far the framework just has an example app and some
>>> basic tools built on it), and those will act as test cases as well. I don't
>>> have any intention to create another project like OFBiz that is a
>>> comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will
>>> be separate project.
>>>
>>> However, I am working on a project to act as a basis for various
>>> applications that will share the same data model, common services, and
>>> derive from a common set of stories too. This project is called "Mantle". To
>>> see how this all fits together, check out the home page on the moqui.orgsite which has a diagram that includes these things. There is also a link to
>>> the github repository that has the Mantle UDM (Universal Data Model)
>>> progress so far.
>>>
>>> Back to the first comment: I don't know all of this will turn out. In a way
>>> it would be interesting to have OFBiz migrate to use these things, but that
>>> may not be of interest to very many in the community, so I won't be too
>>> surprised if that never happens. I've already heard from a couple of people
>>> who have proposed this idea, and I know some others would probably be very
>>> against it.
>>>
>>> On the other hand, if anyone is curious about such a thing, now it's
>>> possible to get an idea of what it might look like by look at the Moqui
>>> Framework and the example application and such.
>>>
>>> -David
>>>
>>>
>>>
>

[samhamilton]

Hi David,

Congats on the beta release!

You were asking for feature requests and today I ran across a java framework called Play they have a few of things that might be interesting:
- they get their framework to compile java sources directly and then hot-reloads the JVM [1]
- their logging seems to be very clear and would speed up bug finding [1] [2]
- they have a module repo to specify third party hosted module repos [3]

[1] - http://www.playframework.org/documentation/1.1.1/overview
[2] - http://www.playframework.org/documentation/1.1.1/usability#aBetterusabilityisnotjustfornormalpeoplea
[3] - http://www.playframework.org/documentation/1.1.1/modules#repository

Sam


On 3 Apr 2011, at 12:57, David E Jones wrote:

>
> The "Introduction to Moqui Framework" document is now ready and available do download through SourceForge:
>
> https://sourceforge.net/projects/moqui/files/
>
> This document is meant for application developers, ie for the same people who would use Moqui. It is 12 pages with 2 diagrams and should be a quick read, but describes where everything is in the framework and from a high level how to do various things.
>
> BTW, feedback on this document and on the framework itself would both be most helpful...
>
> -David
>
>
> On Apr 2, 2011, at 12:17 PM, David E Jones wrote:
>
>>
>> That is a good question. The best way to get an idea of how things would look is to look at the example component (in runtime/component/example), the configuration files (default: framework/api/conf-default/MoquiDefaultConf.xml, environment-specific: runtime/conf/...), and the interface definitions for the API (framework/api/src/org/moqui/...).
>>
>> I'm working on a document now that describes the different parts of the framework and how the API is organized ("Introduction to Moqui Framework") and hopefully I'll have that posted this weekend.
>>
>> -David
>>
>>
>> On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote:
>>
>>> David,
>>>
>>> We are interested in this project.  Let us know the best way to start
>>> playing with the framework and see how we could use it.  We do a lot of
>>> custom applications and moqui sounds like a framework that could be used for
>>> this.
>>>
>>>
>>> Thanks again for your efforts.
>>>
>>>
>>> Brett
>>>
>>> On Sat, Apr 2, 2011 at 12:09 AM, David E Jones <[hidden email]> wrote:
>>>
>>>>
>>>> I still don't know if or how all of this will turn out, but here is the
>>>> latest on the changes I've been wanting to make in the OFBiz Framework, but
>>>> gave up on doing directly in OFBiz about a year and a half ago. The
>>>> redesigned framework is a separate project that is now in beta (I just did
>>>> the release today):
>>>>
>>>> http://www.moqui.org/
>>>>
>>>> The Moqui Framework is now feature-complete for the planned feature set of
>>>> the 1.0 version. There are details about this in the release notes,
>>>> including everything in this release and the previous 3 releases, plus a
>>>> list of features not to be included in 1.0.
>>>>
>>>> At this point the framework is far enough along that it is a clear
>>>> demonstration of the changes that I would like to see in OFBiz, but that are
>>>> difficult to do in a project with such a mature community and a large set of
>>>> software that depends on it. Some of the main things are how the security
>>>> and authorization are done, how the API is organized, the separation between
>>>> framework and non-framework runtime artifacts, the deployment model
>>>> (described in detail in the RunDeploy.txt file in the project), the way
>>>> templates are used for simple-methods (XML Actions in Moqui) and the
>>>> form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web
>>>> "controller" in OFBiz could be combined with screens and made hierarchical
>>>> to introduce a lot of flexibility and far better organization of
>>>> applications (less files open, easier to find things, automatic menu
>>>> creation, per-used menu items/subscreens, and much more).
>>>>
>>>> Now that the beta is out the next step is to start building more real-world
>>>> applications with it (so far the framework just has an example app and some
>>>> basic tools built on it), and those will act as test cases as well. I don't
>>>> have any intention to create another project like OFBiz that is a
>>>> comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will
>>>> be separate project.
>>>>
>>>> However, I am working on a project to act as a basis for various
>>>> applications that will share the same data model, common services, and
>>>> derive from a common set of stories too. This project is called "Mantle". To
>>>> see how this all fits together, check out the home page on the moqui.orgsite which has a diagram that includes these things. There is also a link to
>>>> the github repository that has the Mantle UDM (Universal Data Model)
>>>> progress so far.
>>>>
>>>> Back to the first comment: I don't know all of this will turn out. In a way
>>>> it would be interesting to have OFBiz migrate to use these things, but that
>>>> may not be of interest to very many in the community, so I won't be too
>>>> surprised if that never happens. I've already heard from a couple of people
>>>> who have proposed this idea, and I know some others would probably be very
>>>> against it.
>>>>
>>>> On the other hand, if anyone is curious about such a thing, now it's
>>>> possible to get an idea of what it might look like by look at the Moqui
>>>> Framework and the example application and such.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>
>

[David E. Jones-2]

On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote:

> Hi David,
>
> Congats on the beta release!
>
> You were asking for feature requests and today I ran across a java framework called Play they have a few of things that might be interesting:
> - they get their framework to compile java sources directly and then hot-reloads the JVM [1]

Taking a quick look at things I wonder if they are using Groovy to treat ".java" files as ".groovy" files. In Moqui the recommendation is to just use Groovy anytime you need a script for a service or other things. Of course, Moqui isn't so Java-centric as it seems like Play is, so runtime reloading during development is more of an inherent part of the framework and recommended tools as opposed to something that has to be added.

> - their logging seems to be very clear and would speed up bug finding [1] [2]

Yes, that is interesting. In OFBiz this is a HUGE problem because there is so much use of the hideous log & rethrow pattern which results in the same, or very similar, stack trace being logged half a dozen times.

One thing I've noticed about the use of Groovy in Moqui is that they do a good job of putting locations of things like scriptlets (including screen actions, etc) in the stack trace. On the other hand, the stack traces are HUGE because of all of the groovy proxy calls and such, and I've thought about writing something to filter those out... just haven't done it yet.

I agree trimming out redundant stuff from the stack trace would be helpful, in addition to avoiding the redundant stack traces.

> - they have a module repo to specify third party hosted module repos [3]

I'd like to do this sooner or later with Moqui and list addons or plugins, plus a document about how to create them (I couldn't find a doc like that for Play, maybe I didn't look hard enough). That framework has various means of supporting this right now, but I like the idea of creating a page to list addons/plugins, even if it starts out empty... ;)

-David

>
> [1] - http://www.playframework.org/documentation/1.1.1/overview
> [2] - http://www.playframework.org/documentation/1.1.1/usability#aBetterusabilityisnotjustfornormalpeoplea
> [3] - http://www.playframework.org/documentation/1.1.1/modules#repository
>
> Sam
>
>
> On 3 Apr 2011, at 12:57, David E Jones wrote:
>
>>
>> The "Introduction to Moqui Framework" document is now ready and available do download through SourceForge:
>>
>> https://sourceforge.net/projects/moqui/files/
>>
>> This document is meant for application developers, ie for the same people who would use Moqui. It is 12 pages with 2 diagrams and should be a quick read, but describes where everything is in the framework and from a high level how to do various things.
>>
>> BTW, feedback on this document and on the framework itself would both be most helpful...
>>
>> -David
>>
>>
>> On Apr 2, 2011, at 12:17 PM, David E Jones wrote:
>>
>>>
>>> That is a good question. The best way to get an idea of how things would look is to look at the example component (in runtime/component/example), the configuration files (default: framework/api/conf-default/MoquiDefaultConf.xml, environment-specific: runtime/conf/...), and the interface definitions for the API (framework/api/src/org/moqui/...).
>>>
>>> I'm working on a document now that describes the different parts of the framework and how the API is organized ("Introduction to Moqui Framework") and hopefully I'll have that posted this weekend.
>>>
>>> -David
>>>
>>>
>>> On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote:
>>>
>>>> David,
>>>>
>>>> We are interested in this project.  Let us know the best way to start
>>>> playing with the framework and see how we could use it.  We do a lot of
>>>> custom applications and moqui sounds like a framework that could be used for
>>>> this.
>>>>
>>>>
>>>> Thanks again for your efforts.
>>>>
>>>>
>>>> Brett
>>>>
>>>> On Sat, Apr 2, 2011 at 12:09 AM, David E Jones <[hidden email]> wrote:
>>>>
>>>>>
>>>>> I still don't know if or how all of this will turn out, but here is the
>>>>> latest on the changes I've been wanting to make in the OFBiz Framework, but
>>>>> gave up on doing directly in OFBiz about a year and a half ago. The
>>>>> redesigned framework is a separate project that is now in beta (I just did
>>>>> the release today):
>>>>>
>>>>> http://www.moqui.org/
>>>>>
>>>>> The Moqui Framework is now feature-complete for the planned feature set of
>>>>> the 1.0 version. There are details about this in the release notes,
>>>>> including everything in this release and the previous 3 releases, plus a
>>>>> list of features not to be included in 1.0.
>>>>>
>>>>> At this point the framework is far enough along that it is a clear
>>>>> demonstration of the changes that I would like to see in OFBiz, but that are
>>>>> difficult to do in a project with such a mature community and a large set of
>>>>> software that depends on it. Some of the main things are how the security
>>>>> and authorization are done, how the API is organized, the separation between
>>>>> framework and non-framework runtime artifacts, the deployment model
>>>>> (described in detail in the RunDeploy.txt file in the project), the way
>>>>> templates are used for simple-methods (XML Actions in Moqui) and the
>>>>> form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web
>>>>> "controller" in OFBiz could be combined with screens and made hierarchical
>>>>> to introduce a lot of flexibility and far better organization of
>>>>> applications (less files open, easier to find things, automatic menu
>>>>> creation, per-used menu items/subscreens, and much more).
>>>>>
>>>>> Now that the beta is out the next step is to start building more real-world
>>>>> applications with it (so far the framework just has an example app and some
>>>>> basic tools built on it), and those will act as test cases as well. I don't
>>>>> have any intention to create another project like OFBiz that is a
>>>>> comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will
>>>>> be separate project.
>>>>>
>>>>> However, I am working on a project to act as a basis for various
>>>>> applications that will share the same data model, common services, and
>>>>> derive from a common set of stories too. This project is called "Mantle". To
>>>>> see how this all fits together, check out the home page on the moqui.orgsite which has a diagram that includes these things. There is also a link to
>>>>> the github repository that has the Mantle UDM (Universal Data Model)
>>>>> progress so far.
>>>>>
>>>>> Back to the first comment: I don't know all of this will turn out. In a way
>>>>> it would be interesting to have OFBiz migrate to use these things, but that
>>>>> may not be of interest to very many in the community, so I won't be too
>>>>> surprised if that never happens. I've already heard from a couple of people
>>>>> who have proposed this idea, and I know some others would probably be very
>>>>> against it.
>>>>>
>>>>> On the other hand, if anyone is curious about such a thing, now it's
>>>>> possible to get an idea of what it might look like by look at the Moqui
>>>>> Framework and the example application and such.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>
>>
>

[Bruno Busco]

Hi David,
I downloaded the beta and seen a great work!

Looks like we will have soon a very good option to the actual OFBiz
framework to think about.

BTW, I couldn't find any implementation or plans regarding a portal/portlet
feature.
Will the moqui framework include this, or what?

Regards,
Bruno

2011/4/5 David E Jones <[hidden email]>

>
> On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote:
>
> > Hi David,
> >
> > Congats on the beta release!
> >
> > You were asking for feature requests and today I ran across a java
> framework called Play they have a few of things that might be interesting:
> > - they get their framework to compile java sources directly and then
> hot-reloads the JVM [1]
>
> Taking a quick look at things I wonder if they are using Groovy to treat
> ".java" files as ".groovy" files. In Moqui the recommendation is to just use
> Groovy anytime you need a script for a service or other things. Of course,
> Moqui isn't so Java-centric as it seems like Play is, so runtime reloading
> during development is more of an inherent part of the framework and
> recommended tools as opposed to something that has to be added.
>
> > - their logging seems to be very clear and would speed up bug finding [1]
> [2]
>
> Yes, that is interesting. In OFBiz this is a HUGE problem because there is
> so much use of the hideous log & rethrow pattern which results in the same,
> or very similar, stack trace being logged half a dozen times.
>
> One thing I've noticed about the use of Groovy in Moqui is that they do a
> good job of putting locations of things like scriptlets (including screen
> actions, etc) in the stack trace. On the other hand, the stack traces are
> HUGE because of all of the groovy proxy calls and such, and I've thought
> about writing something to filter those out... just haven't done it yet.
>
> I agree trimming out redundant stuff from the stack trace would be helpful,
> in addition to avoiding the redundant stack traces.
>
> > - they have a module repo to specify third party hosted module repos [3]
>
> I'd like to do this sooner or later with Moqui and list addons or plugins,
> plus a document about how to create them (I couldn't find a doc like that
> for Play, maybe I didn't look hard enough). That framework has various means
> of supporting this right now, but I like the idea of creating a page to list
> addons/plugins, even if it starts out empty... ;)
>
> -David
>
>
>
> >
> > [1] - http://www.playframework.org/documentation/1.1.1/overview
> > [2] -
> http://www.playframework.org/documentation/1.1.1/usability#aBetterusabilityisnotjustfornormalpeoplea
> > [3] -
> http://www.playframework.org/documentation/1.1.1/modules#repository
> >
> > Sam
> >
> >
> > On 3 Apr 2011, at 12:57, David E Jones wrote:
> >
> >>
> >> The "Introduction to Moqui Framework" document is now ready and
> available do download through SourceForge:
> >>
> >> https://sourceforge.net/projects/moqui/files/
> >>
> >> This document is meant for application developers, ie for the same
> people who would use Moqui. It is 12 pages with 2 diagrams and should be a
> quick read, but describes where everything is in the framework and from a
> high level how to do various things.
> >>
> >> BTW, feedback on this document and on the framework itself would both be
> most helpful...
> >>
> >> -David
> >>
> >>
> >> On Apr 2, 2011, at 12:17 PM, David E Jones wrote:
> >>
> >>>
> >>> That is a good question. The best way to get an idea of how things
> would look is to look at the example component (in
> runtime/component/example), the configuration files (default:
> framework/api/conf-default/MoquiDefaultConf.xml, environment-specific:
> runtime/conf/...), and the interface definitions for the API
> (framework/api/src/org/moqui/...).
> >>>
> >>> I'm working on a document now that describes the different parts of the
> framework and how the API is organized ("Introduction to Moqui Framework")
> and hopefully I'll have that posted this weekend.
> >>>
> >>> -David
> >>>
> >>>
> >>> On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote:
> >>>
> >>>> David,
> >>>>
> >>>> We are interested in this project.  Let us know the best way to start
> >>>> playing with the framework and see how we could use it.  We do a lot
> of
> >>>> custom applications and moqui sounds like a framework that could be
> used for
> >>>> this.
> >>>>
> >>>>
> >>>> Thanks again for your efforts.
> >>>>
> >>>>
> >>>> Brett
> >>>>
> >>>> On Sat, Apr 2, 2011 at 12:09 AM, David E Jones <[hidden email]> wrote:
> >>>>
> >>>>>
> >>>>> I still don't know if or how all of this will turn out, but here is
> the
> >>>>> latest on the changes I've been wanting to make in the OFBiz
> Framework, but
> >>>>> gave up on doing directly in OFBiz about a year and a half ago. The
> >>>>> redesigned framework is a separate project that is now in beta (I
> just did
> >>>>> the release today):
> >>>>>
> >>>>> http://www.moqui.org/
> >>>>>
> >>>>> The Moqui Framework is now feature-complete for the planned feature
> set of
> >>>>> the 1.0 version. There are details about this in the release notes,
> >>>>> including everything in this release and the previous 3 releases,
> plus a
> >>>>> list of features not to be included in 1.0.
> >>>>>
> >>>>> At this point the framework is far enough along that it is a clear
> >>>>> demonstration of the changes that I would like to see in OFBiz, but
> that are
> >>>>> difficult to do in a project with such a mature community and a large
> set of
> >>>>> software that depends on it. Some of the main things are how the
> security
> >>>>> and authorization are done, how the API is organized, the separation
> between
> >>>>> framework and non-framework runtime artifacts, the deployment model
> >>>>> (described in detail in the RunDeploy.txt file in the project), the
> way
> >>>>> templates are used for simple-methods (XML Actions in Moqui) and the
> >>>>> form/screen/etc widgets (XML Screens, Forms in Moqui), and how the
> web
> >>>>> "controller" in OFBiz could be combined with screens and made
> hierarchical
> >>>>> to introduce a lot of flexibility and far better organization of
> >>>>> applications (less files open, easier to find things, automatic menu
> >>>>> creation, per-used menu items/subscreens, and much more).
> >>>>>
> >>>>> Now that the beta is out the next step is to start building more
> real-world
> >>>>> applications with it (so far the framework just has an example app
> and some
> >>>>> basic tools built on it), and those will act as test cases as well. I
> don't
> >>>>> have any intention to create another project like OFBiz that is a
> >>>>> comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping
> those will
> >>>>> be separate project.
> >>>>>
> >>>>> However, I am working on a project to act as a basis for various
> >>>>> applications that will share the same data model, common services,
> and
> >>>>> derive from a common set of stories too. This project is called
> "Mantle". To
> >>>>> see how this all fits together, check out the home page on the
> moqui.orgsite which has a diagram that includes these things. There is also
> a link to
> >>>>> the github repository that has the Mantle UDM (Universal Data Model)
> >>>>> progress so far.
> >>>>>
> >>>>> Back to the first comment: I don't know all of this will turn out. In
> a way
> >>>>> it would be interesting to have OFBiz migrate to use these things,
> but that
> >>>>> may not be of interest to very many in the community, so I won't be
> too
> >>>>> surprised if that never happens. I've already heard from a couple of
> people
> >>>>> who have proposed this idea, and I know some others would probably be
> very
> >>>>> against it.
> >>>>>
> >>>>> On the other hand, if anyone is curious about such a thing, now it's
> >>>>> possible to get an idea of what it might look like by look at the
> Moqui
> >>>>> Framework and the example application and such.
> >>>>>
> >>>>> -David
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >
>
>

Hi

On Apr 5, 2011, at 9:08 PM, David E Jones wrote:

>
> On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote:
>
>> Hi David,
>>
>> Congats on the beta release!
>>
>> You were asking for feature requests and today I ran across a java framework called Play they have a few of things that might be interesting:
>> - they get their framework to compile java sources directly and then hot-reloads the JVM [1]
> Taking a quick look at things I wonder if they are using Groovy to treat ".java" files as ".groovy" files. In Moqui the recommendation is to just use Groovy anytime you need a script for a service or other things. Of course, Moqui isn't so Java-centric as it seems like Play is, so runtime reloading during development is more of an inherent part of the framework and recommended tools as opposed to something that has to be added.

No. Play uses standard bytecode enhancement to shorten many things up (i.e. autogenerating getters and setters if they are not set), which are bloated in java. Groovy is used as part of the templating language only. The eclipse compiler is used for live compilation on changes in development mode, if the .java file is newer than the .class file.

>> - their logging seems to be very clear and would speed up bug finding [1] [2]
> Yes, that is interesting. In OFBiz this is a HUGE problem because there is so much use of the hideous log & rethrow pattern which results in the same, or very similar, stack trace being logged half a dozen times.
Well, this is "simply" an implementation issue, you could also screw up any play application that way...

>> - they have a module repo to specify third party hosted module repos [3]
> I'd like to do this sooner or later with Moqui and list addons or plugins, plus a document about how to create them (I couldn't find a doc like that for Play, maybe I didn't look hard enough). That framework has various means of supporting this right now, but I like the idea of creating a page to list addons/plugins, even if it starts out empty... ;)
This is because modules are actually applications themselves (with minor tweaks of course), but if you know how to write a play application, you have all the basics needed for module writing.

More generally talking about play: Concepts differ greatly between play and frameworks similar to ofbiz - no xml hell, real objects instead of map-defined entities (also making validation really simple), actually using and understanding HTTP instead of interpreting it as a stupid transport layer (this weakness exists in java since the definition of the servlet spec), completely configurable URLs as entry point to your application, multi node scalability due to true shared nothing architecture. Running tests in your IDE or without restarting your whole system is also pretty nice, when you want to call yourself test driven - any many things more.

This should be enough marketing for today... :-)

If you have time, you should take a closer look at play. It has pretty clear concepts, some of them being quite radical and thus complex to port into existing frameworks.


--Alexander (frustrated ofbiz dev on day, happy play hacker at night, possibly somewhat biased ;-))

[David E. Jones-2]

On Apr 6, 2011, at 12:32 AM, [hidden email] wrote:

> Hi
>
> On Apr 5, 2011, at 9:08 PM, David E Jones wrote:
>
>>
>> On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote:
>>
>>> Hi David,
>>>
>>> Congats on the beta release!
>>>
>>> You were asking for feature requests and today I ran across a java framework called Play they have a few of things that might be interesting:
>>> - they get their framework to compile java sources directly and then hot-reloads the JVM [1]
>> Taking a quick look at things I wonder if they are using Groovy to treat ".java" files as ".groovy" files. In Moqui the recommendation is to just use Groovy anytime you need a script for a service or other things. Of course, Moqui isn't so Java-centric as it seems like Play is, so runtime reloading during development is more of an inherent part of the framework and recommended tools as opposed to something that has to be added.
> No. Play uses standard bytecode enhancement to shorten many things up (i.e. autogenerating getters and setters if they are not set), which are bloated in java. Groovy is used as part of the templating language only. The eclipse compiler is used for live compilation on changes in development mode, if the .java file is newer than the .class file.

Interesting. I've never felt the desire to get into direct bytecode morphing, but I suppose there is a lot of fun to be had there. This sounds like a lot of stuff Groovy does (auto getters/setters, etc), but I bet it's a lot faster if it doesn't do the runtime type checking/converting and other Groovy sugar.

>>> - their logging seems to be very clear and would speed up bug finding [1] [2]
>> Yes, that is interesting. In OFBiz this is a HUGE problem because there is so much use of the hideous log & rethrow pattern which results in the same, or very similar, stack trace being logged half a dozen times.
> Well, this is "simply" an implementation issue, you could also screw up any play application that way...

Yes, that is true, and it could certainly be cleaned up in the OFBiz applications and framework.

>>> - they have a module repo to specify third party hosted module repos [3]
>> I'd like to do this sooner or later with Moqui and list addons or plugins, plus a document about how to create them (I couldn't find a doc like that for Play, maybe I didn't look hard enough). That framework has various means of supporting this right now, but I like the idea of creating a page to list addons/plugins, even if it starts out empty... ;)

> This is because modules are actually applications themselves (with minor tweaks of course), but if you know how to write a play application, you have all the basics needed for module writing.
>
> More generally talking about play: Concepts differ greatly between play and frameworks similar to ofbiz - no xml hell, real objects instead of map-defined entities (also making validation really simple), actually using and understanding HTTP instead of interpreting it as a stupid transport layer (this weakness exists in java since the definition of the servlet spec), completely configurable URLs as entry point to your application, multi node scalability due to true shared nothing architecture. Running tests in your IDE or without restarting your whole system is also pretty nice, when you want to call yourself test driven - any many things more.
>
> This should be enough marketing for today... :-)
>
> If you have time, you should take a closer look at play. It has pretty clear concepts, some of them being quite radical and thus complex to port into existing frameworks.
>
>
> --Alexander (frustrated ofbiz dev on day, happy play hacker at night, possibly somewhat biased ;-))

Aside from "xml hell" and map-ish entities instead of objects, and the occasional use of the servlet session instead of shared nothing, what is it that frustrates you about the OFBiz framework? In other words, what bothers you on a regular basic or makes things slower for you than you'd like, or than you'd anticipated?

-David

[David E. Jones-2]

The "portal" screens in OFBiz are really just database-driven dynamic screens. In Moqui they are called dynamic screens using the DynamicScreen* entities. While designed, this feature has been tabled for the 1.0 release and will be incorporated in a later release. You can see the entity definitions (commented out) in the ScreenEntities.xml file.

-David


On Apr 5, 2011, at 11:05 PM, Bruno Busco wrote:

> Hi David,
> I downloaded the beta and seen a great work!
>
> Looks like we will have soon a very good option to the actual OFBiz
> framework to think about.
>
> BTW, I couldn't find any implementation or plans regarding a portal/portlet
> feature.
> Will the moqui framework include this, or what?
>
> Regards,
> Bruno
>
> 2011/4/5 David E Jones <[hidden email]>
>
>>
>> On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote:
>>
>>> Hi David,
>>>
>>> Congats on the beta release!
>>>
>>> You were asking for feature requests and today I ran across a java
>> framework called Play they have a few of things that might be interesting:
>>> - they get their framework to compile java sources directly and then
>> hot-reloads the JVM [1]
>>
>> Taking a quick look at things I wonder if they are using Groovy to treat
>> ".java" files as ".groovy" files. In Moqui the recommendation is to just use
>> Groovy anytime you need a script for a service or other things. Of course,
>> Moqui isn't so Java-centric as it seems like Play is, so runtime reloading
>> during development is more of an inherent part of the framework and
>> recommended tools as opposed to something that has to be added.
>>
>>> - their logging seems to be very clear and would speed up bug finding [1]
>> [2]
>>
>> Yes, that is interesting. In OFBiz this is a HUGE problem because there is
>> so much use of the hideous log & rethrow pattern which results in the same,
>> or very similar, stack trace being logged half a dozen times.
>>
>> One thing I've noticed about the use of Groovy in Moqui is that they do a
>> good job of putting locations of things like scriptlets (including screen
>> actions, etc) in the stack trace. On the other hand, the stack traces are
>> HUGE because of all of the groovy proxy calls and such, and I've thought
>> about writing something to filter those out... just haven't done it yet.
>>
>> I agree trimming out redundant stuff from the stack trace would be helpful,
>> in addition to avoiding the redundant stack traces.
>>
>>> - they have a module repo to specify third party hosted module repos [3]
>>
>> I'd like to do this sooner or later with Moqui and list addons or plugins,
>> plus a document about how to create them (I couldn't find a doc like that
>> for Play, maybe I didn't look hard enough). That framework has various means
>> of supporting this right now, but I like the idea of creating a page to list
>> addons/plugins, even if it starts out empty... ;)
>>
>> -David
>>
>>
>>
>>>
>>> [1] - http://www.playframework.org/documentation/1.1.1/overview
>>> [2] -
>> http://www.playframework.org/documentation/1.1.1/usability#aBetterusabilityisnotjustfornormalpeoplea
>>> [3] -
>> http://www.playframework.org/documentation/1.1.1/modules#repository
>>>
>>> Sam
>>>
>>>
>>> On 3 Apr 2011, at 12:57, David E Jones wrote:
>>>
>>>>
>>>> The "Introduction to Moqui Framework" document is now ready and
>> available do download through SourceForge:
>>>>
>>>> https://sourceforge.net/projects/moqui/files/
>>>>
>>>> This document is meant for application developers, ie for the same
>> people who would use Moqui. It is 12 pages with 2 diagrams and should be a
>> quick read, but describes where everything is in the framework and from a
>> high level how to do various things.
>>>>
>>>> BTW, feedback on this document and on the framework itself would both be
>> most helpful...
>>>>
>>>> -David
>>>>
>>>>
>>>> On Apr 2, 2011, at 12:17 PM, David E Jones wrote:
>>>>
>>>>>
>>>>> That is a good question. The best way to get an idea of how things
>> would look is to look at the example component (in
>> runtime/component/example), the configuration files (default:
>> framework/api/conf-default/MoquiDefaultConf.xml, environment-specific:
>> runtime/conf/...), and the interface definitions for the API
>> (framework/api/src/org/moqui/...).
>>>>>
>>>>> I'm working on a document now that describes the different parts of the
>> framework and how the API is organized ("Introduction to Moqui Framework")
>> and hopefully I'll have that posted this weekend.
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote:
>>>>>
>>>>>> David,
>>>>>>
>>>>>> We are interested in this project.  Let us know the best way to start
>>>>>> playing with the framework and see how we could use it.  We do a lot
>> of
>>>>>> custom applications and moqui sounds like a framework that could be
>> used for
>>>>>> this.
>>>>>>
>>>>>>
>>>>>> Thanks again for your efforts.
>>>>>>
>>>>>>
>>>>>> Brett
>>>>>>
>>>>>> On Sat, Apr 2, 2011 at 12:09 AM, David E Jones <[hidden email]> wrote:
>>>>>>
>>>>>>>
>>>>>>> I still don't know if or how all of this will turn out, but here is
>> the
>>>>>>> latest on the changes I've been wanting to make in the OFBiz
>> Framework, but
>>>>>>> gave up on doing directly in OFBiz about a year and a half ago. The
>>>>>>> redesigned framework is a separate project that is now in beta (I
>> just did
>>>>>>> the release today):
>>>>>>>
>>>>>>> http://www.moqui.org/
>>>>>>>
>>>>>>> The Moqui Framework is now feature-complete for the planned feature
>> set of
>>>>>>> the 1.0 version. There are details about this in the release notes,
>>>>>>> including everything in this release and the previous 3 releases,
>> plus a
>>>>>>> list of features not to be included in 1.0.
>>>>>>>
>>>>>>> At this point the framework is far enough along that it is a clear
>>>>>>> demonstration of the changes that I would like to see in OFBiz, but
>> that are
>>>>>>> difficult to do in a project with such a mature community and a large
>> set of
>>>>>>> software that depends on it. Some of the main things are how the
>> security
>>>>>>> and authorization are done, how the API is organized, the separation
>> between
>>>>>>> framework and non-framework runtime artifacts, the deployment model
>>>>>>> (described in detail in the RunDeploy.txt file in the project), the
>> way
>>>>>>> templates are used for simple-methods (XML Actions in Moqui) and the
>>>>>>> form/screen/etc widgets (XML Screens, Forms in Moqui), and how the
>> web
>>>>>>> "controller" in OFBiz could be combined with screens and made
>> hierarchical
>>>>>>> to introduce a lot of flexibility and far better organization of
>>>>>>> applications (less files open, easier to find things, automatic menu
>>>>>>> creation, per-used menu items/subscreens, and much more).
>>>>>>>
>>>>>>> Now that the beta is out the next step is to start building more
>> real-world
>>>>>>> applications with it (so far the framework just has an example app
>> and some
>>>>>>> basic tools built on it), and those will act as test cases as well. I
>> don't
>>>>>>> have any intention to create another project like OFBiz that is a
>>>>>>> comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping
>> those will
>>>>>>> be separate project.
>>>>>>>
>>>>>>> However, I am working on a project to act as a basis for various
>>>>>>> applications that will share the same data model, common services,
>> and
>>>>>>> derive from a common set of stories too. This project is called
>> "Mantle". To
>>>>>>> see how this all fits together, check out the home page on the
>> moqui.orgsite which has a diagram that includes these things. There is also
>> a link to
>>>>>>> the github repository that has the Mantle UDM (Universal Data Model)
>>>>>>> progress so far.
>>>>>>>
>>>>>>> Back to the first comment: I don't know all of this will turn out. In
>> a way
>>>>>>> it would be interesting to have OFBiz migrate to use these things,
>> but that
>>>>>>> may not be of interest to very many in the community, so I won't be
>> too
>>>>>>> surprised if that never happens. I've already heard from a couple of
>> people
>>>>>>> who have proposed this idea, and I know some others would probably be
>> very
>>>>>>> against it.
>>>>>>>
>>>>>>> On the other hand, if anyone is curious about such a thing, now it's
>>>>>>> possible to get an idea of what it might look like by look at the
>> Moqui
>>>>>>> Framework and the example application and such.
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>>

[Bruno Busco]

Great!
Thanks

2011/4/6 David E Jones <[hidden email]>

>
> The "portal" screens in OFBiz are really just database-driven dynamic
> screens. In Moqui they are called dynamic screens using the DynamicScreen*
> entities. While designed, this feature has been tabled for the 1.0 release
> and will be incorporated in a later release. You can see the entity
> definitions (commented out) in the ScreenEntities.xml file.
>
> -David
>
>
> On Apr 5, 2011, at 11:05 PM, Bruno Busco wrote:
>
> > Hi David,
> > I downloaded the beta and seen a great work!
> >
> > Looks like we will have soon a very good option to the actual OFBiz
> > framework to think about.
> >
> > BTW, I couldn't find any implementation or plans regarding a
> portal/portlet
> > feature.
> > Will the moqui framework include this, or what?
> >
> > Regards,
> > Bruno
> >
> > 2011/4/5 David E Jones <[hidden email]>
> >
> >>
> >> On Apr 4, 2011, at 11:06 PM, Sam Hamilton wrote:
> >>
> >>> Hi David,
> >>>
> >>> Congats on the beta release!
> >>>
> >>> You were asking for feature requests and today I ran across a java
> >> framework called Play they have a few of things that might be
> interesting:
> >>> - they get their framework to compile java sources directly and then
> >> hot-reloads the JVM [1]
> >>
> >> Taking a quick look at things I wonder if they are using Groovy to treat
> >> ".java" files as ".groovy" files. In Moqui the recommendation is to just
> use
> >> Groovy anytime you need a script for a service or other things. Of
> course,
> >> Moqui isn't so Java-centric as it seems like Play is, so runtime
> reloading
> >> during development is more of an inherent part of the framework and
> >> recommended tools as opposed to something that has to be added.
> >>
> >>> - their logging seems to be very clear and would speed up bug finding
> [1]
> >> [2]
> >>
> >> Yes, that is interesting. In OFBiz this is a HUGE problem because there
> is
> >> so much use of the hideous log & rethrow pattern which results in the
> same,
> >> or very similar, stack trace being logged half a dozen times.
> >>
> >> One thing I've noticed about the use of Groovy in Moqui is that they do
> a
> >> good job of putting locations of things like scriptlets (including
> screen
> >> actions, etc) in the stack trace. On the other hand, the stack traces
> are
> >> HUGE because of all of the groovy proxy calls and such, and I've thought
> >> about writing something to filter those out... just haven't done it yet.
> >>
> >> I agree trimming out redundant stuff from the stack trace would be
> helpful,
> >> in addition to avoiding the redundant stack traces.
> >>
> >>> - they have a module repo to specify third party hosted module repos
> [3]
> >>
> >> I'd like to do this sooner or later with Moqui and list addons or
> plugins,
> >> plus a document about how to create them (I couldn't find a doc like
> that
> >> for Play, maybe I didn't look hard enough). That framework has various
> means
> >> of supporting this right now, but I like the idea of creating a page to
> list
> >> addons/plugins, even if it starts out empty... ;)
> >>
> >> -David
> >>
> >>
> >>
> >>>
> >>> [1] - http://www.playframework.org/documentation/1.1.1/overview
> >>> [2] -
> >>
> http://www.playframework.org/documentation/1.1.1/usability#aBetterusabilityisnotjustfornormalpeoplea
> >>> [3] -
> >> http://www.playframework.org/documentation/1.1.1/modules#repository
> >>>
> >>> Sam
> >>>
> >>>
> >>> On 3 Apr 2011, at 12:57, David E Jones wrote:
> >>>
> >>>>
> >>>> The "Introduction to Moqui Framework" document is now ready and
> >> available do download through SourceForge:
> >>>>
> >>>> https://sourceforge.net/projects/moqui/files/
> >>>>
> >>>> This document is meant for application developers, ie for the same
> >> people who would use Moqui. It is 12 pages with 2 diagrams and should be
> a
> >> quick read, but describes where everything is in the framework and from
> a
> >> high level how to do various things.
> >>>>
> >>>> BTW, feedback on this document and on the framework itself would both
> be
> >> most helpful...
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>> On Apr 2, 2011, at 12:17 PM, David E Jones wrote:
> >>>>
> >>>>>
> >>>>> That is a good question. The best way to get an idea of how things
> >> would look is to look at the example component (in
> >> runtime/component/example), the configuration files (default:
> >> framework/api/conf-default/MoquiDefaultConf.xml, environment-specific:
> >> runtime/conf/...), and the interface definitions for the API
> >> (framework/api/src/org/moqui/...).
> >>>>>
> >>>>> I'm working on a document now that describes the different parts of
> the
> >> framework and how the API is organized ("Introduction to Moqui
> Framework")
> >> and hopefully I'll have that posted this weekend.
> >>>>>
> >>>>> -David
> >>>>>
> >>>>>
> >>>>> On Apr 2, 2011, at 11:22 AM, Brett Palmer wrote:
> >>>>>
> >>>>>> David,
> >>>>>>
> >>>>>> We are interested in this project.  Let us know the best way to
> start
> >>>>>> playing with the framework and see how we could use it.  We do a lot
> >> of
> >>>>>> custom applications and moqui sounds like a framework that could be
> >> used for
> >>>>>> this.
> >>>>>>
> >>>>>>
> >>>>>> Thanks again for your efforts.
> >>>>>>
> >>>>>>
> >>>>>> Brett
> >>>>>>
> >>>>>> On Sat, Apr 2, 2011 at 12:09 AM, David E Jones <[hidden email]> wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> I still don't know if or how all of this will turn out, but here is
> >> the
> >>>>>>> latest on the changes I've been wanting to make in the OFBiz
> >> Framework, but
> >>>>>>> gave up on doing directly in OFBiz about a year and a half ago. The
> >>>>>>> redesigned framework is a separate project that is now in beta (I
> >> just did
> >>>>>>> the release today):
> >>>>>>>
> >>>>>>> http://www.moqui.org/
> >>>>>>>
> >>>>>>> The Moqui Framework is now feature-complete for the planned feature
> >> set of
> >>>>>>> the 1.0 version. There are details about this in the release notes,
> >>>>>>> including everything in this release and the previous 3 releases,
> >> plus a
> >>>>>>> list of features not to be included in 1.0.
> >>>>>>>
> >>>>>>> At this point the framework is far enough along that it is a clear
> >>>>>>> demonstration of the changes that I would like to see in OFBiz, but
> >> that are
> >>>>>>> difficult to do in a project with such a mature community and a
> large
> >> set of
> >>>>>>> software that depends on it. Some of the main things are how the
> >> security
> >>>>>>> and authorization are done, how the API is organized, the
> separation
> >> between
> >>>>>>> framework and non-framework runtime artifacts, the deployment model
> >>>>>>> (described in detail in the RunDeploy.txt file in the project), the
> >> way
> >>>>>>> templates are used for simple-methods (XML Actions in Moqui) and
> the
> >>>>>>> form/screen/etc widgets (XML Screens, Forms in Moqui), and how the
> >> web
> >>>>>>> "controller" in OFBiz could be combined with screens and made
> >> hierarchical
> >>>>>>> to introduce a lot of flexibility and far better organization of
> >>>>>>> applications (less files open, easier to find things, automatic
> menu
> >>>>>>> creation, per-used menu items/subscreens, and much more).
> >>>>>>>
> >>>>>>> Now that the beta is out the next step is to start building more
> >> real-world
> >>>>>>> applications with it (so far the framework just has an example app
> >> and some
> >>>>>>> basic tools built on it), and those will act as test cases as well.
> I
> >> don't
> >>>>>>> have any intention to create another project like OFBiz that is a
> >>>>>>> comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping
> >> those will
> >>>>>>> be separate project.
> >>>>>>>
> >>>>>>> However, I am working on a project to act as a basis for various
> >>>>>>> applications that will share the same data model, common services,
> >> and
> >>>>>>> derive from a common set of stories too. This project is called
> >> "Mantle". To
> >>>>>>> see how this all fits together, check out the home page on the
> >> moqui.orgsite which has a diagram that includes these things. There is
> also
> >> a link to
> >>>>>>> the github repository that has the Mantle UDM (Universal Data
> Model)
> >>>>>>> progress so far.
> >>>>>>>
> >>>>>>> Back to the first comment: I don't know all of this will turn out.
> In
> >> a way
> >>>>>>> it would be interesting to have OFBiz migrate to use these things,
> >> but that
> >>>>>>> may not be of interest to very many in the community, so I won't be
> >> too
> >>>>>>> surprised if that never happens. I've already heard from a couple
> of
> >> people
> >>>>>>> who have proposed this idea, and I know some others would probably
> be
> >> very
> >>>>>>> against it.
> >>>>>>>
> >>>>>>> On the other hand, if anyone is curious about such a thing, now
> it's
> >>>>>>> possible to get an idea of what it might look like by look at the
> >> Moqui
> >>>>>>> Framework and the example application and such.
> >>>>>>>
> >>>>>>> -David
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
>
>

[Ean Schuessler]

Hi David,

As usual you are a fantastically productive guy. Its a little awe
inspiring. :-D

Have you given any thought as to how different display technologies like
Vaadin, JSF or even Wicket could be accommodated in your framework?
Playing with Vaadin has shown me how I wish my views were constructed in
OFBiz.

~Ean

On 04/02/11 01:09, David E Jones wrote:

> I still don't know if or how all of this will turn out, but here is the latest on the changes I've been wanting to make in the OFBiz Framework, but gave up on doing directly in OFBiz about a year and a half ago. The redesigned framework is a separate project that is now in beta (I just did the release today):
>
> http://www.moqui.org/
>
> The Moqui Framework is now feature-complete for the planned feature set of the 1.0 version. There are details about this in the release notes, including everything in this release and the previous 3 releases, plus a list of features not to be included in 1.0.
>
> At this point the framework is far enough along that it is a clear demonstration of the changes that I would like to see in OFBiz, but that are difficult to do in a project with such a mature community and a large set of software that depends on it. Some of the main things are how the security and authorization are done, how the API is organized, the separation between framework and non-framework runtime artifacts, the deployment model (described in detail in the RunDeploy.txt file in the project), the way templates are used for simple-methods (XML Actions in Moqui) and the form/screen/etc widgets (XML Screens, Forms in Moqui), and how the web "controller" in OFBiz could be combined with screens and made hierarchical to introduce a lot of flexibility and far better organization of applications (less files open, easier to find things, automatic menu creation, per-used menu items/subscreens, and much more).
>
> Now that the beta is out the next step is to start building more real-world applications with it (so far the framework just has an example app and some basic tools built on it), and those will act as test cases as well. I don't have any intention to create another project like OFBiz that is a comprehensive ERP/CRM/etc/etc/etc system, and instead I'm hoping those will be separate project.
>
> However, I am working on a project to act as a basis for various applications that will share the same data model, common services, and derive from a common set of stories too. This project is called "Mantle". To see how this all fits together, check out the home page on the moqui.org site which has a diagram that includes these things. There is also a link to the github repository that has the Mantle UDM (Universal Data Model) progress so far.
>
> Back to the first comment: I don't know all of this will turn out. In a way it would be interesting to have OFBiz migrate to use these things, but that may not be of interest to very many in the community, so I won't be too surprised if that never happens. I've already heard from a couple of people who have proposed this idea, and I know some others would probably be very against it.
>
> On the other hand, if anyone is curious about such a thing, now it's possible to get an idea of what it might look like by look at the Moqui Framework and the example application and such.
>  

--

Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com