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 <[email protected]> > >> >> 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 <[email protected]> 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 >>>>>>> >>>>>>> >>>>>>> >>>>> >>>> >>> >> >>
