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 <d...@me.com> > > 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 <d...@me.com> 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 > >>>>> > >>>>> > >>>>> > >>> > >> > > > >
