Jacopo Cappellato wrote: >> 3. running in a single webapp: while this isn't necessary with >> Moqui, the Moqui Screens are a combination of the controller.xml >> entries for the particular screen and the OFBiz Screen Widget, and >> are hierarchical instead of being flat like the request-map URIs in >> OFBiz; this allows apps to plug into a screen hierarchy from >> separate places (by explicit inclusion, a database record, or >> implicitly by directory structure) > > The existing OFBiz screen/form widget is an area where OFBiz should > be greatly improved in my opinion. Some of the things I don't like: * > the "configuration by exception" patter should be used more > extensively (most common screen definitions, controller entries > etc... should not be required) * it is difficult to build complex > Ajax screens * I don't like the xml code for screen/form actions: it > is limited and it is an additional programming language to learn * in > simpler screen it is an overkill to maintain in separate files the > data preparation script, the form definition and the screen > definition * the html code that is produced by the widgets is ugly > and difficult to maintain > > It seems that some of the points above have been addressed by Moqui; > David, did you ever consider to integrate other ui frameworks in > Moqui? I know that in Moqui there is a more powerful mechanism to > automatically render ui elements (e.g. submenu items for subscreens > etc...) but frankly speaking I am less interested in them because I > have learned that these tools are great to cover the 80% of the > requirements of a ui but the work on the remaining 20% still has to > be done in each and every screen to make it really usable. But I > would be really interested to see a rather complex Moqui screen that > uses Ajax and calls events: this would help me to evaluate the > advantages of the new solution.
I don't know of any magic formulas for web-based UI stuff. Even a lot of the desktop UI stuff is quite a pain and only elaborate visual-design tools make it easier... and when those aren't adequate for what you want to build life gets hard in a hurry. One thing that the Moqui screens have that help with this is that it is easier to extend the form and screen definitions by just adding macros to an FTL template that extends and/or overrides the default templates. You can add your new tags to an XSD file if you want so that things will validate properly in your IDE, but that is not necessary for the new tags to function. This still isn't a silver bullet, but at least it makes it easier to incorporate consistent UI widgets based on jQuery plugins or your own hand-rolled stuff or whatever so that it is not necessary to have HTML and/or JavaScript snippets to use each of these on each screen/page that needs them. It is also easier to inline HTML and JavaScript in a screen definition, so that doesn't have to be maintained in a separate file... and have have HTML inline in a form field and such. In other words, you can drop it just about anywhere, making it much easier to do crazy stuff with the screen and form XML files so you don't have to drop to FTL templates so often. OOTB the Moqui XML Screens and XML Forms use more JavaScript and dynamic stuff than the OFBiz ones, but there is still a LOT of room for improvement and it is something I'd like to do more of, or work with other who do it to get it into the project (any takers? :) ). If you have other ideas about what an artifact might look like that would be easier for UI stuff, I would be very interested in discussing it more. You have a lot of good ideas Jacopo, and I appreciate them a great deal. -David
