http://ofbiz.116.s1.nabble.com/My-vision-for-the-OFBiz-Framework-tp3421685p3430165.html
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.
> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>>