Hi all, Currently there are several threads regarding the overhaul of the framework, the mini-lang, and other structures. But how will all these affect the performance?
I haven't seen anything on that subject. Regards, Pierre Op 16 maart 2012 02:15 schreef David E Jones <[email protected]> het volgende: > > > 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 > >
