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