The mini-lang overhaul only effects the grammar, not the performance. No one can comment on the framework performance until a decision is made about the direction it will take.

-Adrian

On 3/16/2012 8:09 AM, Pierre Smits wrote:
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


Reply via email to